B2B add-on inbound XML root node

[former_member230495]

Hi Guys,

I'm working on a "ANSI X12 810" to IDOC scenario.

Everything looks good, but I noticed that the payload from EDISeparator (which will go through my operational mapping), has this XML structure with root node <ns:ASC810_004010......>. root-node.jpg

This caused an error in the mapping since I have defined my source message type with a different name, which I fixed by parsing it through a XSL mapping first.

But I'm curious to know where it's pulling this "ASC810_004010" and if it's something we cane change.

Thanks,

~Jay

[Ryan-Crosby · Accepted solution]

Hi Jay,

"ASC810_004010" is the name that would be generated for the data type if you use the B2B cockpit to create the .xsd schema. You can alter the generated content but IMO the name tells you everything you need to know about the message type including the version number so I'm not sure why you would prefer to alter it.

Regards,

Ryan Crosby

[former_member230495 · Accepted solution]

Hi Ryan,

Actually this was my first thought as well.

And I did try changing the data type name (to ANSIX12_810_Send) and it didn't work.

Got the same payload from EDISeparator sender with the root node <ns:ASC810_004010......>.

The only reason I want this to be changed is, it fails trying to execute my message mapping as the root node doesn't match with my source message type name(ANSIX12_810_Send).

Actually I can avoid the whole issue simply by changing the message type name, which would be not nice, as it'll be deviating from our naming standards 🙂

BTW one observation I made, when you do an "Ansi.X12 to XML Conversion" using the EDI content manager, it generates the XML with the root node <ns:ASC810_004010......>. So I don't think it has anything to do with a data type we define in ESR.

As I mention in my question, this isn't a real showstopper. I'm just curious of how the whole thing works.

Thanks a lot for your feedback.

~ Jay

[Ryan-Crosby · Accepted solution]

Yes, since this is something generated during conversion you would have to handle the name generated in the standard module. For this reason we don't deviate from the naming conventions that they have chosen so we don't have end up with problems like this one. We simply import the schemas created from the cockpit and based the message type names off the same convention.

Regards,

Ryan Crosby

[former_member230495 · Accepted solution]

Thanks for the clarification Ryan.

By any chance, have you come across a module parameter which we can change this?

Just as a comparison, on File sender adapter FCC, we have attribute "Document Name", which defines the root XML tag for the payload.

Thanks,

~Jay

[Ryan-Crosby · Accepted solution]

Hi Jay,

Not that I am aware of. You would have to manage it using the XSLT mapping that you have already generated or intercept it with a custom module to adjust the XML root name.

Regards,

Ryan Crosby

[former_member230495 · Accepted solution]

Hi Ryan,

Exactly what I did. Used and XSLT.

Not relevant to this question at all, but since you seems to have pretty good experience with the B2B add-on. 🙂

By any chance, have you seen this question by me on the forum? I never got a proper solution to this (other than of course doing it in the mapping).

https://answers.sap.com/questions/403155/x12filluptominlength-not-working.html

Thanks a lot for your help.

~Jay

[Ryan-Crosby · Accepted solution]

Hi Jay,

I will look at the thread and see if I can offer any help.

Regards,

Ryan Crosby

[former_member186851]

Hello Jay,

How you generated the source XSD ,using B2B cockpit?

You might need to change the XSD before importing it.

[former_member230495]

Hi Raghu,

Thanks a lot for your feedback.

I try doing this, and it didn't work.

Please see my reply to Ryan.

~ Jay