1:N IDOC Receiver Without BPM. Yes It’s Possible!

For those of you familiar with PI, you know that it likes to deal with single messages, and not multiple messages in bulk. Many interfaces to “legacy” systems require single file interfaces. If you are using a file sender adapter and an IDOC receiver adapter, I have a little tip for you that will allow you to process one file into many IDOCs.

At a client of mine, I had to develop an interface to accept a file with IDOC acknowledgments. Our SAP system was sending data to an external system and the external system was sending back status messages that we were to post using ALEAUD. The status file was written periodically and could contain any number of records. Each record needed to be its own IDOC. The problem is that there is no “out of the box” solution that allows 1:N file to IDOC mapping. I searched a bit on SDN and found that there were others with my same problem. All of the responses, however, suggested using BPM. That just didn’t seem right to me. BPMs are great and all, but I don’t feel like I should need to implement a BPM to do something as simple as 1:N correlations. I set out to find a better way to do 1:N correlations with IDOCs and found that is actually was real easy.

After doing my research, I found that the issue is not with the IDOC adapter nor mapping engine, but rather the issue lies in the meta-data imported from the ECC instance. The meta-data describing the IDOCs has an element occurs of “1..1″–i.e. each message that contains an IDOC can contain one and only one IDOC. As it turns out, SAP handles the case if multiple IDOCs are passed to the receiver IDOC adapter. The mapping engine can easily handle multiple IDOC occurrence. The only limitation is the IDOC meta-data and, as I will show you below, that is an easy limitation to overcome.

1. First, in your XI integration repository, download the IDOC definition from your ECC/R/3 instance as you normally would for any standard IDOC integration scenario.
2. Complete the message mapping and the rest of the integration scenario development as usual.Notice how the source message has an occurrence of 1..unbounded, but destination message is limited to an occurrence of 1..1. If the mapping were to remain this way, no matter how many IDOC tags would be in the source XML, one and only one IDOC tag will be created in the resultant XML. We’ll take care of this next.
3. Export the XSD for the IDOC to a file on your PC.
4. Open the file in a text editor and change the element named “IDOC”. Add the following text:minOccurs="1" maxOccurs="unbounded" Save and close the XSD file.
5. In the message mapping created in step 2, import the XSD created in the previous step as the message reference for the IDOC. Notice how the evil “1..1″ occurrence constraint on the IDOC tag is now “1..unbounded”!
6. Multiple rows in the file will create multiple IDOCs! Are you as excited as I am?

So, what did we learn today?

• You aren’t completely locked into the meta-data derived by SAP.
• The reciver IDOC adapter is pretty forgiving (much more so than the sender IDOC adapter–more on that another day)
• Most importantly, it is possible for a 1:N multi-message IDOC reciver correlation without BPM!

About: Craig: Craig Stasila is a senior partner consultant with DataXstream, LLC. He has over twelve years experience with SAP integration. His specialties include ALE configuration, SAP XI/PI, and SAP.NET Connector Integration.