Wednesday, August 20, 2008

IDocs, ALE

IDoc (for intermediate document) is a standard data structure for electronic data interchange (EDI) between application programs written for the popular SAP business system or between an SAP application and an external program. IDocs serve as the vehicle for data transfer in SAP's Application Link Enabling (ALE) system. IDocs are used for asynchronous transactions: each IDoc generated exists as a self-contained text file that can then be transmitted to the requesting workstation without connecting to the central database. Another SAP mechanism, the Business Application Programming Interface (BAPI) is used for synchronous transactions.

A large enterprise's networked computing environment is likely to connect many geographically distributed computers to the main database. These computers are likely to use different hardware and/or operating system platforms. An IDoc encapsulates data so that it can be exchanged between different systems without conversion from one format to another.

IDoc types define different categories of data, such as purchase orders or invoices, which may then be broken down into more specific categories called message types. Greater specificity means that an IDoc type is capable of storing only the data required for a particular transaction, which increases efficiency and decreases resource demands.

An IDoc can be generated at any point in a transaction process. For example, during a shipping transaction process, an IDoc may be generated that includes the data fields required to print a shipping manifest. After a user performs an SAP transaction, one or more IDocs are generated in the sending database and passed to the ALE communication layer. The communication layer performs a Remote Function Call (RFC), using the port definition and RFC destination specified by the customer model. The IDoc is transmitted to the receiver, which may be an R/3, R/2, or some external system.


What is ALE?
The ALE (Application Link Enabling) concept available in R/3 (Release 3.0) supports the development of applications across different SAP systems. It incorporates the exchange of business information across these systems whilst ensuring consistency and integrity of the data. This functionality is achieved with the use of IDocs (Information Document) as opposed to the use of a centralized database. ALE allows the user to perform an SAP transaction in the sending system, after-which
the following steps occur:
• One or more communication IDocs (intermediate documents: container for the application data) are created in the sending system database. An ALE distribution
model, that needs to have been configured, determines which systems the IDocs are to be sent
• These communication IDocs, that contain the relevant application data of the transaction that was performed, are then passed to the ALE communication layer
• This layer performs an RFC call, using the port definition and an RFC destination determined through the customer model
• The IDocs are then transferred to the respective receiving systems. These could be SAP R/3, R/2 or external systems
• If the receiving system is an SAP system then:
• In the case of master data distribution the same transaction that was performed on the sending system is again performed on the receiving system with the data contained in the IDoc. This allows the data to go through the SAP checks before posting occurs
• In the case of transaction scenarios the relevant data is passed to the respective transactions in order to load the required application document. E.g., a PO is loaded on the sending side, yet a SO is created on the receiving system
• Master data has another difference:
• It can be set up in such a way that any changes made to specific fields in master data tables can automatically trigger off the ALE distribution process for that particular master data object
• If a master data object is created or changed on a sending system and distributed to another system the respective transaction is used to either create or change that respective master data object on the receiving system
In general, if standard SAP can't perform the task required then neither can ALE. It doesn't add functionality; it merely de-couples it and allows you to distribute it onto other remote systems.

What can be distributed?
Control data
The control data includes all objects that describe how the system is organized.
These include Customizing data like company codes, languages, purchasing organizations, plants and user maintenance.
The customer details his specific distribution in the customer distribution model. Once the control data is distributed the control data cannot be changed on the receiving systems. All changes are made to the central system and transported to the receiving systems.
Master Data
The distribution scenarios for the master data are contained in the reference model.
Rather than distributing the entire master data information, views on it are distributed
(for example, sales views on the material master). By configuring the views, the customer can select the master data fields to be distributed.
Transaction Data
The distribution scenarios for the transaction data are stored in the distribution reference model. Examples of transaction data are customer order, distributed contracts, purchase order, shipping notification and invoice.
Why ALE?
ALE is business solutions to a very real need emerging in the SAP market. This is the need for businesses to move towards tighter integration between systems, yet, at the same time, provide independence to the various business units within the company.
In the past the move was towards centralized systems.
Standardization of business processes accompanied by ever-tighter integration within the central system no longer represents a practicable approach to this problem. The following are some of the most commonly encountered difficulties:
• Technical bottlenecks,
• Upgrade problems,
• The effect of time zones on international corporations,
• Excessively long response times in large centralized systems.
In order both to meet the requirements of today's customers and to be open for future developments, ALE must meet the following challenges:
• Communication between different software releases.
• Continued data exchange after a release upgrade without special maintenance.
• Independence of the technical format of a message from its contents.
• Extensions that can be made easily even by customers.
• Applications those are decoupled from the communication.
• Communications interfaces that allow connections to third party applications.
• Support for R/3-R/2 scenarios.


No comments: