Different Systems, same Configuration in ID, but different Result?!

[Former Member]

Hi guys,

i´m working on a Idoc to File Scenario, which works in our development environment (DXI) but fails in our test environment (QXI)

first of all some information about our system landscape.

We are using 3 XI Systems for development (DXI), test (QXI) and production (PXI).

For some reason we don´t have one central SLD, but 3 SLD (one for each XI System)

So the Repository content could be transported via File, the configuration in ID is environment specific (not transported) and have to be maintained manually.

As I sad above the scenario is Idoc to File, more exactly it is 1 Idoc to 2 files.

The result files of one idoc are used to have the "same" file name pattern for example

file 1 = file2_TIMESTAMP.idoc

file 2 = file1_TIMESTAMP.eds

The order of the files is important. file 1 should be created first, file 2 afterwards.

in this pattern TIMESTAMP is the timestamp should be the same for both file, so I use the timestamp of the XI message of the idoc

(=> StreamTransformationConstants.TIME_SENT)

the content of the file differs. While file 2 contains one text line with some control information (static and some payload data), contains the file 1 the idoc xml, but with a

different codepage (ISO-8859-1 instead of UTF-8)

To get the wright content and filename, 2 java mappings are used, that are referenced in interface determination. furthermore the order of the files should be maintained, so that file 1 (idoc xml) should be created first, and file 2 (control information) afterwards

(filename mapping is done via Dynamic configuration)

As I sad at the beginning the whole scenario works fine for development environment, but fails for test.

In test the 2 files are created with the correct filename, but the file content of the file 1 is wrong. It contains the same content then the file 2 (control information)

when i have a look at the apap monitoring sxmb_moni the message content after java mapping is correct for both files.

but in message monitoring (RWB) the file 1 has the same content as file 2, which is incorrect.

Directory content of development and test are the same.

why is the result different?

anybody has an idea.

This error drives me crazy

Kind regards

Jochen

[Former Member · Accepted solution]

Jeez Jochen this is scary.

Is the message id's in the AE and the one's in smxb_moni the same?

Rod

[Former Member · Accepted solution]

Good question! That info might be important to diagnose the prob.

regards

Suddha

[Former Member · Accepted solution]

Hi @ll;

unbelieveable but true

it is the same, i already checked this.

I take the ID from the message Header in ABAP and put it in the Search Formular in RWB.

and it get the exactly this message.

but as sad before in adapter engine the content is different.

crazy, isn´t it

Kind regards

Jochen

P.S. is there a possibility to have a look in between ABAP and Java Stack to get more information where the content is changed.

[Former Member · Accepted solution]

check the content in Message content in RWB

Thanks,

Beena.

Edited by: Beena Thekdi on Aug 11, 2008 5:20 PM

[Former Member · Accepted solution]

Hi Beena,

thanks for your answering.

I already checked the content in rwb.

The content from intergration engine differs the content from adapter engine, but I do not konw why.

configuration is identical.

thanks in advance for helping

Kind regards

Jochen

[Former Member · Accepted solution]

Hi Jochen,

That means,

The message ID (in SOAP Header) in moni is the same as that in RWB - AE monitoring - but the message content is different in these two instances.

Could this be a problem while retrieving the message from the Receive queue...............the application retrieving the wrong message before delivering it to the File Channel. Since the IDoc message is splitted in the Interface Determination Step - is there any Parent Message ID to this individual messages?

I am still trying to think of a reason behind such behaviors!!!!!!!!!!!!

Suddha

[Former Member · Accepted solution]

Hi Suddha,

thanks for your help.

obviously something like that must be the reason for that behaviour.

I compared the audit logs of a succesful message (DXI) and a failed message (QXI)

there was only one difference between this to messages.

In the QXI there was a entry like "process the underlying message of mulit-message-ID xxxxxx"

I have searched both the RWB and the integration server for thismsg-ID, but without success.

I forgot one detail.

There is one difference between development environment and test.

In test and production we have two java nodes. In development we only have one single java node.

Could this be of any influence on a scenario like that?

Could this be a problem while retrieving the message from the Receive queue...............the application retrieving the wrong message before delivering it to the File Channel
Since the IDoc message is splitted in the Interface Determination Step - is there any Parent Message ID to this individual messages?

In RWB the messages from the Integration Engine have a reference and a parent msg id, but the adapter engine message don´t.

In this point there is no difference between DXI and QXI.

maybe somebody have another idea how to get more information about this error

Kind regards

Jochen

[Former Member · Accepted solution]

Hi guys,

I made some progress in error analysis.

It seems that this error occurs only if I use an adapter based on the adapter engine.

I changed the adapter to soap adapter and it has the same behaviour.

When I disable the option "maintain order at runtime" in interface determination both files are created with the correct content in it.

It seems to be a problem with EOIO.

As mentioned earlier in development environment this error doesn´t occur.

may be somebody could give me some more advices based on this behaviour?

Kind regards

Jochen

[Former Member · Accepted solution]

Hi guys,

Meanwhile I found the reason for the error.

It was caused by a runtime parameter in sxmb_adm .

We had enabled the function "packaging" for performance purposes.

I defined an exception rule for my scenario, so that packaging is not used.

And now the scenario works fine.

Of course now I ask myself, if this a correct/normal behaviour of XI?

Kind regards

Jochen

[Former Member · Accepted solution]

Hi guys,

my problem is solved and there was no more comment to my last post, so I

close the thread.

Thanks for helping

Kind regards

Jochen

[Former Member · Accepted solution]

Hi @ll,

my solution was just a workaround.

This behaviour was caused by bug in SAP XI, that was solved by SAP Note.

this thread shows further information

[Thread|;

Kind regards

Jochen

[Former Member]

You said that the scenario is particularly 1 IDoc to 2 Files, so do you use 1:n mapping for splitting the IDoc message (using Java Mappings)?

If so please check in the interface determination step if you are using Enhanced Interface Mapping and the correct interface mapping is referenced in there. At the same time please cross check if the interface mapping is also correctly using the two Java mappings.

Regards,

Suddha

[Former Member]

Hi Suddha,

many thanks for your answer.

For mapping the Idoc to the 2 files i use 2 Interface Mappings.

Both of them are referenced in the interface determination, so that at runtime the incoming idoc message is duplicated and

two "child" messages are created.

One child goes through the InterfaceMapping 1, which generates the file 1 (idoc xml with special codepage)

the other goes through the InterfaceMapping 2, which generates the file 2 (single text line with control information).

I checked the pipeline steps in the integration server. The messages are correct splitted and mapped.

the mapping results are correct.

but as I sad before the content changes from integration server to adapter engine, so that the file adapter gernerates a file with the incorrect content.

I hope this makes it understandable to you.

Perhaps you have an idea why in DXI all works fine and in Test in fails

Thanks again

Regards

Jochen