http://www.saptechnical.

com

Tutorials on ALE & IDOCs

Step-by-Step Tutorials

• Step-by-step guide to ALE and IDOCs (More details) HOT

• ALE-IDOC Scenario using Custom IDOC (More details)
• Distributing Master data (Outbound) (More details)
• Creation of Custom IDOC Type (More details)
• ALE step by Step Configuration for Message type MATMAS (More details)
• IDOC Mass Upload Tool (More details) HOT
• Conversion Rule in ALE/IDOC Scenario (R/3 To R/3) (More details)
• Configuring Message Control and understanding how Message Control works (More
details)
• Serialization of IDOC Message type (More details)
• ALE - Error handling through Workflow (More details)
• Archiving IDocs (More details)
• IDOC Filtration (More details)
• Distributing Material Master Data using Standalone programs and Change Pointers (More
details)
• Automatic IDOC generation whenever a PO is created/changed (More details)
• Enhancement/Extension of Standard IDOC type. (More details)
• Conversion of IDOCs to XML format (More details)
• Download IDOC to excel, HTML or any other format (More details)
• Change Pointers in ALE (More details)
• Extending the standard IDOC for Outbound delivery (VL02N) (More details)
• Re-Processing inbound IDOC using WE02 (More details)
• Customer exit for passing extra fields in Master data distribution using SMD tool (Shared
master data tool) (More details)
• Automatic Master Data distribution using the change pointers for Material Master Data
(More details)
• Configure workflow notifications for IDocs in error status (More details) NEW
• Create Condition Records Using the Message Type COND_A for condition table A018
(More details) NEW
• Creating an IDoc File on SAP Application Server (More details) NEW
Step-by-step guide to ALE and IDOCs
By Shankar Reddy Chamala, ITChamps Software
Introduction to EDI and ALE:
EDI (Electronic Document interchange) - EDI is the electronic exchange of business
documents between the computer systems of business partners, using a standard format
over a communication network.
EDI is also called paperless exchange.
Advantages:
Reduced Data entry errors
Reduced processing time
Availability of data in electronic form
Reduced paperwork
Reduced Cost
Reduced inventories and better planning
Standard means of communications
Better business process

EDI has two process

1. Outbound process
2. Inbound process

Outbound Process:
1.Application document is created.
2. IDOC is generated
3.Idoc is transferred from SAP to Operating system layer
4.Idoc is converted into EDI standards
5.Edi document is transmitted to the business partner
6.The Edi Subsystem report status to SAP

Inbound Process:
1.EDI transmission received
2.EDI document is converted into an IDOC
3.IDOC is transferred to the SAP layer
4.The application document is created
5.The application document can be viewed.
ALE-IDOC Scenario using Custom IDOC
By Sachin Dabhade

Aim: Transfer the data from one system to another using user customized IDOC.

Sender System:

Server: 172.25.8.185

Client: 200

Data from Z table: zsach1

ReceiverSystem:

Server: 172.25.9.198

Client: 800

Data from Z table: zsach1

Data is fetched from Z table on the sender system and inserted it in the Z table of Receiver
system using ALE/IDOC.

Settings on the Sender End

Table Creation T – Code SE11. The table contains data that is to be sent to Receiver.

ALE Configuration

T-Code – SALE
Defining Logical System

200 is our sender

800 is our receiver

Assigning Client to Logical System

200 is our sender

800 is our receiver

Defining Target System for RFC Calls (Tcode – SM59)

Click on R/3 Connections and then Create TAB

Step 1
Step 2

Save and test the connection.

Defining Port

The sender system is connected to the receiver system through this Port.
Distributing Master Data (Outbound)
By Sarang Kahu

Master data can be distributed in two ways. In both case the IDOC receives data for only one
master data object.

1. Master data object sent directly

This process sends the entire data of the master objects.

This is done by triggering a report program starting with RBDSEXXX where XXX is the first
three characters of the message type. Example for message type MATMAS the program is
RBDSRMAT. For DEBMAS the program is RBDSEDEB and so on.

Inside the report programs a function module is called which is responsible for generating and
dispatching the IDOC for the master data. The naming convention for the function module is
MASTERIDOC_CREATE_REQ__XXXXX where XXXXX is the name of the message type.

The function module executes the change pointers and generates IDOC in the following manner

• Creates IDOC for each master data objects where the first field of each segment
MSGFN is ‘005’.
• Pass the IDOC to the ALE layer by calling the function module MASTER
IDOC_DISTRIBUTE.

