Skip to Content

File to Multiple IDocs

The complexity of file to IDoc scenario depends on the complexity of the incoming file and the IDoc posting criteria. Graphical mapping becomes difficult as the complexity increases. In such cases we have to go for other
mapping options like XSLT and Java mapping.


IDocs have to be posted for every occurrence of REJFL and TROUT in the
incoming file (Please refer to the Sample file).

Sample input file:



Incoming “

Incoming “



Incoming “


Incoming “


Incoming “


Incoming “

Incoming “


Incoming “


As per this sample file, three IDocs should get posted.

In the incoming text file there can be one or more REJRS nodes
(cardinality 0 to unbounded) after every REJFL, TROUT, TRANS, MTPNT, and ADDRS.
The complexity comes as the key field value for all these reasons are the same
“REJRS”. So the file content conversion will generate a flat XML
with the same node name for all occurrences of REJRS. Message mapping is not
possible in this case as the REJRS node name remains the same through out the
file. Hence I have used XSLT mapping.

The picture below would give a better idea about the IDoc posting criteria.



A flat data type (DT_RSUPD) is created as shown.










Interface Mapping:

the interface mapping with the outbound message interface as the source and
abstract message interface as the target and use the XSL as the mapping
program( select the XSLT program imported in IA).


Integration Process:

Create a simple integration process as in the screen shot.

This integration process will receive the output of XSLT mapping and send it to ISU system as IDocs.




Create two communication channels

Sender channel with File adapter

Receiver channel with IDoc adapter

The content conversion parameters have to be defined in the sender



Receiver Determination:

There will be two receiver determinations.

1) The output of XSLT mapping is given to Integration process.

2) The output of Integration process is given to ISU system.



Interface Determination:

There will be two interface determinations accordingly.

Sender Agreement:

Mention the sender communication channel.

Receiver Agreement:

Mention the receiver channel and the sender service also as in the screen shot.



The monitoring can be done in two steps.

In SXMB_MONI give the sender service name and see if the chequered flag has come.

If you get a checked flag, then give the Integration process name as the sender service and check if you get chequered flag for that too.

In the ISU system, go to WE02 and see if the expected number of IDocs has been posted.

Hope this document could give you a better idea about the file to multiple IDoc scenarios using XSLT mapping.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Hi Anish,
            it was a great blog, at difficult times xlst really comes to rescue and showed a path!
    keep up the great work.
  2. Former Member
    A while back we implemented Business Connector. We had business requirements and we weren’t ready for XI.

    We wanted to develop our maps in a way that would simplify the porting of the maps from Business Connector to XI when the time came. Our choice was to do the mapping with XSL rather than BC flow logic.

    Your blog shows we made the right choice.


  3. Former Member
    Good job !!

    I fail to understand the need for an Integration Process in this scenario. We can have the ISU system as the direct receiver of the message from file system. Can you elaborate on this?


    1. Former Member Post author
      Thanks Praveen!

      The Integration Process is used to send multiple Idocs. You can eliminate IP if you do not have multiple Idocs to be send from the same input file. There are some work arounds to send multiple Idocs without IP also.
      Please let me know if you need any help on this.



Leave a Reply