We are working with a scenario IDOC flat file(coming to PI through JMS adapter) to IDOC XML and for this we are using ABAP mapping.
when we are triggering message from JMS MQ server ,message coming to PI and waiting at MONI with status "recorded for outbound processing" at “receiver grouping ” step of pipeline.
But it is giving us an error at SMQ2 “FM-IDX_XML_TO_IDOC call failed”.
We tried to find similar post in SDN and what we understood that function module which giving us an error at SMQ2 is used in IDOC XML to IDOC flat file conversation. And we are not even calling this function in our Mapping class.
Even mapping step is not get called in Pipeline.
We have 2 more scenario using same mapping class and working file .
Do any one have any clue on this error.
have you tried to use the standard module available for this?
We removed all special char from the source and now message is not stopping at SMQ2. else it is failing at Mapping program and giving exactly same error as SMQ2 .
but here we are finding another issue.
When we are routing MQ messages to our Dev box it is working fine and no error at mapping .but when we route same payload to our QA box it is failing at mapping(same error).
we have checked every thing and there is no difference in between QA and Dev box code. all the channel have same configuration.
Is in PI we are defining any encoding at system level.
As of I know PI support UTF-8 encoding.
If you are absolutely sure that your configuration in Dev and QA is identical in PI, then there is only one conclusion: the connection config in the sender system has to be different across the landscapes. Can you verify that?
And you are right about the encoding, PI uses Unicode.
Hope this helps,
Thank you all for replying.
We able to resolve our issue.
Please find our solution below
1. 1. Message are failing at queue(SMQ2) due to encoding issue. Input file contain some special char which is not handled. Program internally calling FM “IDX_XML_TO_IDOC” which is failing because inbound file is not in fixed length format due to special char. To solve this we included encoding 1164 to our mapping class. Once done message reached to mapping step but failing again there.
2. 2. To solve the mapping issue we found that Partner profile at IDX1 is referring to some old RFC destination which is not in use. We changed this to our current system and it is working fine now.