• Executes COMMIT WORK and calls DEQUEUE_ALL Function module

2. Master data is distributed using SMD tool (Shared master data tool)

The SMD tools logs changes to a master data using changed pointers. Changed document
should be written whenever the master data is changed or created or deleted. Only changed
data is written to the IDOC, send to the ALE layer and dispatched to the other system.

For example when a modification is recorded in customer information (VD02 transaction), an

entry is saved in BDCPS or BDCP2 table, it depends on the customizing. At the entry creation,
the PROCESS field is empty. As soon as the change pointer has been processed, the field is
filled with the value X.

Steps for distributing Master data using SMD tool.

➢ Define change relevant field for the message type

Transaction BD52
For master data to be distributed to other systems change document fields are defined in
transaction BD52 so that change pointers are written. This creates entry in table TBD62.

➢ Activate change pointers for message type.

Transaction BD50

The message type for which master data is to be downloaded has to be activated if change
pointers are to be written. This create a entry in table TBDA2
➢ Activate change pointers - generally.

Transaction BD61.

This activates master data distribution using change pointers

Define function module to evaluate change pointers

Transaction BD60

This create entry in table TBDME

Creation of Custom IDOC Type
By Sarang Kahu

1.Business Case

SAP R/3 systems send out data through IDoc (Intermediate Document), which in internally has
segments and fields containing the data. But sometimes, these fields are not sufficient for a specific
end-to-end business scenario as far as data transfer is concerned. So in such scenario, either few
fields are to be added or subtracted, or completely new structure- IDoc needs to be created. This are
called as Custom – IDOC Types. Following blog gives out step-by-step approach for creation of the
same.

2.Development of IDOC types

2.1 Creation of Segment Types

Run T-code ‘WE31’ to create segment type, which has fields to contain the data and are added to the
segment type in the same transaction. The data stored contained into the segment mesh is finally
stored in EDISEGMENT table.

Add your custom fields as per business scenario.

To make it available to other transactions, release the segment created.

Go to Edit -> Set Release

2.2 Creation of IDoc type

Run T-code ‘WE30’ to create custom IDoc type. Enter the name of custom IDoc you want to create
and click on red box for creation.

Now, it takes you to following screen. Here you can add description for your IDoc type. Also you can
specify name of existing IDoc for Copy or Successor mode.

Now, you can maintain attributes of the custom IDoc, which consists of attaching segment type
created above to the IDoc type. Also specifying the details of frequency of these segments getting
filled i.e. Maximum and Minimum number. Fill the necessary details and release this IDoc type as
well.

2.3 Creation of logical message types

Run T-code ‘WE81’ to create the logical message types. Go to Edit mode and click New Entry to go
to following screen.

Save the entered data.

2.4 Linking Message type and IDoc type.

Run T-Code ‘WE82’. Now we have to link these created IDoc types and Message types. Enter the
message type name, Basic IDoc type (ZCUST_IDC) and release type to be linked. In the data
transfer through ALE, these message types represent the IDOC structure.

Extension field above will be used as per the Extended IDoc type scenario i.e. in case of addition of
few more fields into the existing IDoc type.

Hence, now our Creation of Custom IDoc is ready to use in ALE scenarios.
ALE step by step Configuration for Message type MATMAS
By N.K.Chaitanya

In this scenario, I explained the process for ALE configuration for MATMAS (Material Master
Data).

Go to Tcode SALE .Select Define Logical Systems.

Created two systems. One for Sender and One for Receiver.
Now In SALE, select Assign Logical Systems to Client. You will get the below screen.

Assign the system ECC001 to Client 001.

Assign the system ECC002 to Client 002.
ALE step by step Configuration for Message type MATMAS
...Previous

Now create RFC connections for two systems. In SALE you can select Create RFC
Connections or you can directly go to Tcode SM59.
Select ABAP Connections and then click on Create.

Enter the details. In target Host Enter the IP Address of your SAP SYSTEM.
In Logon & Security Tab Enter the Login details of the Receiver system (002 clients).
Now Click on Connection Test. If you get the below it means the connection to the system is
successful. If the Connection fails then you will get error message.

Now In Receiver system (client 002) Create RFC to Client 001.

ALE step by step Configuration for Message type MATMAS
...Previous
Now go to transaction SALE (client 001) ,go to Maintain Distribution Model and Distribute Views
or else you can directly go to Transaction BD64.

Go to change mode and then click on Create Model View.

Now after clicking on Create Model View Button You will get the below screen. Enter short text
and any name in technical Name.
The below Model view is created.

