complex interface determination fails for 0-N mappings

[Former Member]

We have a mapping question for the following scenario in PI 7.1: One message needs to be mapped into two target structures, it comes from the same sender and goes to same receiver. We need to call two different BAPI in the same SAP end system simultaneously.

This is set up in one interface determination (same sender & receiver) where we use two different operation mappings with different receiver interface names. If the mapping have multiplicity 1, everything works fine and the message gets mapped to both receiver interfaces simultaneously. But, when the multiplicity of the mappings is 0-N (split mapping), then we get error message during interface determination phase:

Error when determining the inbound interface: Inbound interface found several times (for same sender and receiver) for the outbound interface http://sending/namespace.sndInterfaceName

How can we set up our scenario with two 0-N mappings without getting error message? One option would be combining two mappings in one, but this can not work in our case because of the high complexity.

Any comments appreciated. Thanks, Sanjay.

Edited by: Sanjay Gupta on Oct 21, 2010 10:50 PM

[Former Member]

Hi Sanjay,

With this issue, u r using two operation mappings each having multiplicity 0...unbounded in a single interface determination. However, sender & receiver communication components are same.

So, at runtime, when this interface determination gets executed, due to being multi-mappings - receiver interface will be always "InterfaceCollection" & receiver namespace will be always "http://sap.com/xi/XI/System" in SXMB_MONI. And this value will remain same even if we add one more multimapping to same interface determination.

Hence, at runtime, all inbound interfaces will be with same name for no of multimappings used irrespective of their physical name in ESR. That's why u get an error "Inbound interface found several times (for same sender and receiver) for the outbound interface".

But, if we use two mappings each having target occurence as 1 in a single interface determination, no of inbound interfaces name will be unique both at runtime & physical name in ESR which results in no issues.

Hope it clarifies now. Please revert , if we still have any doubts.

Thanks,

Anoop Garg

[Former Member]

Dear Anoop,

thank you for your exact and detailed explanation of the error cause. Independently of this thread, I came across the same issue today and also identified the name "Interface Collection" assigned at runtime to the reciever interface as error cause.

I am still looking for a solution. Unfortunately, I cannot combine my mappings into one.

Is a possible solution, to use the several (I have 3 of them) receiver interfaces with different receiver communication components such as business components?

Thank you in advance,

Joerg

[Former Member]

Hi Joerg,

Yes, ofcourse we can build in similar way to technically make it work.

Or , u can have a one common receiver component in receiver determination. With this corresponding receiver component, create interface determination but along with virtual receivers also for each of diff mappings.

Please revert, in case of issues/trouble with this.

Thanks,

Anoop Garg

[Former Member]

Thanks for all the answers, and good to know its not supported. Still doesn't make much sense to me. I've merged the two mappings into one true multi-mapping which includes message split too and now everything works, even though its not supported. Thanks again.

[stefan_grube]

> How can we set up our scenario with two 0-N mappings without getting error message? One option would be combining two mappings in one, but this can not work in our case because of the high complexity.

This is not allowed in a sync scenario.

You could create an RFC wrapper for the BAPIS, so the wrapper calls both BAPIs inside or you could use BPM.

[VijayKonam]

I have the below questions to comment on your query -

1. Are you using multi mapping? Source Message type 1 and Traget message types 2 (added from messages tab in the mapping)

2. At any time, can both the target messages be created or are they mutually exclusive?

3. With in each message type that gets generated on the target side, is the occurance 1..1 or 1..unbounded?

4. Is there any condition in the interface determination?

5. How many operation mappings did you design.

Being said that, the ideal way should be,

You need to create only one message mapping by adding multiple message types on the target side. Care should be taken when a target message needs to be created. In the interface detrmination, when you select this operation mapping, automatically it will ask you to provide the associated receiver interfaces.

VJ

[Former Member]

Thanks for taking the time to look into this. See my comments below.

1. Are you using multi mapping? Source Message type 1 and Traget message types 2 (added from messages tab in the mapping)

We have two mappings, both create only a single output type, however, they are split mappings, meaning the mapping result message multiplicity is 0-N. So the answer is NO, this are no multi mappings

2. At any time, can both the target messages be created or are they mutually exclusive?

both targets will always be created, they are NOT mutually exclusive

3. With in each message type that gets generated on the target side, is the occurance 1..1 or 1..unbounded?

Don't fully get the question, but I assume you ask if the mapping is defined as a 1:1 or 1..N mapping. The latter is true.

4. Is there any condition in the interface determination?

Answer is No.

5. How many operation mappings did you design.

