locked
XML Converted to string RRS feed

  • Question

  • Hi everyone.

    I will try to explain my issue as simple as I can

    • There is an XML message which I need to convert to a string variable and assign this string variable to a field in another schema and then send  that message to a Stored procedure in a database. The message looks like this while opening it in any browser:

    <ns0:RetailTranscationTable><RETAILTRANSACTIONTABLE><TRANSACTIONID>266</TRANSACTIONID><TYPE>1</TYPE><RECEIPTID>266</RECEIPTID><STORE>18201</STORE><TERMINAL>18201-1</TERMINAL><STAFF>234</STAFF><TRANSDATE>2016-01-12</TRANSDATE><TRANSTIME>10:19:53</TRANSTIME><NETAMOUNT>99.9</NETAMOUNT><GROSSAMOUNT>100</GROSSAMOUNT><PAYMENTAMOUNT /><DISCAMOUNT> 1001.1 </DISCAMOUNT><NUMBEROFITEMS>1</NUMBEROFITEMS><STATEMENTCODE>18201-1</STATEMENTCODE><TIMEWHENTRANSCLOSED>10:19:53</TIMEWHENTRANSCLOSED><CURRENCY>DKK</CURRENCY><CREATEDONPOSTERMINAL>18201-1</CREATEDONPOSTERMINAL><BATCHTERMINALID>18201-1</BATCHTERMINALID><BATCHID /><CREATEDDATE>2016-04-19</CREATEDDATE><BUSINESSDATE>2015-12-18</BUSINESSDATE><EXCHRATE>100</EXCHRATE></RETAILTRANSACTIONTABLE></ns0:RetailTranscationTable>

    • Here it looks fine since it is opened in browser. However, if I open it in notepad or with Visual studio or SQLSMS, it will show &lt; and &gt instead of '<' and '>'.

    <ns0:RetailTranscationTable>&lt;RETAILTRANSACTIONTABLE&gt;&lt;TRANSACTIONID&gt;266&lt;/TRANSACTIONID&gt;&lt;TYPE&gt;1&lt;/TYPE&gt;&lt;RECEIPTID&gt;266&lt;/RECEIPTID&gt;&lt;STORE&gt;18201&lt;/STORE&gt;&lt;TERMINAL&gt;18201-1&lt;/TERMINAL&gt;&lt;STAFF&gt;234&lt;/STAFF&gt;&lt;TRANSDATE&gt;2016-01-12&lt;/TRANSDATE&gt;&lt;TRANSTIME&gt;10:19:53&lt;/TRANSTIME&gt;&lt;NETAMOUNT&gt;99.9&lt;/NETAMOUNT&gt;&lt;GROSSAMOUNT&gt;100&lt;/GROSSAMOUNT&gt;&lt;PAYMENTAMOUNT /&gt;&lt;DISCAMOUNT&gt;1001.1 &lt;/DISCAMOUNT&gt;&lt;NUMBEROFITEMS&gt;1&lt;/NUMBEROFITEMS&gt;&lt;STATEMENTCODE&gt;18201-1&lt;/STATEMENTCODE&gt;&lt;TIMEWHENTRANSCLOSED&gt;10:19:53&lt;/TIMEWHENTRANSCLOSED&gt;&lt;CURRENCY&gt;DKK&lt;/CURRENCY&gt;&lt;CREATEDONPOSTERMINAL&gt;18201-1&lt;/CREATEDONPOSTERMINAL&gt;&lt;BATCHTERMINALID&gt;18201-1&lt;/BATCHTERMINALID&gt;&lt;BATCHID /&gt;&lt;CREATEDDATE&gt;2016-04-19&lt;/CREATEDDATE&gt;&lt;BUSINESSDATE&gt;2015-12-18&lt;/BUSINESSDATE&gt;&lt;EXCHRATE&gt;100&lt;/EXCHRATE&gt;&lt;/RETAILTRANSACTIONTABLE&gt;</ns0:RetailTranscationTable>

    This is a big headache now since I need to send this message to a stored procedure and it is expecting the parameter in the format that is seen in the first screenshot. I am converting the first XML message to string by using OuterXML.

    • MesssageString = Message1.OuterXML;
    • Message2.Parameters.param1=MessageString;

    I tried using ToString(),InnerText,InnerXML, and whatever I could find on the net but nothing is helping. While writing the converted string to event viewer I am able to see it in the proper format but after inserting it inside another XML field the issue starts.

    It would be a great help if anyone could suggest a proper solution for this. Thanks in advance :) 

    Monday, April 25, 2016 5:24 AM

