How to set an Async/Sync with multi mapping?

[Former Member]

Hi,

So with PI7.4 I use the async/sync bridge via adapter modules to handle my scenario IDOC (async) > PI > SOAP (sync).

• I should add that the IDOC part of the scenario is a collections via configuration of the IDOC_AAE adapter.
• And the sync response is sent to a file receiver

So when my SOAP receiver can take multiple IDOCs per single SOAP call we have a message mapping and then operation mapping of:

    1 IDOC Collection : 1 SOAP message

This works perfectly when we switch the target part of the operation mapping (the SOAP bit) to synchronous for the async/sync scenario and everyone is happy.

The challenge is now repeating the same scenario but where we have a multi-mapping so:

    1 IDOC collection (containing 1..n IDOCs)   mapping to 0...unbounded SOAP messages

Of course when I try and set the operation mapping target (the SOAP message) as synchronous I get the message saying multimappings are not supported.

So the question is how to get around this? I cannot change the fact that my IDOCs are collected as many interfaces are built of the back of that.

So options seem to be in my mind:

• Maybe split the collected IDOCs so we can get a 1:1 mapping of IDOC to SOAP which will support async/sync
• Use BPM, I've seen http://scn.sap.com/docs/DOC-34624  by but that doesn't help with the multi-mapping issue and I don't have a JMS broker
• Anything else...

I know there was a similar post http://scn.sap.com/thread/3944582 but the multimapping was on the response side and this is on the request side.

Any help much appreciated looking at all possible options.

Thanks,

Peter

[former_member182412 · Accepted solution]

Hi Peter,

Use two flows in your interface, first flow will split the multiple IDocs into individual Idocs and send it to second flow. Then in second flow in receiver channel you can include async/sync bridge. it will work because it will be only one IDoc to one soap call.

Check below blog for more details.

Regards,

Praveen.

[Former Member · Accepted solution]

Great! Thanks as always that's just what I needed. I did have an idea of looping back through PI but wasn't sure of the best way of handling that without too much overhead on the system.