cancel
Showing results for 
Search instead for 
Did you mean: 

How to handle 0 messages in multi-mapping

Former Member
0 Kudos

Hello,

We have a working scenario where a single asynchronous message goes through operations multi-mapping (with XSLT and visual mapping steps) and then goes through BPM for async-to-sync conversion.

We have some valid cases when the initial asynchronous message produces no outgoing sync messages due to filtering that we implement in XSLT steps of the operation mapping.  This currently results in an error status in SXI_MONITOR issuing the "Split mapping created no messages".

What is the appropriate mechanism to handle scenarios when we really don't have any valid sync messages and we don't want the initial async message to show up in error state in SXI_MONITOR.  I realize this is a tricky question because this needs to be conditional.  For example, if we have no messages from step 2 to 3 (XSLT) in our operation mapping then we consider that to be acceptable (no error), but if there are messages after step 3 (XSLT) and we produce no messages in step 4 (visual mapping) then we do want to see an error in SXI_MONITOR.


For now I am thinking we just have to live with these errors and since they will happen very infrequently this is not a big deal, but was wondering if anyone has ever run into a similar scenario.

Best regards,

Anton

Accepted Solutions (1)

Accepted Solutions (1)

udo_martens
Active Contributor
0 Kudos

Hi Anton,

unfortunately the receiver determination is executed BEFORE the mapping, therefore a condition would not help there.

You could create a Enhanced Receiver Determination where you use nearly the same operation mapping. You just add one mapping program where you put a condition: In case there are 1-unbounded messages you put a static receiver, in case of 0 messages no receiver. Then you mark the determination correspondingly: If no receiver determined => no error.

Regards,

Udo

Former Member
0 Kudos

Udo,

Looks like Enhanced Receiver Determination will work in principle.  Thank you for pointing me in that direction.

Here is the part that bugs me.  This approach now couples the operation mapping logic (which is specific to each 3rd party) with receiver determination logic.  And this is already going to cause an issue for me.

Right now we have condition-based receiver determination where we check the receiver system in the header of a standard SAP XML message (through XPath) to determine which integration process and thus operation mapping to send it through.  We are using the same type of outbound XML message (and thus same standard XI content interface) for 2 different 3rd parties.  The mapping to these 2 parties cannot be part of the same operation mapping because the timing of sending the message is different.  So we control the timing logic in the SAP application (Transportation Management in this case) but send the same type of message (TransportationOrderRequest_Out) in both cases.  Hope that makes sense.

If I try to use Enhanced Receiver Determination, like you said, I basically have to duplicate my operation mapping and add one more step that produces the Receivers message at the end.  Since operation mapping is 3rd party specific (what we send to one party does not necessarily need to be sent to another party), this means that I cannot just copy the operation mapping that I have in place for one of the parties for ReceiverDetermination purposes.  Instead I have to create a merged operation mapping that takes into account all possible 3rd parties involved, and in the process not only duplicate some of the logic that I have in individual operation mappings but also add a whole new level of complexity.  This is all goes back to what I said originally - coupling operation mapping to logic to receiver determination logic seems like a very bad design.

So now I am wondering what is the lesser of 2 evils - seeing error messages for blank inbound messages or creating a "monster" for receiver determination.


Your further thoughts would be much appreciated.

Answers (1)

Answers (1)

iaki_vila
Active Contributor
0 Kudos

Hi Anton,

I was wondering that may be you could avoid this error creating a "special" message, then after the three step you ask for a value in a determinate tag, if the condition is true you will send to a Z RFC a petition and you log all the error cases and no error would produce in sxi_monitor.

Regards.