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.
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
WHSORD./AFS/DELVRY03(MessageType.IDOCType)
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).
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.
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)
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.
6 Comments
