Application Linking And Enabling

Distributed Process

An introduction

Distributed Process.

When a part of a business process is conducted in one system and another part of the same business process in another system, such procedure is termed as a distributed process.

Distributed Process : Example.

Sales operations :
Create and Store Sales Order. Calculate price. Check inventory availability. Check credit rating of customer. Calculate delivery dates. Determine Shipping Point. Calculate shortest route.

Generate Delivery notice.

Distributed Process : Example.

Sales operations
System 1 - Sales
Create and Store Sales Order.
Calculate price. Check inventory availability. Check credit rating of customer.

System 2 - Deliveries
Calculate delivery dates. Determine Shipping Point. Calculate shortest route. Generate Delivery notice.

Distributed Process : Example.

Sales operations
System 1 - Sales
Create and Store Sales Order.
Calculate price. Check inventory availability. Check credit rating of customer.

System 2 - Deliveries
Calculate delivery dates. Determine Shipping Point. Calculate shortest route. Generate Delivery notice.

Why a distributed process ?

Reasons for Distributed Process

Geographical Location
Consolidation System Capacity

Mission Critical Applications

Separate upgrade of Modules Data Security

Reasons for Distributed Process

Geographical Location
Companies that opt for SAP implementation are large companies that are physically spread. Manufacturing units are strategically located to take advantage of cheap labor or cheap raw material. Warehouse units are located nearer to some convenient transport facility for easy movement of goods. Admin / corporate offices are located at main cities to facilitate better transactions with business partners.

These units tend to operate autonomously and do not like to depend on distant central system. It is necessary to have a dedicated system for each geographical area in which the company exists.

Reasons for Distributed Process

Consolidation
A company can have several business units that share some common resources.

A company with several sales operations could share a common shipping and warehouse systems.

This may need to keep shipping and warehouse applications on one system and applications for sales operations on another.

Reasons for Distributed Process

System Capacity
System capacities such as :

Database size. Memory requirements. Number of concurrent users. Network bandwidth.

often offer limitations which force to split and shift applications on different systems.

Reasons for Distributed Process

Mission Critical Applications

Mission critical applications (ex : shipping, delivery, inventory, purchases, sales etc) cannot afford frequent down time for any reason. In such cases it becomes necessary to deploy such mission critical applications on separate systems.

Reasons for Distributed Process

Separate Upgrade of Modules
SAP delivers new modules and enhanced functionality in every new release.

Some company has implemented SAP with release 3.1,. Later the SD division is interested in customer service model available in 4.0. This is not generally possible since the SD division cannot use this functionality until next implementation of release 4.0, when the entire company moves to 4.0.
In such situations , ability to upgrade a module without worrying about compatibility issues is desirable.

Reasons for Distributed Process

Data Security
On some sensitive operations , it may be required to separate critical and general information and keep the critical information secure, by not allowing general applications to use the same.

Existing technologies for Distribution of data

Existing technologies for Distribution of data

Disk Mirroring. Online Distribution using two phase commit protocol. Distributed updates to Replicas.

Existing technologies for Distribution of data

Disk Mirroring.

Just like disk copy.

Changes in a database are simultaneously propagated to another disk which maintains a mirror image of the main disk.

Existing technologies for Distribution of data

Online Distribution using two phase commit protocol.

Online Distribution enables you to maintain distributed database in which enterprise data is managed across multiple database servers connected thru network.

Two phase commit protocol guarantees that the related tables across systems that are updated in one LUW.

Existing technologies for Distribution of data

Distributed updates to replicates.

In this scenario, the system allows to maintain redundant data across multiple systems.

The owner of the data or the holder of the copy can update the data.
If changes are made to a copy, changes are first propagated to the owner and then to the replicas.

What SAP wanted for its distribution solutions.

What SAP wanted for its distribution solutions.

A system that understands the syntax and semantics of data.

To base distribution of data on business rules and not on data replication techniques. Distributed systems should maintain their autonomy while being integrated as one logical system. Distributed systems should handle different data models. Sending and receiving systems should handle their own problems and not tie up with each other. Distribution process should continue inspite of network failures.

SAPs solution for its distribution requirements :

Application Linking & Enabling.

Application Linking & Enabling.

SAP introduced ALE to to support a distributed yet integrated environment.

ALE allows for efficient and reliable communication between distributed processes across physically separate systems. ALE is based on application to application integration using message control architecture.

Application Linking & Enabling.

Features ALE is not based on any data replication technique. ALE architecture is independent of participating systems. This allows SAP to allow SAP to Non-SAP communication also.

This allows third party applications to integrate with SAP using ALE at data distribution level.
IDOCs constitute a major component of ALE.

Application Linking & Enabling.

Features ALE is not based on any data replication technique. ALE architecture is independent of participating systems. This allows SAP to allow SAP to Non-SAP communication also.

This allows third party applications to integrate with SAP using ALE at data distribution level.
IDOCs constitute a major component of ALE.

Release upgrades are supported by ALE.

ALE supports AUTONOMY.

Provisions of the standard system for ALE

Provisions of the standard system for ALE

Pre-configured Distributed Process Scenarios

SAP provides pre-configured scenarios based on the commonly deployed distributed applications.

SAP has identified process boundaries, optimized these scenarios and defined various IDOCs that must be exchanged.

Provisions of the standard system for ALE

Pre-configured Distributed Application Scenarios

SAP allows third party applications to be integrated with SAP using ALE and IDocs.

Provisions of the standard system for ALE

Pre-configured Master Data Scenarios

Several master data objects in SAP have been enabled for ALE.

Master data is the critical information that needs to be shared between several applications in a company.

Next Class : ALE Technology and Components