iDoc receiver channel - multimapping error

[Former Member]

Hi folks,

I have an Edifact to iDoc scenario (PO Java single stack 7.31, AF 7.31). This scenario needs a 1:n multimapping. After the mapping is executed (successfully), I get this error message below in the comm. channel monitoring for the iDoc receiver channel:

Message-Verarbeitung fehlgeschlagen. Grund: com.sap.aii.af.idoc.exception.IDOCAdapterException: Error before sending due to idoc parsing error: (7) IDOC_ERROR_PARSE_FAILURE: Invalid XML 1.0 character encountered within IDocXML for type <ns0:Messages>:
state=EXPECTING_IMMEDIATE_TAG_END, charPosition=68, lineNumber=1, columnNumber=69, invalidChar=U+0078,
sourceSnippet=...UTF-8" standalone="no"?><ns0:Messages xmlns:ns0="http://sap.com/xi/XI/SplitAndMerge

The XML structure is absolutely fine, I tested the mapping plenty of times. If I perform the exact same mapping 1:1, it works just fine.

My research lead me to one relevant note:

http://service.sap.com/sap/support/notes/1843122

The only difference is I dont actually use binary payloads and such, just a good ole 1:n message mapping. Nevertheless, we are now asking the Basis team to update the AF to the sps and patch level mentioned in this note.

I searched all the threads with this kind of error (IDOC_ERROR_PARSE_FAILURE), none seems to completely describe my problem.

Is there maybe something that I'm missing in the iDoc receiver channel that can solve this? This happens for all EDIFACT to iDoc scenarios that involve multi mappings (never for 1:1 mappings).

Please let me know if you have any good to very good ideas.

Thanks in advance and best regards,

George

[Harish · Accepted solution]

Hi George,

Please check the below wiki

File to Multiple IDOC Splitting without BPM - Process Integration - SCN Wiki

Message and Message1 tag is not supported in IDOC receiver.

regards,

Harish

[engswee · Accepted solution]

George, Harish

That is a very old Wiki and only applicable for XI3.0/PI7.0.

Mapping-based message split (multi-mapping) for IDoc receiver is supported at least from PI 7.11 (I didn't work on PI 7.1 so I'm not sure.) From PI 7.11 onwards, it is easily achieved by just changing the signature of the IDoc receiver to unbounded - no longer any need to export and edit the XSD.

1-n multi-mapping for IDoc targets is a very common scenario and I've done tonnes of them without any issue. The IDoc receiver channel (whether dual stack or AAE) automatically unwraps the <Message>/<Message1> tags into child messages.

Here is a simple sample that I just did on PO 7.4 system with IDoc_AAE receiver adapter.

Set target occurrence to unbounded

After mapping payload shows that the <Message>/<Message1> sections are added to indicate multi-mapping message split.

Log of parent message shows a split to child messages.

Child payload shows that the <Message>/<Message1> tags are automatically removed.

Log of child message shows that child message is successfully sent as IDoc to backend system.

From your error above, it looks like it's related to incorrect target payload. At position 68 of the payload it is expecting an end tag but getting an x (unicode 0078) instead.

Invalid XML 1.0 character encountered within IDocXML for type <ns0:Messages>:
state=EXPECTING_IMMEDIATE_TAG_END, charPosition=68, lineNumber=1, columnNumber=69, invalidChar=U+0078,

The "standalone=no" in your payload indicates that you might be using a Java mapping to perform the multi-mapping. Check if the output of the mapping is in a correct XML format. Check also that your Operation Mapping is using unbounded occurrence for the target operation.

Rgds

Eng Swee

[Former Member · Accepted solution]

Hello Eng,

I am writing this here as i believe my doubt is relevant to this discussion and may help others

I was wondering if you could help me clear one of my doubts.

Can we manage erroneous IDOC to fail in PI and send the rest to SAP using this 1.n mapping ?

We achieve n IDOC's after mapping in a single message , If there are any idoc's which fail due to data validation in IDOC Receiver channel , I am keen to know whether the rest of them reaches SAP?

Thank you in Advance,

Regards,

Mudassir

[Former Member]

Finally I managed to login to my SCN account again (stupid password). Thank you all for the contribution.

Folks, I've solved it with the approach presented by Harish. I just wanted ONE way in which I can do a 1:n mapping between an EDIFACT and iDoc messages and the first one that works is good enough for me, especially because I dont see much difference in performance between the two.

I understand you don't believe me when I tell you that my mapping was just a good ole message mapping created in PI, no JAVA external program. This is really this case. The case is also that the comm. channel throws the error for that <ns0:Messages xmlns=.... (that small "x" from xmlns is to blame and it is introduced from the mapping signature with which I have nothing to do. Because it's taking ages to update PO and implement the note mentioned above by me, I will go with door number one and just do that for all other interfaces in this system. I know it "should" work with the <Messages> too, but it doesn't and investigating why and testing stuff without a helpful Basis and without sufficient NWA authorizations to check logs and such is too much of a hassle and I have other things to do on the project.

