Explaining Cross-System Business Processes

Let's start by defining cross-system business processes, using common situations as examples.

• For example, it may be the case that within a company, the Human Resources system is separated from the other business software systems. Obviously, the systems cannot be completely separated, since the accounting system needs the employees' wage data. In this situation, you need cross-system business processes to exchange the relevant data.

• Cross-system business processes are also used, for example, if two companies collaborate closely and send joint orders to a vendor. The companies' business IT systems need to communicate with each other to consolidate the quantities to be ordered. In this case, the business process does not just cross system boundaries, but also company boundaries.

• An additional example is the transfer of a limited quantity of specific data, for example, the electronic transfer of account statement data from a bank to a company.

You could also describe ALE as being composed of the elements: who exchanges what data when, with whom, and by what means.

Implementing ALE therefore requires that you clarify the following points in detail:

• Identify the business process and the objects involved

• Identify the information to be transmitted

• Specify the format for the data to be transferred

• Decide on the transfer technology to be used

• Decide on the transfer type

• Specify the destination of the data transfer

In an integrated SAP system, data is transferred from the logistics application to the accounting application using the financials accounting interface. Each logistics application calls the accounting interface with the relevant data. The accounting document is checked there, completed, and then forwarded to the various accounting applications for further processing.

This principle is also used in a distributed SAP system. Imagine a customer with a central accounting system and several decentral SAP logistics systems. Here, an accounting system runs in the background in every SAP logistics system. The logistics applications call the accounting interface in the decentral SAP system. The detailed posting is performed locally rather than in the remote accounting system. Every accounting application then has to decide which data it needs to send to the other logical system.

The following table contains an example for implementing ALE in such a distributed scenario:

The data is often identified within the client of an SAP system using a business object and its Business Application Programming Interfaces (BAPIs). A BAPI is a method of a business object, for example, the method Availability of the business object StandardMaterial. A permissible method could also be creating (method Create) or changing (method Edit) the standard material. BAPIs normally enable you to edit all data belonging to the object.

The IDoc format describes the structure of intermediate documents. There are various kinds of IDoc formats for different types of data to be exchanged. IDoc Types are based on the EDI standards and mostly on EDIFACT standards. Alternatively, you can transfer data in an agreed XML format.

You can select your preferred data transfer technology within the constraints imposed by the SAP system. For example, you can transfer data by Remote Function Call (RFC) or using HTTP or HTTPS.

There are two basic types of transfer: synchronous and asynchronous. A synchronous transfer means that the data is transferred at the time of creation or change and the sending system waits for the response of the target system. In contrast, you can start asynchronous transfers at intervals of your choice.

There are very few restrictions on the SAP systems that can be linked: The SAP systems involved must have the technical capability to receive the communications (RFC-enabled, HTTP-enabled) and interpret the format transferred (IDoc, XML). Using ALE, SAP systems of different releases can be linked.