Now select the model view like above and then select Add message tpe. You will get the below
screen. Enter the Sender and Receiver and the Message type you want. Here we are sending
MATMAS data from ECC01 to ECC02.

Now when you expand the Model View You will get the below view.
Now again select the Model view and click on Generate Partner Profiles.

In Model View Enter the Model view name which you created and then in Partner system enter
the receiver system name (ECC02).

When you click on execute you will get the below screen. The port A000000017 will be created.
Now without creating the model view in receiver system you can distribute the model view so
that it will be sent to receiver system.

Select the Receiver system, here ECC002.Click on Enter.

You will get the below screen.

ALE step by step Configuration for Message type MATMAS

...Previous

Now In Client 002 check the model view in BD64.You can see it in Client 002 without creating it
as we have distributed it.
Now click on the Generate Partner profile which is there in the menu shown above. You will get
the below screen. Enter the Model view name and Partner System.

When you click on execute you will get the below screen.
In Client 001 go to Tcode WE20. You need to configure the message type MATMAS in Partner
profile. In Outbound system (Sender system) we need to select the Inbound system (Receiver
system) and then in Outbound parameters we should configure MATMAS message type.

Now In Client 002 (Inbound system – Receiver system) after going to WE20 select the
outbound system and then in Inbound parameters configure MATMAS message type.
Now create a material for testing in Client 001 using Tcode MM01.
ALE step by step Configuration for Message type MATMAS
...Previous
Check the material created by using the tcode MM03.

Now In Client 002 check whether the material created is available or not by using the tcode
MM03.
The material is not there. Now in Client 001 execute the Tcode BD10.Ente the material no
created, Message type and the receiver system name. Now click on execute.

You
will get the following screens.

Click on Enter after getting below screen.

Now In Client 002 check whether the material is available or not by using the Tcode MM03.

So the material is distributed from client 001 to Client 002 using ALE.
IDOC Mass Upload tool
By Infosys Technologies Ltd (Manish Gupta, Vivek Gupta, Devakumar Karthikeyan)

INTRODUCTION

As we know that SAP provides its users the facility to edit the data in the IDOC segments, but
only one segment of an IDOC at a time.

Moreover, the user can not edit multiple occurrences of the same segment at the same time.
This tool provides the user the flexibility to edit multiple IDOC’s of the same Message type at
one go and save the IDOC’s at the same time.

The tool takes the IDOC number(s) and IDOC message type as input from the user and
displays all the errors in that IDOC (s)on the screen.

The user can select the IDOC(s), and after following a series of simple steps he can edit the
data in the IDOC segments.

Moreover, the tool also displays the user the original and the edited values on the same screen
so that he can see what values he edited.

PROGRAMS

Create the following programs:

• Main Program
• YRTRR6N_MASS_TOP - Include program for the data declaration
• YRTRR6N_MASS_SEL_SCREEN - Include program for the selection screen.
• YRTRR6N_MASS_FORM - Include program for the subroutines

Create a transaction code YRTR_IDOC_UPD for the main program created above.

HOW TO USE THE TOOL

1. The below selection screen appears when the user executes the transaction
‘Y_IDOC_UPD’.
2. Provide input on the selection screen i.e. document number (IDOC) that needs to be

edited and the message type and click on EXECUTE .

3. All the segments that contain errors are displayed on the screen as shown below.

4. Select the IDOC’s that need to be edited by selecting the check box in front of each
IDOC.
 5. If you want to select all the entries together, click on the SELECT ALL button.
The below screen appears.

IDOC Mass Upload tool

...Previous

6. After selecting the relevant check boxes, click on the MASS UPLOAD
button.

a. If the UPDATE button is clicked, a pop up comes stating the user that he has
clicked on the wrong button.
b. If none of the above screens appears then the below screen appears.

7. Edit the values you want to change on the above screen and click on the UPDATE
button.
The below pop up appears.

8. Click on YES or hit enter on the keyboard.

The below screen appears displaying the original and edited values.
9. The FIND AND REPLACE button allows you to find a particular value and replace it
with a suitable value. When this button is clicked the below screen appears.

10. Enter the values in the above screen and click on the REPLACE button.
The old values will be replaced by the new ones.
11. Now click on the UPDATE button. The below screen appears displaying
the original and edited values.
IDOC Mass Upload tool
...Previous

Additional Details like screen, message class and text elements used:

