Skip to Content

Hello Everyone,

I wish to share a technical challenge i faced in one of our client’s PI environment and how we went about resolving the issue. Let me explain it taking one specific scenario, where in, we designed an interface to send delivery documents from the client’s SAP AFS system to the client’s warehouse management system(mainframe). Technically put, Delivery IDOCs(/AFS/DELVRY03 IDOCs) triggered from SAP AFS to PI, will be delivered to a JMS queue(after transformation of the IDOC-XML to a legacy format XML using a Message Mapping and after content conversion to a fixed length JMS message in the JMS adapter) from where legacy systems could access the delivery document data in their needed format.

Initially, we used the standard IDOC(WHSORD./AFS/DELVRY03), the PI interface was designed, developed, unit tested and was all set for integration test. As we proceeded furthur in the Build phase, we had to build additional interfaces to few other systems that needed the delivery document data. Sounds familiar, isn’t it, immediate solution that pops to our mind is to add multiple recievers to the reciever detrmination object and we are good. Well, the catch here is that,  few of these new business systems needed some additional information in the delivery document(that is not available in the standard delivery IDOC structure). This too is common in PI implementations where  the SAP representation of a customer or a material is not the same as how a customer or material is represented in legacy systems.

So, to accomodate this, we decided to extend the standard delivery IDOC and add custom(Z) segments with the additional fields needed for other interfaces. this too sounds familar, isn’t it ? any typical PI implementation will face changes to metadata in the middle of build phase, ofcourse, with valid business justifications.

If you ask, how this change impacted the already built interface ? i have shown it below pictorially, now, we have two objects under “Imported Objects” in PI design time, instead of one.

Imported Objects

Previously, the root node of the the root node of the IDOC in the Message Mapping was the IDOCType, like shown below pictorially and the sender interface used to be

Standard IDOC

Now, after the extensions were added to the IDOC and released, the sender interface is ZE_AFS_DELVRY03.WHSORD./AFS/DELVRY03(ExtensionName.MessageType.IDOCType) and the root node of the IDOC in the message mapping is the extension name we had given to the delivery IDOC in SAP(ZE_AFS_DELVRY03, in this case).

Extended IDOC

Now, we loaded the extended IDOC in the already built message mapping, ZAP, it just removed the mappings for all the fields we had done previously using the standard IDOC. This is a normal(!!??) behaviour in PI message mapping editor.When you change the root node of your metadata you know you are in for some trouble. Redoing the mappings was the last option we had in mind, with pressing deadlines, and the mappings being fairly complex(with multiple lookups and user defined functions). Hope now, you got a hang of the issue at hand.

The Solution

We introduced a “pre-map” in PI to address this issue. Since, we do NOT need the new extended segments in the delivery IDOC for the already built and tested interface, we created a new Message Mapping in PI, using the Extended delivery IDOC metadata as the source and the standard delivery IDOC metadata as the target. This mapping is extremely simple. We just choose the IDOC node in both the source & target MTs and select the ICON “Map Selected Fields and Substructures if Names are identical”.All the data needed for this interface now gets mapped to the target.

Xtended to Standard

Now, i updated the existing Interface Mapping to call both these Message Mappings in sequence,
1) Newly created message mapping(Extended to Standard)
2) Already existing message mapping(Standard to Legacy)

Interface Mapping

Then we proceed with changes to the integration directory objects(this is because the sender interface has now changed).We have this interface, now up and running, in very good shape with no issues, and we could see that any performance hit, we had thought, would occur in executing this pre-map, is negligible.

When you choose to have a GBO(Generic Business Object) approach for your integration objects, meaning, when you plan to have one and only one common global representation of a Business object in your integration landscape, then using “pre-maps” could come in handy. Hope you found this an interesting blog. I also intend to write in future about using “post-maps” in integration projects. So, if interested, keep reading.

To report this post you need to login first.


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

  1. Michal Krawczyk
    hi Saravana,

    one more quicker method to do this
    is to export the mapping (to mte file)
    open it in notepad – change the main
    segment name to Z…) and import it again ๐Ÿ™‚
    all mappings are preserved and you can use Z idoc ๐Ÿ™‚ it takes one minute to do that
    and developeing a new mapping might take a little more ๐Ÿ™‚


    1. Former Member Post author
      I did try creating Mapping templates, i either got out of scope errors or it asked me to choose a DT or a complex type. Can you eloborate furthur on this method ?
      IMHO, creating a new map & use them in sequence will be a much cleaner & trackable than exporting and changing it outside XI editors(if its possible with one export like you have said)


      1. Michal Krawczyk
        hi Saravana,

        no no:)
        not a mapping template ๐Ÿ™‚
        you can export the mapping from IR
        to mte (xml) file – (ctrl+shift) right click
        and them you can change it from there

        no easier way I assure you:)


  2. Former Member
    Thanks for sharing your real time experience, Saravana.
    However,I have a doubt here: When you transformed the Custom idoc with zsegments (newly added to accomodate
    fields in the new target system) with the standard idoc then did not you loose those new fields in the
    first mapping? As the custom segment/fields do not exist in the stahdard idoc, as was the original issue
    Please correct me if I am wrong.



Leave a Reply