SAP PI N:1 Mapping in AAE without BPM
Scenario: Collect IDoc’s and process them as one message .
There are lot of blogs available on processing M:1 mappings without BPM. All those blogs talk about creating an external definition for the IDoc and changing the occurrence to 0 to unbounded.
But when there are frequent changes to the IDoc structure we need to repeat the above process for each project.
So I thought why can’t we leverage the mapping signature functionality provided in the message mapping instead of creating external definition and manually changing the signature just as we do for 1:N mappings.
But the problem with this approach is that we cannot assign the operation mapping to the ICO as AAE (without BPM) supports “1:1” or “1:M” scenario’s only, but not “M:1”.
So I did a small trick to achieve this. This is a two-step process. I will only highlight the changes required at a very high level.
Change the message mapping and the corresponding operation mapping signature to 1:M as shown below and activate it.
Message Mapping (1:M Signature).
Source Message Occurrence 1 to 1 and Target Message Occurrence 0..unbounded .
Operation Mapping (1:M Signature)
Now assign the operation mapping to ICO and activate it.
You now need to change the same Message Mapping and the corresponding Operation Mapping signatures to M:1 as shown below and activate it.
Message Mapping (M:1 Signature)
Source Message Occurrence 0..unbounded and Target Message Occurrence 1 to 1.
Operation Mapping (M:1 Signature)
No change required in the ICO for the step 2. That’s all we need to do.
When you do a check on the ICO you may get a warning. Just ignore it.
Now you can execute the scenario.
The first step is required as we need to assign the operation mapping to the ICO and also the Inbound service interface signature(0 to unbounded) in the ICO. This is very important in processing the mapping during run-time, this will help to wrap the source message with the following tags Messages and Message1.
Without these tags your message mapping will not be able to evaluate the XPath for this scenario. This should not be the same case for XSLT and Java mapping.
However you will be able to execute the mapping locally in the ESR but not during the runtime without the Inbound service interface signature(0 to unbounded) in the ICO.
This process looks ok if there is no change to the operation mapping. Just in case you need to change the mapping in future(add another target message M:N scenario) then you need to go through this entire process once again. But the odds of IDoc structural changes will be more when compared to a adding a new target message.
Nevertheless this process seems to introduce more confusion both from supportability point of view and upgrade point of view. I am just writing this blog to show case that there is a work around option exists without creating external definition for IDoc.
By the way this is my first blog.
R u saying that this interface does not work during runtime ?
It will work if you follow Step 1 and Step 2.
How long will the interface collect the idocs before it processes the mapping ? Or is their any count for number of messages received before it processes the mapping ?
Wouldn’t you please clarify how does it work in runtime?
Let’s say my sender system sends three separate messages to PI system. How are these messages got collected in one multimessage structure?