Enhanced Interface Determination - does not work!

[Former Member]

Hi guys,

well i have a scenario where i have done a multi mapping where MT_TYPSCH is generated for each new value which occurs in one special source field.

<NO>1</NO>

<NO>2</NO>

<NO>3</NO>

..so three MT will be generated.

Now i would like these messages devided to different Business Services where each one has on FTP-CC to write a file with a certain filename, e.g. File1.txt, File2.txt, File3.txt.

Therefore i thought i use different receivers in Receiver Determination with using Conditions and pointing to a value in field with XPATH. So depending on field <NO> the message should be routed to the given receiver targets.

I surely use the enhanced Interface Determination because i use multi mapping.

But when i run test, i receive 3 files with different names but same content. For me the receiver determination is not working that good.

Can someone help me on this?!

source:

<ZBC0>

<IDOC BEGIN="">

<EDI_DC40 SEGMENT="">

<ZBC0 SEGMENT=""> 0...9999

<NO>1</NO>

<TYPE>1B20-6</TYPE>

<SPEC>152J</SPEC>

</ZBC0>

<ZBC0 SEGMENT="1">

<NO>2</NO>

<TYPE>1B20-6</TYPE>

<SPEC>152J</SPEC>

</IDOC>

</ZBC0>

target:

<?xml version="1.0" encoding="UTF-8"?>

<MT_TYPSCH> 1..1

<TYPSCHRecordSet> 1..1

<TYPSCHDetailsStruc> 1..unbounded

<FELD1/> {represents content of <No>}

<FELD2/>

<FELD3/>

</TYPSCHDetailsStruc>

</TYPSCHRecordSet>

</MT_TYPSCH>

[henrique_pinto · Accepted solution]

As far as I've understood, there is a misconcept here, on how Receiver/Interface Determination works.

If I've understood it right, you have one sender and 3 receivers, where each receiver should receive 1 tag of the input message (NO = 1 should go to receiver1, NO = 2 should go to receiver 2, NO = 3 should go to receiver 3). Is that so?

If that's the case, the easiest solution would be as described below:

- in Receiver Determination, create simple routing conditions to select the receiver: NO = X -> receiverX.

Notice that the routing conditions within Receiver Determination are always based on the input message and not on the the output. Hence, if you have message as in your example (with 3 occurrences of NO, each with a different value), then all 3 receivers will receive the message above.

- in Interface Determination, use a different mapping for each of the possible receivers, each mapping program handling a different value of NO (e.g. Mapping_NO_1 for receiver1, Mapping_NO_2 for receiver2, Mapping_NO_3 for receiver 3).

That way, you'll make sure that each receiver receives only the tags which are relevant for it. A unique mapping program could be used instead of 3 different mapping programs, but the logic should not be simple split (multimapping); it should be to read which is the receiver of the message during runtime (reading message header) and then choose which tags to map. This would prove to be really complex if you consider that the systems' names will be different accross the diferent landscapes (DEV, QA, PROD). Separate mappings are much easier to handle.

Regards,

Henrique.

[Former Member · Accepted solution]

Hello Henrique,

that's exactly what my requirements are and what i intended to do!

But because i am not that good in mapping i have problem to implement the mapping.

I now did the following:

I took the isEqual function and compare the constant 1 with the value in <NO>. unfortunately this does not work! (or do i have to use "1")

Which function do i have to take?!

Could you give me a step-by-step solution - if you don't mind?!

I am quite a beginner on this!

br

[henrique_pinto · Accepted solution]

Hi Fritz,

make it like this.

NO -> RemoveContexts -> EqualS -> FieldX
                       /
            Constant[X]

Of course, X is 1, 2, 3..., one for each mapping you need to create.

Regards,

Henrique.

[Former Member · Accepted solution]

Hi Henrique,

finally i found it by myself - but thanks at all!

br

[Former Member]

hi ,

You can go through the blog given below :-

1.https://www.sdn.sap.com/irj/sdn/wiki?path=/display/xi/enhancedReceiverDeterminationinSAP+XI&

2.

Regards

[Former Member]

Hi Fritz,

"But when i run test, i receive 3 files with different names but same content. For me the receiver determination is not working that good."

It is not the receiver determination. It is your mapping that generates the error!

On the other hand I don't understand:

You wrote you use the enhanced CC. On the other hand you write you use XPATH.

Both at the same time is not possible. What are you really doing?

Regards Mario

[Former Member]

Hi Mario,

ok here is my requirement.

We get ONE IDoc in which several items are listed. These have one field <NO> which can have the values 1,2 and 3. Depending on this value the items should be collected and written to different files on FTP.

My approach is that i divide all the items in mapping in different Message Types. This MT should be routet to different business services which has one CC to write on FTP.

To get the items with e.g. <NO>1</NO> i took condition in reciever determination using xpath. ((/ZBC21/IDOC/ZBC21/NO = 1).

So depending on the mapping everything runs - in my point of view but the different messages are not routed to the different services to write them to different files.

Source

<ZBC0>

<IDOC BEGIN="">

<EDI_DC40 SEGMENT="">

<ZBC0 SEGMENT=""> 0...9999

<NO>1</NO>

<TYPE>1B20-6</TYPE>

<SPEC>152J</SPEC>

</ZBC0>

<ZBC0 SEGMENT="1">

<NO>2</NO>

<TYPE>1B20-6</TYPE>

<SPEC>152J</SPEC>

</IDOC>

</ZBC0>

target:

<?xml version="1.0" encoding="UTF-8"?>

<MT_TYPSCH> 1..1

<TYPSCHRecordSet> 1..1

<TYPSCHDetailsStruc> 1..unbounded

<FELD1/> {represents content of <NO>}

<FELD2/>

<FELD3/>

</TYPSCHDetailsStruc>

</TYPSCHRecordSet>

</MT_TYPSCH>

The output should be files with content of items depending on field <NO>.

file1.txt (all items with <NO>1</NO>)

file2.txt

file3.txt

I hope i made it clearer!

br

[Former Member]

Hi Fritz,

That XPath is used to whole message so it will take first value. In your case you cannot make a split on adapter engine because it's to late.

My proposal is either:

a) use one file directory where you will just split messages and later in other one to one step read it and route them

b) use bpm

/wg

[Former Member]

Hallo Fritz,

do you have a BPM that splits the message?

If yes: Your XPATH is checking the source message, but I guess your BPM sends the already splittet IDOC. So you have to "XPATH" your target message.

Regards Mario

[Former Member]

Hi because i don't want to use BPM i tried the workaround given in a)

But when i try to use xpath on the message type of the read text-file, i am not able to chose anything.

Does somebody can give my a big hand on this - independent from this workaround?!

br and thanks to all so far!

[Former Member]

Hi,

I'll try to elaborate more about it. In second step you need to have some outbound interface the same as inbound in first step.

it should look like that

first step (split on adapter)

outbound 1 -> inbound 1 (like in the blog with message split)

second step

outbound 2( the same as inbound 1) -> here receiver determination -> inbound 2( the same as inbound 1)

Kind regards,

Wojciech

[former_member182455]

Hi

check this one

3 Inbound Interfaces, with 3 separate Interface mappings, one for each Idoc. You need not specify any Condition in the Interface Determination.

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

regards

srinivas

[Former Member]

Hi, but we have the requiremnt that we have to collect the data and write to three different files depending on the value in <NO>.

The source file is one IDoc!

Does this match your suggestion?! Can u help?!

br