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.

/wp-content/uploads/2016/03/om_multi_917181.png

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.

/wp-content/uploads/2016/03/am_payload_917182.png

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

/wp-content/uploads/2016/03/split_917189.png

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

/wp-content/uploads/2016/03/child_917190.png

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

/wp-content/uploads/2016/03/log_917253.png

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.

To report this post you need to login first.

7 Comments

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

  1. Jegatheeswaran Pitchaimuthu

    Hi Eng Swee

    Thank you for the blog.

    We followed this design in our IDoc ibound interfaces. (File to IDoc).

    Business has asked some attributes from the payload in the alert email messages.

    I have configured the same (UDMS attributes – NWA) by referring the Outbound Service interface which is for file.

    When the message splits, UDS attributes appeared in the Outbound message, inbound messages did not have, i.e split idoc messages

    When the split message is failed, the alert e-mail messages did not have UDS attributes.

    Then I changed the UDS configuration by referring fields from the inbound interface i.e IDoc.

    After change, UDS attributes are displayed in each individual split idoc messages, but the alert is triggered only for first message with UDS.

    Remaining inbound messages though failed with UDS attributes in MM the alert is not triggered. i.e When I check the alert job log, it says no alerts are suppressed and no alerts are aggregated. (I tried this test by stopping IDOC_AAE receiver channel)

    I could not understand why.

    One thing we observed that this problem comes only for split messages.

    Could you please clarify how to overcome this with this approach?

    (When I switch to older format (IDoc XSD), an alert e-mail message comes correctly with UDS attributes for all records which is in the message since it is only 1 message)

      

    Thank you.

    (0) 
    1. Eng Swee Yeoh Post author

      Hi Jegatheeswaran

      Thank you for your comment. However, it would be more appropriate to raise your issue as a thread in the forum instead. Your issue require more details for a thorough analysis and it is not suitable to be done over the comments section here. Additionally, other members would be able to contribute to the analysis as well.

      When you raise your thread, please include as much specifics and examples for your case (i.e. sample source and target payloads, screenshot of errors/alerts, UDS configuration). Please also provide the PI version and SP level.

      Regards

      Eng Swee

      (0) 
  2. Daniel Graversen

    Hi

    Great blog.

    It does make sense some times to use the split mecanism that you provide here and in most cases it will be okay.

    It gives some more visibility to the number of messages that you have in the payload.

    though this can also make it less visible to what else is being processed.

    I belive that the bundled idoc will make less strain on the PO AEX system because there is not all the extra processing about creating new spit messages.

    (0) 
    1. Eng Swee Yeoh Post author

      Hi Daniel

      Thanks for your feedback.

      Regarding the strain on the system, is this a hypothetical assumption or based on real-life experience that you have encountered? I have used this split mechanism over many interfaces on many systems and have never experienced any negative performance impact caused by it.

      Do you have any statistics of such performance comparison to back this up? This would help others to take this factor into consideration when designing such interfaces.

      Regards

      Eng Swee

      (0) 
  3. Nidhi Srivastava

    Hi Eng,

    We are having a requirement where we need to have multiple idocs at the source.810 INVOIC ANSI X12 is there, where we need to pack the idocs and send those as a single message.

    Do we just need to change the occurrence and it will work or we need to do necessary settings in ECC systems as well.

    Please advice what all needs to be checked.

    Thanks,

    Nidhi

    (0) 

Leave a Reply