1. Screens: There are 2 screens created apart from selection screen i.e. 1100 and 1101 and
their details are as in the screen shot below:
Screen # 1100: Screen attributes:
Element List:
Screen Layout:

Screen # 1101 Screen Attributes:

 Screen Layout:

TEXT ELEMENTS & Selection Texts:

 PF statuses used in the program:

1. Status_1100:

2. Z_MASS_UPLOAD:
3. Z_OUTPUT:

Conversion Rule in ALE/IDOC Scenario (R/3 To R/3)

By Jitendra Nath Sethi, HCL AXON

Scenario: R/3 To R/3 ALE Communication ->when multiple systems involved in sending the
messages to each other for their business transactions through IDOC.

If both the systems have different configurations then we need to convert the entity like Unit of
measure/Text id/delivery block etc. For example the system ‘A’ has the Unit of measure (BT –
Bottle) but in the system ‘B’ it is (BO-Bottle). So while sending an IDOC (Outbound) we need to
convert the field value from BT to BO.

Solution: This can be achieving through User Exit or conversion Rule.

Conversion Rule: This is the standard functionality provided by the SAP & it is easy to deal with
the conversion of the field value in the segment of the IDOC.

There are three steps to achieve these conversions.

Step 1 -> Maintain Conversion Rules

a) Go to transaction code BD62

b) Click on the change button

c) Enter the name of conversion rule, description and IDOC segment name.

Steps 2 -> Create Conversion Rule

a) Go to Transaction code BD55

b) Click on the New Entries

c) Enter type/Sender/Receiver/Conversion Rule etc.

d) Save

Steps 3 ->ALE/IDOC Segment

a) Go to Transaction code BD79

b) Enter the conversion rule which we have created in the transaction code BD62
c) Click on the change mode

d) Copy & paste the receiver field to the sender field.

e) Double click on the field whose value need to be converted in this case it is : MENEE &
PMENE
f) Select Convert Sender field & Copy Sender field radio button as shown in the screenshots.

g) Click on the conditions button & input the value in the table as shown in the below screen
shots.
Conversion Rule in ALE/IDOC Scenario (R/3 To R/3)
...Previous

Test Result:

Before applying conversion rule:

After applying Conversion Rule:
Configuring Message Control and understanding how Message
Control works
By Krunal Raichura, Accenture Services Pvt. Ltd

Most SD and MM process use Message Control. The concept of Message control is to generate
and manage outputs from an application and control their timing and medium of exchange.

Below are the details for configuring the message control and understanding how message
control works.

Configuring Message control:

Message Control Components:

Communication Structure:

The communication structure passes application information to the Message control. The
communication structure for output determination uses the naming convention as KOMxByy,
where x can be K (header structure) or P (Item structure), and yy is two character application ID.

The two character application ID can be found from the NACE transaction depending on the
application.

The Procedure
A Procedure defines a set of possible outputs for an application. A procedure is assigned a six
character name. Several procedures can be defined for an application but only one can be
configured as active.

A list of procedure can be seen in NACE transaction for the required application.

A procedure has three main attributes:

- A List of output types – set of outputs that are possible for an application

- A Requirement field

- A manual flag

Set of Outputs those are possible for applications are listed in the output types.
Manual Flag is set if the output has to be selected by the user manually instead of selecting
automatically.

For Sales, Procedures can be assigned to Sales document type using V/43 transaction.

Preconditions are captured in Requirements. These conditions are written in VOFM transaction.

Configuring Message Control and understanding how Message

Control works
...Previous
We can write the conditions for the Requirement selected from the above list by creating routine
which will start from 900.

ABAP code can be written in the routine for checking the condition.

Output Type:

An Output type defines the characteristics and attributes of the output itself.

Output type can also be selected from the NACE transaction.

Access sequence is the set of business rules for proposing an output type.

If the flag Access to condition is set then the medium and timing are determined from the
condition records using access sequence.

If the flag is not set then the medium and timing data is taken from the customer master.

CannotBeChanged determines whether the output can be edited.

Multiple issuing determines whether multiple outputs are permitted.

Access Sequence:

Access sequence defines a sequence in which the business rules are checked for proposing an
output type. A business rule is checked by comparing the values passed in the application data
with the values defined in the condition records of the condition table. If a match occurs the
business rule is considered satisfied. After a business rule is satisfied the output values from the
condition records are used for the output type.
The exclusive or inclusive strategy specifies whether the system should exit after the first match
of the business rule against the condition record or should continue to process other business
rule in the access sequence.

