Stop using External Definition for 1-N IDoc multi-mapping ©

Introduction

Let’s take a stroll down memory lane

In the early days of XI 3.0 and PI 7.0, it was not uncommon to come up with workarounds to meet the various integration challenges. One common requirement is to post multiple target IDoc messages from a single source message. This required a 1-N IDoc multi-mapping (also called mapping-based message split). Back then, there was a restriction for mapping-based message split as described in the below snippet from the blog Multi-Mapping without BPM – Yes, it’s possible!

Messages that result from the split in a mapping-based message split are sent using one AE. So only adapters running on the AE are supported. In particular, this means that target IDOC message splits are not supported since the IDOC adapter is not part of the AE.

As the IDoc adapter was ABAP-based in those dual-stack days, this meant that such splitting was not possible for target IDoc interfaces in the “truest sense of the word”. However all is not lost, as the workaround for such a requirement is to change the occurrence of standard IDoc by exporting the standard IDoc schema, changing the root node’s occurrence to “unbounded” and reimporting it as an External Definition.

Fast forward a few years and in PI 7.11 the restriction mentioned above has been removed (I’m not sure of the behavior in a PI 7.1 system as I didn’t work on one). Although the IDoc adapter was still ABAP-based (IDoc_AAE was only introduced in 7.3x), the behavior of the adapter has changed.

In various client systems I have worked on, as well as on SCN’s forum, it is evident that the workaround using external definitions are still used for IDoc interfaces. As the restriction has been removed, it is no longer necessary to use an external definition for IDoc when performing mapping-based message split. As this is a lesser known fact in the community, therefore this post aims to highlight this and to bring awareness of the redundancy of the above mentioned workaround.

Example

Below is an example scenario of how 1-N IDoc multi-mapping can be achieved without using External Definition. This example is based on a single stack system which uses IDoc_AAE but conceptually it applies to the ABAP-based IDoc adapter on any dual stack system since PI 7.11.

Instead of using an externally modified IDoc definition, we can just use the imported IDoc definition as the Target Message/Operation in Message/Operation Mapping. For the Occurrence column, change it from 1 to 0..unbounded.

When end-to-end testing is performed, we can see that the output of the multi-mapping produces the <Messages> and <MessageN> nodes wrapping the IDoc structure. This verifies that a mapping-based message split has occurred.

The audit log shows that the mapping has split the message into multiple child messages.

Upon viewing the child messages generated from the split, it shows that the <Message> and <MessageN> nodes are automatically removed from the child payload.

And finally, the child messages are delivered to the IDoc receiver channel and processed successfully.

Conclusion

As detailed in this article, the workaround using modified External Definition is no longer required to achieve 1-N IDoc multi-mapping. Instead this can be easily achieved by changing the Occurrence in the Message/Operation Mapping. Hopefully this will help raise awareness in the community, thereby removing redundant and unnecessary workarounds during the development of 1-N IDoc interfaces.