It must be because of a bad SPS of the system and might have been solved with a new patch.

Notwithstanding that, now people confronted with the same issue now have an alternative linked in this topic that can be quickly implemented which it also worked for me.

Thank you all and best regards,

George

[engswee]

Glad to hear that you managed to resolve your issue despite all the obstacles. Thanks for the update and sharing your final approach.

[RaghuVamseedhar]

George,

Your interface is, EDIFACT to IDoc. One input file will be split into multiple IDocs.

FYI... This is not a multi-mapping. There should not be any <ns0:Messages OR <ns0:Message1> input and output. (I agree with Harish first response).

Step 1) Changing the Occurrences of Standard IDOC. Import updated XSD into ESR. In message mapping point to this imported XSD.

2) No need to change the anything else. There will be no change in signature tab of message mapping (occurrence will be one for both input and output structure).

To be sure that XML is well formed, open the .xml with any browser.

[engswee]

Hi Raghu

I don't understand why you say that one input to multiple IDocs is not multi-mapping.

As documented in the following SAP Help link, a 1-n transformation is a multi-mapping.

Multi-Mappings - Managing Services in the Enterprise Services Repository - SAP Library

As I mentioned in my earlier reply, the changing occurrence XSD is a workaround from the days of XI3.0/PI7.0. Back then, the IDoc adapter does not support child messages generated out of multi-mapping. As of PI7.11 (at least), that workaround is no longer required, just a changing of the target occurrence will suffice. This has helped reduce the additional steps for developers when doing a 1-n IDoc mapping.

Unfortunately, in most places I have been the common misconception and practice from the old days are still around. I try as best as I can to inform them that this is no longer required.

I would suggest that you try it out in your system. Wouldn't saving a few unnecessary steps help in one's productivity?

Rgds

Eng Swee

[RaghuVamseedhar]

Eng,

Thank you for letting me know. I was not aware of this (did not think about the solution given by you). I was mistaken, sorry.

All,

Please ignore my above response.

[engswee]

No worries I didn't know myself until someone first told me years back. I'm just passing it forward. Now it's your turn to pass it forward

[Former Member]

Thank you both.

I am using a message mapping, no JAVA program, minimal UDFs only when absolutely needed. That unexpected x is the one from <ns0:Messages xmlns=....

I'm definitely not the one interfering with the namespaces they're done from the data definitions.

That's why I was digging through notes and stuff, it's definitely something probably deeper and nothing having to do.

I just want it to work in one way or another and I was not able to achieve that by using 1:n mapping for the iDoc receiver channel.

I'm now testing Harish's way, still my mapping hangs when I have more than 1 entry in the source array of elements (in order to create more than one iDoc), even though i have ZERO loops and zero UDFs in the message mapping, funny enough. I'll probably post that challenge separately if I cant find a solution today. Man, I've been working in PI since 2009, but this Java only 7.31 stack I'm working on now has significant issues like these...

Best regards,

George

[Former Member]

Hello George,

IdocAAE check the xml structure and content. I have this error in migration scenarios  where it was used Idoc standard adapter.  In our cases the problem was that Idoc adapter does not validate the content but if you change the adapter to Idoc_AAE errors happen.This error was raised because in mapping steps  some values were mapping in segments where the value is not expected.

Can you post your payload and full error trace?

[Harish]

Thanks Eng Swee

I overlooked the error.

@George - As Eng Swee pointed out the real issue for error is output message. Open the output XML in text editor (e.g. Notepad++) and check the line 1 column 69. you will find a special/invalid char in the output XML which is causing the problem.

<ns0:Messages>:

state=EXPECTING_IMMEDIATE_TAG_END, charPosition=68, lineNumber=1, columnNumber=69, invalidChar=U+0078,

regards,

Harish

[engswee]

George

Not sure what luck you have had in resolving the issue since. Just to let you know my intention wasn't to get you to choose one approach instead of the other. It's fine whichever approach you go for. Just wanted to point out that the <Messages> part may not be the real root cause.

I'm on a PO 7.4 SP08 (equivalent to 7.31 SP13) system and multi-mapping for IDoc receiver works fine for me. Not sure which SP your PI7.31 system is on and if the issue might be SP-related.

Also, I've never seen a graphical message mapping generate an additional standalone="no" attribute on the first line of the XMLpayload. I normally see this when it is generated by a DOM-based Java mapping. Not that I'm doubting you, but are there more than one mapping steps in the Operation Mapping?

I would suggest that you create a new multi-mapping interface with some simple mapping (just IDoc control record and 1-2 fields) to see if it works - see if the different logs/payloads for the parent-child matches what I've shown above.

If it's possible then posting your payload might also be useful for further analysis here.

Rgds

Eng Swee