The reason for an inclusive strategy is to have an output type proposed multiple times.
However, one of the attributes (partner function, partner number or language) must be different.
The system does not allow two output types to have identical values.

Condition Tables:

The condition table specifies the key field for a business rule. You use this key to access the
condition records for output values such as output medium, partner function, partner number,
output language and output time for the message.
If the standard condition tables supplied in the system do not meet your requirements, you can
create new condition tables.

Condition Records:

Condition records are inserted in the condition tables. Condition records contain the actual
business data against which the business rules are checked to propose an output. They are
considered master data maintained by customer.

You can create condition records for the each application in NACE transaction by clicking the
condition record button for the required application.

You will have to select the business rule for which condition record is to be maintained.

Specify the values for the key fields and maintain the output medium, output timing, partner
number and partner function for each record and save the entries.

Configuring Message Control and understanding how Message

Control works
...Previous

Understanding How Message Control works:

Message Control is a three step process:

1. Output proposal
2. Output editing
3. Output processing
Output Proposal

When an application is created or changed, after saving the application data the communication
structure is filled and is passed to the Message control along with the application id and
procedure.

The various outputs defined in the procedure are processed one at a time. The output marked
as manual will be processed manually by the user.

The requirement, if specified for an output type is executed to check if the output meets the
requirement. If the requirements are met then further checking continues.

If the conditions are not met then the next output type will be processed from the list.

The short listed output types are checked for the access condition flag. If the flag is not set then
the output medium and timing are determined from the customer master data.

If the access condition flag is set then the processing continues for determining the output
medium and timing. For these output types the access sequence associated is access for
various business rules and determines which of the business rule is satisfied. The values from
the communication structure are checked with the values maintained in the condition tables.

Output Editing:

After the output proposal process is completed, the list of proposed outputs displays on the
output control screen of an application as shown below.
To reach he output control screen we can got for Extras ->Output->Edit for sales order or by
Goto->Messages for Purchase order.

The initial status of these outputs will be 0 (Not Processed) which is displayed as yellow light.

The processed outputs will be displayed as green light.

For EDI, the partner number in the proposed output is validated against the partner profile entry.

The flow chart below explains the Output proposal procedure.

Output Processing:

After the final selection of the output is done and the application document is saved, entries are
created in the NAST table with application ID, Application document number, output type, output
medium, output timing and Status code.

If the output is not processed the Status code will have values as 0 (Not processed).

The entries in the NAST table are processed by RSNAST00 program. If the entries whose
timing is set to immediately, the program will immediately process those entries. For other
entries you will have to schedule the program RSNAST00.

The RSNAST00 program check the TNAPR table for each entries from NAST table and
processes the program associated with the output medium in the TNAPR table.

For EDI a Standard routine EDI_PROCESSING exist in RSNASTED program.

The EDI_PROCESSING routine reads the Message control record in the partner profile and
determines the process code.

The process code will be having a Function module which will be having the standard interface
for its input and output parameters. The function module will read the application document data
and will format the data into the idoc format.

The idoc data and the control record from the function modules received through the output
parameters will be used by the EDI_PROCESSING program to convert it into physical Idoc.

The complete Outbound process with Message control is as shown below:

The setting of the Output mode field in the partner profile is read to determine the timing for
dispatching the idoc.

If the mode is set to ‘Transfer Idoc immed.’ then the idoc is immediately passed to the operating
system and if the mode is set to ‘Collect Idoc’ then the Idoc is not immediately passed to the
operating system until the RSEOUT00 program is executed explicitly.

If the flag for ‘Start subsystem’ is set then the subsystem program name is read from port
definition and the subsystem program is started.
Serialization of IDOC Message type
By Vijayendra Krishnamurthy Rao, Hewlett-Packard

Serialization for Sending and Receiving Data

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.

• Serialization Using Message Types

• Serialization Using Business Objects

In this Tutorial we will learn Serialization using IDOC Message types and the details steps
involved.

Serialization Using Message Types

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: -

• Define Serialization Groups

• Assign Message Types to the Serialization Group

In addition to the message types used, the dispatch of the message type SERDAT must be
modeled in the distribution model.

STEP 1 → Define Serialization Groups

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.

Save your entries.

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).

Step 2 → Maintain Distribution Model

Maintain the Distribution model as per the requirement and add the additional message type
SERDAT as shown in the screen shot below.

Note: The distribution model needs to have all the message types that will be distributed
between systems. It however need not have all the message types defined in the Serialization
groups.

Serialization of IDOC Message type

...Previous

Select the option from the menu to generate the partner profile

