Using ALE, it is fairly easy to synchronize several SAP systems so that they contain the same data objects at anytime. These objects may be master data (customers, vendors, GL accounts, cost centers, ...) or transaction data (FI documents, purchase orders, ...). To enable the synchronization, ALE supports not only mass transfer of data between systems but also selective data transfers of objects changed since the last transfer.
How does it work?
Viewed from a high level perspective, the process is straight and simple: a sender system selects the data that needs to be distributed, packs it in a standard format and sends it to one or several receiving systems. When a receiving system gets the data, it unpacks the standard format and records the data.
In fact, 3 layers are involved in this process:
An application layer which selects and records data in R/3.
A distribution layer which filters and converts data.
A communication layer which ensures the actual communication of records generated in a standard format.
The senders and receivers are determined thanks to a so-called distribution model which defines the transfer rules (who sends what to who?). The definition of the distribution model must be known by all systems involved (either as sender or receiver) and must consequently exist on all those systems.
The Intermediate Document (IDoc)
The data transferred using ALE must have a SAP standard format to be understood from all partners in the communication. This format is the Intermediate Document (IDoc) which represents an intermediary structure between raw SAP data and EDI formats. This structure is not constant, it depends on the data to be transferred and SAP provides the structures for most SAP standard objects such as customers master data, sales orders, ...
An IDoc with a specific structure is said to have a specific type. The IDoc type is nothing more than a version of a specific IDoc structure designed to contain data for a specific object type. For example, the IDoc type DEBMAS05 is the fifth version of a structure that represents a customer master data. The management of versions for IDocs structures is necessary because the objects evolve with time and tend to become more and more complex with new data fields or tables being added regularly.
The conversion of raw data forth (for the sender system) and back (for the receiver system) to the IDoc format is also ensured by SAP standard function modules as long as you transfer standard objects. For non standard objects (enhancements), you must define your own IDoc structure and write your own conversion function modules.
RFC connections
The data communication between the SAP servers may be done by several ways. The 2 most common ways are the transactional RFC and the file. The RFC connection is used to make a direct connection between servers while the file interface speaks for itself, it uses a file containing the IDocs from the sender system as input in the receiver(s) system(s).
The selection of a communication method is made though the ports configuration as we will see in the next section. For the purpose of this article, we are going to choose the most efficient method: the transactional RFC method. To set it up, we first need to define the RFC destinations of the partner systems.
An RFC destination may be seen as a set of settings necessary to connect to a system using the RFC protocol. These settings include the address and type of the partner system along with connection information such as the user ID and password to use.
The RFC destinations of all partners systems must be defined on all systems to include in the distribution model. The transaction to use for this purpose is SM59.
Definition of the communication ports
The communication ports determine the type of data communication that must occur between systems. When the communication is to use the RFC protocol, transactional RFC ports must be created specifying the RFC destinations of the partner systems. Use transaction WE21 for this purpose.
Partners profiles
In SAP, all partners systems involved in a distribution model have a profile. There exist several profile types such as customers profiles, vendors profiles, ... but this distinction between profiles is generally not necessary and you will create in most cases your partners profiles using a generic Logical System type.
Before entering the settings of the logical systems partners, you have to create them in customizing. Also, each system in the distribution model must be assigned in its own system its own logical system that represents it. This assignment is done at client level and not at system level.
This is not easy to explain nor to understand so let's take a simple example. Let's consider we have a simple distribution model made up of a sender system (S01) and a receiver system (R01). We need to transfer data from S01 / client 100 to R01 / client 200. In both the systems, we will define the logical systems S01_100 and R01_200.
But in sender system S01, the logical system S01_100 will be assigned to the client 100 while in the receiver system R01, it will be R01_200 that will be assigned to client 200. With such a configuration you see it is even possible to transfer data between two clients from the same system.
A partner profile is used to determine a lot of important settings that will be involved in the data transfer. These settings vary depending on the role of the partner system (sender / receiver) and are defined per message type. A message type is more or less a version independent IDoc type. It is mainly a convenient way of defining settings and identifying IDocs using a criterium independent of the partner system.
For a sender partner system (inbound parameters are filled in), following important settings are set per message type in the partner profile:
A process code used to indicate which function module will be used to convert the IDoc data to SAP data.
The time of input of the IDoc: as soon as the IDoc is created in the system or on request (using program RBDAPP01).
The post processing agent who will have to treat the data input errors if need be. The post processing agent may be either a user or any other HR organizational unit.
For a receiver partner system (outbound parameters are filled in), following settings are specified in the partner profile:
The receiver port to which the data will be sent.
The sending method: one IDoc at a time or by packets.
The IDoc type that will be sent to that partner. For a given message type, the IDoc type sent may vary depending on the receiver system. Indeed you may have different versions of SAP in your system landscape.
Definition of the distribution model and data filtering
We have already seen that the distribution model is used to decide who sends what to who. But, as you guessed, there is a little bit more to be said about it and the way to manage it.
The distribution model is maintained in a central transaction (BD64) which lets you access the most useful environmental settings necessary to set up the model. Before creating the model, you must first decide on which system you are going to create it. Indeed the model must exist in all partners systems and two possibilities exist to achieve this.
Either you create the model on each system manually (with the same model technical name), which is feasible only with few systems and/or simple models. Either you create it in a specific system (usually the source system) and distribute it to the other systems thanks to the distribution command in the BD64 transaction menu.
If we want to copy the customers master data from the production system to the other systems in the maintenance line for example, we may create the distribution model on the production system and distribute it to all partners systems.
The actual creation of the model requests that you mention a technical name for the model (unique identifier in the systems landscape), a sender system, a receiver system and message types to exchange between those systems. You may afterwards add more sending and receiving systems in the model as well as more message types.
For each message type defined between a sender and a receiver, you may set filters on specific fields of the message type so that IDocs be generated only when these specific values are matched. For example, you may decide to send only customers of a specific account group. These filters are set by selecting the 'no filter set' text under message types in BD64.
There exists also another kind of filters which are segments filters. They do not filter IDocs creation based on values like we have just seen but filter unconditionally segments of created IDocs which must be excluded from the transfer (transaction BD56).
ALE – Application Link Enabling is a mechanism by which SAP systems communicate with each other and with non-SAP EDI subsystems. Thus it helps integration of distributed systems. It supports fail-safe delivery which implies that sender system does not have to worry about message not reaching the source due to unavoidable situations. ALE can be used for migration and maintenance of master data as well as for exchanging transactional data.
The messages that are exchanged are in the form of IDocs or Intermediate Documents. IDocs act like a container or envelope for the application data. An IDOC is created as a result of execution of an Outbound ALE. In an Inbound ALE an IDOC serves as an input to create application document. In the SAP system IDocs are stored in the database tables. They can be used for SAP to SAP and SAP to non-SAP process communication as long as the participating processes can understand the syntax and semantics of the data. Complete documentation on IDOC is obtained by using transaction WE60.
Every IDoc has exactly one control record along with a number of data records and status records. Control record has the details of sender/receiver and other control information. Data records contain the actual business data to be exchanged while the status records are attached to IDoc throughout the process as the IDoc moves from one step to other.
RELATED POST
PERFORMANCE TRACE IN ABAP
EXEC
EXPORT PART ONE
EXPORT PART TWO
FETCH
FIELD SYMBOLS
This comment has been removed by a blog administrator.
ReplyDelete