Sending Character Entities in Web Service Request

Hello,

We have a Remedy web service configured in OIM 7.0.2 to create Remedy work orders from OIM. We have generated the custom script to call the web service method using the OIM web service wizard. One of the fields we need to send is a description field with line breaks. We're passing the value to the custom script as below, with the 
 character entity representing carriage returns:

User First Name: John
User Last Name: Doe
User Network ID: JXD301202
User Employee ID: 999999999

Requested Application: Oracle
Requested Entitlement: Admin

However, I analyzed the SOAP request being sent to Remedy using Wireshark and noticed that & is being encoded to & as below, even though it is part of a character entity representation:

<Detailed_Description>User First Name: John&amp;#13;User Last Name: Doe&amp;#13;User Network ID: JXD301202&amp;#13;User Employee ID: 999999999&amp;#13;&amp;#13;Requested Application: Oracle&amp;#13;Requested Entitlement: Admin</Detailed_Description>

How can I send character entities to a web service from OIM as-is without being encoded? In this particular case, how can I have the SOAP request be generated with the description field as follows:

<Detailed_Description>User First Name: John&#13;User Last Name: Doe&#13;User Network ID: JXD301202&#13;User Employee ID: 999999999&#13;&#13;Requested Application: Oracle&#13;Requested Entitlement: Admin</Detailed_Description>

Thanks in advance,

Febin

  • Hi Febin,
    Take a look at this:
    social.msdn.microsoft.com/.../sending-unencoded-xml-to-soap-web-service

    TLDR: an unescaped & is not valid in XML.

    You might want to try wrapping the entire XML blob in a CDATA tag.

    You don't say how you are generating the string, but another option might be to use a "/r" in place of the "&#13"and let the framework escape that for you
  • In reply to George Cerbone:

    Hey George,

    Thanks for chiming in. I understand that an unescaped & is not valid in XML, but the & in "&#13;" is not meant to be escaped - we need to be delivered to Remedy as-is so that it will be recognized as a carriage return. I'm facing the same issue even if I try to send "&#38;" (ampersand character representation) - this gets sent to Remedy as "&amp;#38;". The issue is with how OIM code is parsing the string to create the SOAP request.

    Thanks,
    Febin
  • In reply to fmoideen:

    Right...what I am telling you is the reason that the & is getting escaped is because otherwise it would not be valid XML.  So the .NET framework (not 1IM) XML serializer is escaping the "&" allow it to be valid.

    If you want to send it as a literal, you can try to wrap it in a CDATA block, or use the /r character and let the .NET serializer handle it.

  • In reply to George Cerbone:

    Hi George,

    My point was that the below is perfectly valid XML - the serializer shouldn't escape the "&" once it sees that it is followed by a valid character representation:

    <Detailed_Description>User First Name: John&#13;User Last Name: Doe</Detailed_Description>

    To drive home the point, I get the same issue if I try to send the character entity of "&" - "&#38;". This gets serialized and sent as follows:

    <Detailed_Description>User First Name: John&amp;#38;User Last Name: Doe</Detailed_Description>

    I forgot to mention in my original post, but the strange thing is that this was working perfectly fine before without any code changes. We did install some hotfixes and a new module - not sure if these caused something related to change.

    I'd already tried to wrap the description in a CDATA block, but the special characters involved get escaped here as well:

    <Detailed_Description>&lt;![CDATA[User First Name: John&amp;#13;User Last Name: Doe]]&gt;</Detailed_Description>

    I just tried replacing "&#13;" with "/r" but that didn't get serialized correctly and got sent as-s:

    <Detailed_Description>User First Name: John/rUser Last Name: Doe</Detailed_Description>

    Thanks,
    Febin
  • This was resolved by replacing "&#13;" with vbCrLf constants. The "&#13;" way was working for a long time and stopped working all of a sudden - not sure why