Serialization by Object Type
Serialized messages can be of different types (for example, create, change or cancel messages). All the messages considered here relate however to one special application object.
The messages can contain both master data and transaction data.
With object serialization the messages of a given object are always processed in the correct order on the receiver system. Messages are posted in the receiver system in the same order they were created in the sender system.
The message (IDoc) to be transferred is assigned a consecutive number. This is managed in the sending and receiving system for each object type and object channel. An object channel contains a number of ordered IDocs and is defined by an object type (BOR) and precisely one channel number which is a message attribute. All the messages in the target system are processed in an object channel in the same order they were created in the source system. A channel number is a message attribute. It is generated in the function module ALE_SERIAL_KEY2CHANNEL or assigned in the application program.
This number identifies the following:
-
RFC transmission error
-
The application document of a message is not yet posted (status code 53), although the next message has already been received
In both cases the IDoc is waiting in inbound processing for its predecessor IDoc and is accordingly assigned status code 66. Once the predecessor IDoc has been posted, you have to then post the IDoc with status 66 using program RBDAPP01.
All messages that have the same channel number and object type are serialized when serialization is activated.
The current number of each object channel is recorded. This process is takes place in what is known as the registry. There is an outbound registry and an inbound registry. Serialization must be activated in both registries.
Outbound Processing (in the source system)
When outbound IDocs are processed, for each object channel (field CHNUM) a unique serial number is assigned to each IDoc created (field CHCOU). This number and the object channel are transferred with the IDoc in the SERIAL field.
An unique serial number is assigned to each message for the application object in question.
Inbound Processing (in the target system)
When inbound IDocs are processed, a unique serial number is generated for each object channel (field CHNUM) 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 using program RBDAPP01.
Object types are preassigned to messages and channels by the application.
Transfer errors (IDoc sequence mixed up) and inbound posting errors (IDoc cannot be posted due to Customizing errors) no longer affect the sequential order, because serialization corrects these errors.