Skip to Content
Author's profile photo Former Member

Using Pre-Maps

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Michal Krawczyk
      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 🙂


      Author's profile photo Former Member
      Former Member
      Blog 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)


      Author's profile photo Michal Krawczyk
      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:)


      Author's profile photo Lukas Rampa
      Lukas Rampa
      Michal, can you give us more details about mapping export from IR? Trying to click everywhere with no effect... 🙂
      Author's profile photo Lukas Rampa
      Lukas Rampa
      Sorry, got it already: XI: Mapping Tool Exports
      Author's profile photo Former Member
      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.