Serialization of Messages
Purpose of Serialization:
Serialization plays an important role in distributing interdependent objects, especially when master data is being distributed. IDocs can be created, sent and posted in a specified order by distributing message types serially.
Thus Errors can then be avoided when processing inbound IDocs.
Types of Serialization:
Interdependent messages can be serially distributed in the following ways:
• Serialization by Object Type
• Serialization by Message Type
• Serialization at IDoc Level (Not for IDocs generated from BAPI-ALE interfaces)
Serialization Using Object Types:
Object type serialization is carried out using object channels. In an object channel all messages are processed in the target system in the same sequence they were created in the source system. An object channel contains a number of ordered IDocs and is defined by an object type (BOR) and precisely one channel number. A channel number is a message attribute. It is generated by the function module ALE_SERIAL_KEY2CHANNEL.
All messages with the same channel number and object type are serialized when the messages are processed. This process takes place in the registry. There is an outbound registry and an inbound registry. Serialization must be activated in both registries.
Outbound processing (in source system):
When outbound IDocs are processed, for each object channel (field CHNUM) a unique serial number is assigned to each IDoc created. This number and the object channel are transferred with the IDoc in the SERIAL field.
Inbound processing (in target system)
When inbound IDocs are processed, a unique serial number is generated for each object channel and communication link. The ALE layer determines whether a given IDoc can now be posted or whether other IDocs have to be posted first. The serial number for each received IDoc is exactly one whole number lower. Any gaps in the sequence will mean that IDocs are missing, either because the transfer did not work, or because earlier IDocs were not posted successfully. In this case the IDoc is assigned status 66 and must be posted again with the program RBDAPP01.
Serialization Using Message Types
The ALE serialization function module Serialization_Check flags each IDoc that has been overtaken. An overtaken IDoc is defined as follows: assuming IDocs A and B contain information about object/document X (e.g. order number 1211). If A is created by the SAP sending system before B, but B has already been successfully processed by the SAP receiving system, A is said to have been overtaken.
To use serialization you need to:
- Define the serialization object for your message type - ALE extracts the object/document number from the IDoc's data segments, and hence needs to know which field to use.
- Call the function module for serialisation Serialization_Check at the beginning of your inbound function module.
- Handle overtaken IDocs according to your needs.
- Ensure that the inbound function module's export table SERIALIZATION_INFO contains the serialization table from the function module Serialization_Check .
Serialization at IDoc Level
Delays in transferring IDocs may result in an IDoc containing data belonging to a specific object arriving at its destination before an "older" IDoc that contains different data belonging to the same object. Applications can use the ALE Serialization API to specify the order IDocs of the same message type are processed in and to prevent old IDocs from being posted if processing is repeated.
SAP recommends that you regularly schedule program RBDSRCLR to clean up table BDSER (old time stamp).
IDocs generated by BAPI interfaces cannot be serialized at IDoc level because the function module for inbound processing does not use the ALE Serialization API.
ALE provides two function modules to serialize IDocs which the posting function module has to invoke:
IDOC_SERIALIZATION_CHECK -checks the time stamps in the serialization field of the IDoc header.
IDOC_SERIAL_POST - updates the serialization table.