Serialization of IDOC Message Type
Serialization of IDOC Message Type
With serialized message distribution, IDocs are created, sent and posted in a specific order. This
prevents errors occurring when inbound IDocs are processed. Interdependent messages can be
distributed serially in different ways, as described in the following sections.
In this Tutorial we will learn Serialization using IDOC Message types and the details steps involved.
When master data is distributed, interdependent objects are often distributed together (for example,
purchasing info record is distributed with vendor and material). With serialized message distribution
IDocs are created, dispatched and posted in a specific order. The interdependency of objects is at
message type level and this avoids errors occurring during inbound processing of IDocs. Serialization
groups in which the messages to be used and the posting order is specified, are used to distribute
interdependent messages serially.
Example
If you distribute materials and the material classes, they must be distributed together. You cannot
process classification data in the receiver system, if this system does not also have the data of the
material to be classified. For this reason materials should be included with the associated classifications
in a serialization group. To use serialized distribution you must carry out the following steps in
Customizing:
Steps to be followed: -
In addition to the message types used, the dispatch of the message type SERDAT must be modeled in
the distribution model.
In this section you create serialization groups and assign message types and the processing order to
each group. Both the sender and the receiver of the serialization group must know the assignments. This
means this step needs to be carried out in both the receiving system and the sending system.
Serialization groups are required to distribute interdependent objects together so that they are
processed in the correct order.
Example
The message types MATMAS (material master) and CLFMAS (classification) are assigned to a
serialization group for dispatching materials and their accompanying classifications. The message type
MATMAS is assigned the suffix 1 and the message type CLFMAS the suffix 2, so that the materials are
processed first and then the classifications.
Create serialization group: Goto IMG Modelling and Implementing Business Proccess Master
Data Distribution Serialization for sending and Receiving data Serialization using Message types
and click on DEFINE SERIALIZATION GROUPS
On the next screen Choose 'New entries' in the view 'Serialization groups' to add a new entry, In our
case we will just modify one of the existing groups provided by SAP.
We will modify the existing group GRP_MATMAS Material Master Complete. So select the group from
the list and Place the cursor on a serialization group and choose 'Assign message types to serialization
group'.
Click on the Change/Display button and Select 'New entries'. In our case we will add one more message
type in this group. The message type to be added is CLSMAS. After adding the new entry we need to
adjust the sequence of serialization if required.
Enter the message types used and add a sequence number for each one.
Further notes
The message types in a serialization group are processed in ascending order of the sequence number
added. You can also leave spaces between the individual numbers. (For example: 1,2,4,10,20).
If the serialization group is to be dispatched later a setting must be made so that the outbound IDocs are
collected and inbound processing is carried out in the background for all message types. This is set
under Partner Profiles -> Generate Partner Profiles. You can also make these settings in the SAP Menu
for each partner profile and message type (choose ALE -> ALE Administration -> Services -> Runtime
Settings -> Partner Profiles).
Select the option from the menu to generate the partner profile
Select all the message types and ensure that the option TRANSFER IDOC IMMEDIATELY is selected.
PLEASE NOTE THIS OPTION MUST BE SET ONLY IN THE OUTBOUND PARMETERS OR IN THE SENDING
SYSTEM.
Similarly maintain for all the other messages in the partner profile and once done save your entries.
Next distribute the model created in the sending system to the receiving system. To do this select the
menu option as shown below.
Step 3 Define Inbound Processing
In this section you can make the settings for processing inbound message types for a serialization group.
These settings are made in the receiving system.
You can specify the size of the IDoc packet forwarded to the application, whether the packet is
transferred in parallel and what server group is used.
Example
For a serialization group containing materials and associated classifications you can specify how the
message types MATMAS (material) and CLFMAS (classification) are processed.
For the message SERDAT processing in the inbound partner profiles should be set to 'immediate
processing'.
From the SALE transaction select Define inbound processing as shown in the image below
On the next screen click on NEW ENTRIES button and add the details as shown below
Under the groups column mention the Serialization group name created in the first step. Under the
Message Type define the messages assigned to the Serialization group. Under the sending system
column enter the sending systems. If the data is sent to more than one system then all these steps have
to repeated for all the individual receiving systems. Under the Object column enter the number of
objects per process. In our case we will use 1 per process.
For Example: Number of objects (e.g. materials, vendors, customers) assigned to an available process.
Under the Indicator: Parallel processing yes/no set the indicator as per your requirement. Generally it is
set to YES.
If the indicator is set then the inbound processing of the application uses one free dialog process for
each IDoc packet on the application server ('asynchronous RFC' is used for this). This means that the
packets can be processed in parallel. If several IDoc packets have been selected, then the IDoc
processing will occupy all the dialog processes on the application server.
If the indicator is not set then the IDocs will not be processed in parallel. This means that each packet
will passed to the application in turn. Only one work process will be used for this action on the
application server.
Under the RFC server group define the server which will be used by the transaction in parallel
processing.
You can check the server group from the transaction RZ12.
Step 4 Enable Change pointers in the system globally using BD61 transaction and also for all the
message types using the BD50 transaction.
Change pointer has to be activated to enable data distribution through Change documents.
Step 1 Maintain the serialization group as done in the above steps in the receiving system as well.
Step 2 Go to to the distribution model and select the model that was distributed from the sending
system. And from the menu generate the partner profile in the receiving system. This step will create
the partner profiles in the receiving system.
Step 3 Change the partner profile settings for all the message types EXCEPT the SERDAT message type
to TRIGGER BY BACKGROUND PROGRAM
As shown below
BUT DO NOT CHANGE THE SETTINGS FOR THE SERDAT message type.
SERDAT will have the option TRIGGER IMMEDIATELY.
Once these settings are done both the systems are now ready for distributing data in a serialized order.
These two activities are scheduled as a periodic job in the sending system.
Creating IDocs
The report RBDSER01 creates the IDocs for a serialization group. The serialization group to be created is
specified as a parameter in this report. The report selects all the master data change pointers assigned
to this serialization group. The IDocs are then created from the change pointers.
Dispatching IDocs
After the IDocs have been created the report RBDSER02 dispatches the IDocs belonging to a serialization
group. The name of the serialization group to be sent is specified as a parameter in this report. You can
also specify the receiving systems and in the time period that IDocs can be created/changed.
The report also schedules the report RBDSER03 which checks whether all the IDocs have been
successfully sent to the receiving system. If they have, a control message of message type SERDAT is
sent to the receiving system and posts the serialization group there. To do this specify in the parameters
of report RBDSER02 the time that should be scheduled after sending report RBDSER03.
You also have the option to always dispatch the control message. This means dispatch it even if all the
IDocs have not been passed to the receiving system. This means that IDocs arriving in the receiving
system can be processed even if some IDocs are still being transferred. However, serialization difficulties
may occur.
Further notes
You can schedule reports RBDSER01 and RBDSER02 after each other in the same job (choose SAP Menu -
> Tools -> ALE -> ALE Administration -> Services -> Periodic Processing -> Outbox -> Serialized
Distribution Using Message Types - SM36).
The report RBDSER03 can be scheduled as an independent job. In this case you should not enter the
date and time.
The processing of inbound IDocs of a serialzation group can be directly started by the Report RBDSER04.