How it works
[ Up ] [ Why ALE? ] [ How it works ] [ Project Detail ] [ ALE General ] [ SAP ] [ Site Index ]

Home

A Summary Girl at computer (5517 bytes)

ALE allows the user to perform an SAP transaction in the sending system, after-which the following steps occur:

1 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. Eg. 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 decouples it and allows you to distribute it onto other remote systems.

The Detail as described by SAP

In the output processing one of the function modules of the application creates an IDoc, the so-called master IDoc. This IDoc is sent to the ALE layer where the following processing steps are applied:

Outbound processing

Receiver determination

An IDoc is similar to a normal letter in that it has a sender and a receiver. If the receiver has not been explicitly identified by the application, then the ALE layer uses the customer distribution model to help determine the receivers for the message.

The ALE layer can find out from the model whether any distributed systems should receive the message and, if so, then how many. The result may be that one, several or no receivers at all are found.

For each of the distributed systems that have been ascertained to be receiver systems, the data that is specified by the filter objects in the customer distribution model is selected from the master IDoc. This data is then used to fill an IDoc, and the appropriate system is entered as receiver.

Data selection

Segment filtering

Individual segments can be deleted from the IDoc before dispatch by selecting Functions for the IDoc processing -> Settings for filtering in ALE Customizing. The appropriate setting depends on the sending and receiving logical R/3 System.

Field conversion

Receiver-specific field conversions are defined under Functions for the IDoc processing -> Conversions.

General rules can be specified for field conversions; these are important for converting data fields to exchange information between R/2 and R/3 Systems. For example, the field "plant" can be converted from a 2-character field to a 4-character field.

The conversion is done using general EIS conversion tools (Executive Information System).

Version change

SAP ensures that ALE functions between different R/3 System releases. By changing the IDoc format you can convert message types of different R/3 releases. SAP Development use the following rules when converting existing message types:

Fields may be appended to a segment type;
Segments can be added;

ALE Customizing keeps a record of which version of each message type is in use for each receiver. The correct version of the communication IDoc is created in the ALE output.

The resulting IDocs (it is possible that several IDocs could be created in the receiver determination) are referred to as communication IDocs and are stored in the database. The dispatch control then decides which of these IDocs should be sent immediately. These are passed to the communications layer and are sent either using the transactional Remote Function Call (RFC) or via file interfaces (e.g. for EDI).

If an error occurs in the ALE layer, the IDoc containing the error is stored and a workflow is created. The ALE administrator can use this workflow to process the error.

Inbound processing

After an IDoc has been successfully transmitted to another system, inbound processing is carried out in the receiver system, involving the following steps in the ALE layer:

Segment filtering

Segment filtering functions the same way in inbound processing as in outbound processing.

Field conversion

Specific field conversions are defined in ALE Customizing.

The conversion itself is performed using general conversion tools from the EIS area (Executive Information System).

Generalized rules can be defined. The ALE implementation guide describes how the conversion rules can be specified.

One set of rules is created for each IDoc segment and rules are defined for each segment field.

The rules for converting data fields from an R/2-specific format to an R/3 format can be defined in this way. An example of this R/2 - R/3 conversion is the conversion of the plant field from a 2 character field to a 4 character field.

Data transfer to the application

Input control

When the IDocs have been written to the database, they can be imported by the receiver application.

IDocs can be passed to the application either immediately on arrival or can follow in batch.

You can post an inbound IDoc in three ways:

  1. by calling a function module directly: A function is called that imports the IDoc directly. An error workflow will be started only if an error occurs.
  2. by starting a SAP Business Workflow. A workflow is the sequence of steps to post an IDoc.
  3. by starting a work item A single step performs the IDoc posting.

The standard inbound processing setting is that ALE calls a function module directly. For information about SAP Business Workflow alternatives refer to the online help for ALE programming.

Please ADD any comments to our Guest book, otherwise READ through it if you wish...

Running cheetah (19590 bytes)

This Web Site was created by Kevin Wilson  and Johan Delport
Last update: April 12, 1999
1