Answers

  • Hi,

    What you are seeing is what is expected behaviour for XMLs. Dont use any HTML decode encode before sending messages.

    The receiver of the message should handle the data. If there is a proper xml handling then there should not be any issue.


    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:48 AM
    Monday, April 25, 2016 12:43 PM
    Answerer
  • Firstly what you are observing is the correct behavior. The receiving side should handle the string data (XML in this case properly). if in a .Net environment, they do the reverse i.e.: create an XMLDocument object and use LoadXML to load the string contents, then irrespective of the type/charset of data used they would get the correct UTF-16 or UTF-8 data.

    If you however force conversion of &lt; or &gt; then the resultant message is likely to mess-up the intermediary which in our case is the database layer (stored procedure).

    Regards.

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:47 AM
    Monday, April 25, 2016 8:43 AM
  • HOLD ON!  STOP!

    Don't do anything yet.  Especially do not use HTMLEncode or HTMLDecode.

    First, never use Internet Explorer to view Xml.  IE applies a style sheet that changes the markup.  Only use a quality text editor such as NotePad++, TextPad or Visual Studio.

    Your second sample is the correct and expected outcome from the process you're using.  You are seeing the escape sequences because the Xml Api (all of them) automatically escapes any reserved characters, <> and such, in string content.

    Some important questions (sorry, but some other answers are just guesses which doesn't help):

    • What is the specific Type of Message2.Parameters.param1?  param1 is this case is a Distinguished Field?
    • Are you using the WCF SQL Adapter?
    • What is the specific db Type of the SP parameter?

    There are a few more, but those will depend on the answers to these.

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:48 AM
    Monday, April 25, 2016 12:29 PM
    Moderator

All replies

  • Use the System.Net.WebUtility.HtmlDecode Method, by passing in your XML-escaped string(that contains the &lt; and &gt; chars). The output will be properly XML formatted that you can then use to assign to your destination message.


    Thanks Arindam


    Monday, April 25, 2016 5:36 AM
    Moderator
  • Hi Mathew,

    You have two options:

    1) You can simply decode your xml string  by passing the string into this function.

    public string XMLDecode(string Value)
    {
        return Value.Replace ("&amp;", "&").Replace("&apos;", "'").Replace("&quot;", "\"").Replace ("&lt;", "<").Replace ("&gt;", ">");
    }

    2) As highlighted by Arindham, Add a reference to System.Net* in your orchestration project and use below code:

    xmlDocReceived = ReceivedMsg;
    xmlDocNew = new XmlDocument();
    xmlDocNew.LoadXML(WebUtility.HtmlDecode(xmlDocReceived.OuterXml));
    NewReceivedMsg = xmlDocNew;



    Rachit Sikroria (Microsoft Azure MVP)

    Monday, April 25, 2016 6:01 AM
    Moderator
  • Hi Rachit,

    I suggested using the following method -  System.Net.WebUtility.HtmlDecode

    as it may not make sense/be possible to introduce System.Web assembly in a BizTalk project just for this method. Functionality wise both methods are similar. May not be feasible to introduce System.Web just for this functionality due to it's size/coupling with ASP.NET. System.Net is more appropriate in this case, imo.


    Thanks Arindam


    Monday, April 25, 2016 6:14 AM
    Moderator
  • Hi Rachit,

    I suggested using the following method -  System.Net.WebUtility.HtmlDecode

    as it may not make sense/be possible to introduce System.Web assembly in a BizTalk project just for this method. Functionality wise both methods are similar. May not be feasible to introduce System.Web just for this functionality due to it's size/coupling with ASP.NET. System.Net is more appropriate in this case, imo.


    Thanks Arindam


    Yes, you are more correct. The methods do exactly the same. The difference is only intended use. HttpUtility is contained in the System.Web assembly and is expected to be used in ASP.net applications which are built over this assembly. WebUtility is contained in the System assembly referenced by nearly all applications and is provided for more general purpose or client use.

    Rachit Sikroria (Microsoft Azure MVP)

    Monday, April 25, 2016 6:32 AM
    Moderator
  • Firstly what you are observing is the correct behavior. The receiving side should handle the string data (XML in this case properly). if in a .Net environment, they do the reverse i.e.: create an XMLDocument object and use LoadXML to load the string contents, then irrespective of the type/charset of data used they would get the correct UTF-16 or UTF-8 data.

    If you however force conversion of &lt; or &gt; then the resultant message is likely to mess-up the intermediary which in our case is the database layer (stored procedure).

    Regards.

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:47 AM
    Monday, April 25, 2016 8:43 AM
  • HOLD ON!  STOP!

    Don't do anything yet.  Especially do not use HTMLEncode or HTMLDecode.

    First, never use Internet Explorer to view Xml.  IE applies a style sheet that changes the markup.  Only use a quality text editor such as NotePad++, TextPad or Visual Studio.

    Your second sample is the correct and expected outcome from the process you're using.  You are seeing the escape sequences because the Xml Api (all of them) automatically escapes any reserved characters, <> and such, in string content.

    Some important questions (sorry, but some other answers are just guesses which doesn't help):

    • What is the specific Type of Message2.Parameters.param1?  param1 is this case is a Distinguished Field?
    • Are you using the WCF SQL Adapter?
    • What is the specific db Type of the SP parameter?

    There are a few more, but those will depend on the answers to these.

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:48 AM
    Monday, April 25, 2016 12:29 PM
    Moderator
  • Hi,

    What you are seeing is what is expected behaviour for XMLs. Dont use any HTML decode encode before sending messages.

    The receiver of the message should handle the data. If there is a proper xml handling then there should not be any issue.


    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    • Marked as answer by J.Mathew Thursday, May 5, 2016 5:48 AM
    Monday, April 25, 2016 12:43 PM
    Answerer
  • Firstly what you are observing is the correct behavior. The receiving side should handle the string data (XML in this case properly). if in a .Net environment, they do the reverse i.e.: create an XMLDocument object and use LoadXML to load the string contents, then irrespective of the type/charset of data used they would get the correct UTF-16 or UTF-8 data.

    If you however force conversion of &lt; or &gt; then the resultant message is likely to mess-up the intermediary which in our case is the database layer (stored procedure).

    Regards.

    Thanks for the reply :) . Like you have pointed out, this is the expected behavior but my peers were insisting on changing it. However, lately we did a test run and on the receiving end they are able to see it in the proper format. Thanks for the support :) 
    Thursday, May 5, 2016 5:51 AM
  • HOLD ON!  STOP!

    Don't do anything yet.  Especially do not use HTMLEncode or HTMLDecode.

    First, never use Internet Explorer to view Xml.  IE applies a style sheet that changes the markup.  Only use a quality text editor such as NotePad++, TextPad or Visual Studio.

    Your second sample is the correct and expected outcome from the process you're using.  You are seeing the escape sequences because the Xml Api (all of them) automatically escapes any reserved characters, <> and such, in string content.

    Some important questions (sorry, but some other answers are just guesses which doesn't help):

    • What is the specific Type of Message2.Parameters.param1?  param1 is this case is a Distinguished Field?
    • Are you using the WCF SQL Adapter?
    • What is the specific db Type of the SP parameter?

    There are a few more, but those will depend on the answers to these.

    Thanks for the reply :) . Like you have pointed out, this is the expected behavior but my peers were insisting on changing it. However, lately we did a test run and on the receiving end they are able to see it in the proper format. Thanks for the support :) 

    Also:

    • Param1 is a distinguished field
    • Exactly, I am using a WCF-SQL adapter
    • SP parameter is of string type

    I was able to execute the stored procedure on the target side without altering my message :) . My peers are convinced now.


    Thursday, May 5, 2016 5:53 AM
  • Hi,

    What you are seeing is what is expected behaviour for XMLs. Dont use any HTML decode encode before sending messages.

    The receiver of the message should handle the data. If there is a proper xml handling then there should not be any issue.


    When you see answers and helpful posts, please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    Thanks for the reply :) . Like you have pointed out, this is the expected behavior but my peers were insisting on changing it. However, lately we did a test run and on the receiving end they are able to see it in the proper format. Thanks for the support :) 
    Thursday, May 5, 2016 5:54 AM