I’m receiving IDOCs where some of the company names have && in them.
This is causing wm problems.
I remember setting the encode value to true when passing the boundnode to documentToXMLString. However it doesn’t seem to be working in this instance.
Does anyone have a solution to this?

what is the error?

is it a parser error when submitting to TN?

I am getting the following error in TN:

XQL query /INVOIC01[0]/IDOC[0]/EDI_DC40[0]/IDOCTYP[0] failed recognizing document m160tt00v51imo4t000000dh. The document is probably not valid XML. The original exception message is: com.wm.lang.xml.WMDocumentException: [ISC.0042.9325] Element <lktext> is missing end tag.

However the end tag is not missing, when I remove the ampersand from the xml file, the file processes without any errors.

I’m pretty sure this is an encoding issue.

I’m not up on WM6.0 - but I’ve tested the recordToDocument flow in IS 4.6. With the encode set to TRUE - the && is encoded correctly in the resulting xmldata string.

The && should be translated to &&

xml handler in webMethods throws an error when you have &,',<,> in a xml files. When you receive the file with these characters convert them into html encoded charcters before processing like
& - &
’ - '
< - <
> - >

this should solve the issue.

Regards,
MJ

Hi,

we are having problems with the XML Handler in 4.6

when we receive addressLine1="PROL. TECNOLOGICO # 5"A" "

the xml is cut in two after 5

any ideas?

thanks in advanced

Rick,

I just tested same data in the IS6.0 the data is parsing and no breaks, I have used the services
XMLStringToNode
XMLNodeToDocument inputs i am passing are makeArrays=false, and documentTypeName=xmldocumentName)

before parsing the xml
PROL. TECNOLOGICO # 5"A"
after parsing the xml
PROL. TECNOLOGICO # 5"A"

So i believe this should work in IS4.6 too…
How are you parsing the data.Is it via documentToRecord?.If so it should definetely work.[documentToRecord(4.6)=XMLNodeToDocument(6.0)]

Sorry i dont have IS4.6 installed here to test the same,but i am sure the data should parse since data you are using is encoded properly.

HTH,
RMG