We have two operation mappings, each containing a different mapping to the different receiver interface type.

Being said that, the ideal way should be, You need to create only one message mapping by adding multiple message types on the target side. I fully understand and agree with this statement, but due to the complexity of the mapping we need to separate it out into two mappings.

It is confusing, that the described scenario works if the multiplicity of the mapping objects used is 1, but as soon as the multiplicity is 0-N (when using a split mapping instead), we start getting the error message.

[Former Member]

As you have two mappings, each mapping you specify 0:N, it is message split and this is one type of multi-mapping,

In this case you have to use Enhanced Interface Determination (Not standard interface determination)

, please see the SAP doc below

Enhanced (Mapping-Based) Interface Determination

http://help.sap.com/saphelp_nw04/helpdata/en/42/f3b31d48fb1bc8e10000000a11466f/frameset.htm

Regards

Liang

[Former Member]

Thanks for your answer, let me add some clarification. None of the mapping objects are multi-mappings. A multi mapping is a mapping with different target message types, regardless of the multiplicity. But in our scenario we have two separate mappings with a single target message type (nut multiplicity 1:n) each. These are considered split mappings and not a multi mappings. For details refer to: http://help.sap.com/saphelp_nwpi71/helpdata/en/42/ed364cf8593eebe10000000a1553f7/frameset.htm

Edited by: Sanjay Gupta on Oct 22, 2010 2:01 AM

[Former Member]

Your concept is wrong, my friend.

Message split is one type of multi-mapping, target message could be one or multiple types of messages

if target message is one type, but its occurrence is N, it is also considered multi-mapping, I think this is your case.

Check:

http://help.sap.com/saphelp_nwpi71/helpdata/en/42/f3b31d48fb1bc8e10000000a11466f/frameset.htm

Similarly for message merging. And most complex multi-mapping is that there are multiple source message types, and multiple target message types, this is M:N multi-mapping.

You have not answered my question yet, did you use standard interface determination or enhanced interface determination ?

Regards

Liang

[Former Member]

When you say split mapping, I guess you changed the occurance of target MT to unbounded in 'Messages' tab of mapping and created a mapping logic to generate n messages of same type.

In this case you need to use enhanced interface determination since it is a multi mapping

[Former Member]

Lian,

i guess in Pi 7.1 we dont have a seperate tab for enhance intrfc dtrmntn , it was there in 7.0

@Stephen,

can u please put some more light , why we can;t have multimapping in a synch scenario?

sounds interesting.

[stefan_grube]

> can u please put some more light , why we can;t have multimapping in a synch scenario?

Because this is not allowed.

[VijayKonam]

Hi,

Sorry that I missed out on the SYNC thing. Even if you think logically a sync call being sent to two systems is not logical because, if the message is delivered to them, both of them would respond and there are no two separate entities present on the sender side to receive the response.

I sync call is a single channel communication and can not be split in to multiple calls and response consilodiation unless we use BPM or as Stefan suggested, using an EFC wrapper.

VJ

[Former Member]

Me too. Also thanks biplab das for the reminder of non-exist of enhanced interface determination in PI 7.1.

Liang

[Former Member]

This doesn't make a lot of sense to me. The scenario works, if the mapping is not a split (or multi or however you call it - mapping, you know what kind of mapping I mean).

One the one hand I can execute both mappings at the same time (via interface determination), if the mappings are 1-1 mapping, but as soon as they are 0-N mappings it doesn't work anymore and give above stated error message.

Also, to add some more clarification, we are not using a SYNC scenario but an ASYNC scenario. I just found the receiver channel is ABAP proxy and not ABAP BAPI. Sorry for the confusion.

[stefan_grube]

> Also, to add some more clarification, we are not using a SYNC scenario but an ASYNC scenario. I just found the receiver channel is ABAP proxy and not ABAP BAPI. Sorry for the confusion.

I would appreciate when peobple try to give exact information.

It is indeed very important, which adapter is used.

When you use ABAP proxy, then I have to say that multimapping (1-n mapping) is not supported at all, neither sync nor async.

I think, this is mentioned in online help.

In an ABAP proxy you have the possibility to enhance the interface to handle the whole payload. So you would need no 1-n mapping. I recommend to avoid any 1-n mapping whenever possible.

[Former Member]

Hi Stefan, could you please kindly point me to the right documentation, I couldn't find any mention of this not being supported at all.

Thank you.

[Former Member]

Refer the prerequisites in the document-

http://help.sap.com/saphelp_nw04s/helpdata/en/42/f3b31d48fb1bc8e10000000a11466f/content.htm