On the next screen select EXECUTE

Once you execute the system will generate the partner profiles in the sending system and
update the partner profiles with the associated messages
You can cross check the details by going into WE20 and checking the partner profile.
As seen from the above by automatically generating the partner profile the system creates the
required entries.

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.
Serialization of IDOC Message type
...Previous

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.

Once done save your entries.

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.

SETTINGS IN THE RECEIVING SYSTEM

Once you have completed the above steps in the sending system login to the receiving system
and do the following steps.

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.

To dispatch a serialization group two steps are required:

➔ The IDocs belonging to a serialization group are created

➔ These IDocs are then dispatched

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.
ALE - Error handling through workflow
By Abhijit Daptary & Siddharth Samal, Capgemini India

Pre-requisites.

It is assumed that the reader of this article has some knowledge in SAP workflow BOR objects
and ALE Idoc process like process code, Partner Profile etc.

Description

Here, we will be discussing in details the Error handling of an Inbound Idoc through triggering
an event, which in turn will be triggering a workflow attached to the workflow.

Steps:-

1. Create custom BOR object with the events, Start and Stop event
2. Create a workflow for the error handling, like generating a notification whenever an error
occurred in the Inbound Idoc.
3. Creation of Function Module and attachment with the Process Code
4. Create the settings for the Inbound Process of the Idoc through the Process Code.

Creation of BOR objects. Go to the transaction SWO1.

Enter a name for the Object type and click ‘CREATE’ button for creating the custom BOR
object.

Enter the details required for creating the BOR objects...

Create the Key fields and events of the BOR object.

For creating the Key fields place the cursor on the Key fields and Click on the Create Button

Create events for triggering the workflow and stopping the workflow.

For creating the event place the cursor on the EVENTS and Click the create button like Key
fields.

Create two events.

Enter the event name description etc and proceed further to create it.
Similarly create another event for ending the Workflow in the similar manner like that created
earlier.

Now, Generate the BOR object through the generate button

Release the EVENTS and subsequently release the BOR object.

After the creation of BOR object

Create a workflow for the generation of notification whenever an error is reached in the Inbound
Idoc.

Execute the transaction SWDD.

Click on the CREATE button for creating the workflow for error handling.

Choose the Step type to be inserted for the notification like here we are using Send Mail option
for sending a mail to the user whenever any error occurred.

ALE - Error handling through workflow

...Previous
Activate the Workflow and test it whether it is working as per the requirement.

After the successful completion it is required to attach the workflow with the event.

Go to the Header section (Denoted by CAP).

Go to the Start Events TAB.

Enter the details of the event with which the workflow should be linked like the category, BOR
object type and the event with which that should be linked.

Enter here the BOR object that has been created and give the name of event created for
starting the workflow.

Click on the Binding Button for generating the binding between the event and the workflow.
Generate the binding and click OK button to save the binding.

Click on Activate / deactivate button for activating the linkage.

After the successful linkage the following sign will appear on the workflow.....

This shows that the workflow has been linked to the event and it will be triggered whenever that
particular event will be triggered.

After the creation and successful linkage of workflow with the event it is required it is required to
generate a function module and attached it to the process code.
Go to SE37 transaction and copy a standard process code function module to a custom one. Do
no delete any parameters from the function module as the SAP standard program itself is
calling this.

In that function module do the required validation and whenever the validation fails set a
standard parameter ‘WORKFLOW_RESULT’ to 9999 from within the function module,
otherwise normally proceed to set the status to 53.

After the creation of function module it is required to attach it to the process code and
corresponding attached to the message type at the Partner Profile stage.

ALE - Error handling through workflow

...Previous

The process code is being created through the transaction WE42

Go to the change mode and click the New Entries button for creating new process code.
Enter the Process Code Name, description and choose the processing type as Processing by
function module. Click on the extension button of Identification.

The details for the of the Process Code after clicking the identification button will be
Whenever idoc arrives into the Destination system then the standard SAP triggers the Process
code attached to the Message type in the partner profile. The partner profile is being maintained
in the transaction WE20.
Since, it is and inbound scenario so the message type and the corresponding process code will
be maintained for the Inbound Parameters.

Click on Create Inbound Parameters button for creating new Inbound Message type and the
corresponding message type.
Enter the process code for the corresponding message type.

Click SAVE button for saving the changes.

Whenever the IDOC arrives into the target system, it checks the partner profile and finds the
corresponding process code. The process code is being linked with the function module through
which the IDOC is required to be processed.