Serialized messages may be of different types (for example, create, change, cancel messages). All messages here relate to one special application object.
With object serialization the messages belonging to a given object are always processed in the correct order on the receiver system. The order messages are posted in on the receiver system is the same as they were created on the sender system.
You have to activate serialized distribution in both systems in ALE Customizing:
Modeling and Implementing Business Processes
Master Data Distribution
Serialization for Sending and Receiving Data
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.
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 (see prerequisites).
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 (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 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.
Objects are assigned 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.