Azure Integration Account XSLT - omit-xml-declaration

This blog shows that Azure XSLT maps ignore the omit-xml-declaration tag. Additionally it discusses some consequences and a workaround.

The issue with omit-xml-declaration

Azure Integration Accounts allow developers to use BizTalk maps in Azure Logic Apps. Moreover, Microsoft promotes this as feature to make migration of BizTalk interfaces to Azure easy.

Thus after importing my schemas and maps and referencing them in my Logic Apps, I am ready to go.

The XSLT for the map contains a xsl:output tag. This removes the xml declaration from the resulting payload using BizTalk.

Creating the an Azure Logic App to map the XML was undemanding. Firstly, configuring the content of an XML Transform action shape with XML from a service bus trigger. Subsequently selecting the drop down of Map box gives a list of XSLT maps in the integration account and completes the configuration of the map.

The compose action contains some gymnastics to manipulate the XML so that it can be used in subsequent actions. Indeed this is the subject of this post. If the compose shape just wraps the XML in a soap envelope as shown below then the soap request fails with “Possible SOAP version mismatch“.

Examining the XML output of Transform action I noticed two things a non-ASCII character and a XML declaration that prefixes the XML. Clearly this is not compatible with in a SOAP body payload and gives the error above.

Furthermore the transform action does not obey the XSLT instruction <xsl:output omit-xml-declaration=”yes” method=”xml” version=”1.0″ />. It always prefixes XML output with the XML declaration above and ignores the XSLT.

Other consequences

As a result this XML also creates an error if it is passed to the xml or xpath work definition language functions. Typical errors are;

“Unexpected character encountered while parsing value: . Path ”, line 0, position 0.”
“The template language function ‘xml’ parameter is not valid. The provided value cannot be converted to XML: ‘Data at the root level is invalid. Line 1, position 1.'”.

Both of these errors are due to the first non-ASCII character. May be this character is a byte order mark.

In summary I think XML manipulations are in doubt if you use the output of the XML transform action shape and a workaround may be required.

A workaround

This strange behaviour where Azure transform actions ignore the omit-xml-declaration tag has been noted before. For example this post from 2017 suggests to

use a replace function ….. Something like
@xml(replace(string(body(‘yourtransformaction’)),'<?xml version=\”1.0\” encoding=\”UTF-16\”?>’,”))

Finally the respondent reported that @replace(string(body(‘Transform_XML’)),'<?xml version=\”1.0\” encoding=\”utf-8\” solved their problem. While the replace function can heal the XML for some tasks it does not remove the first hidden non-ASCII character. Thus my approach uses the last and split function to remove both the XML declaration and the first hidden character.

@{last(split(string(body(‘Transform_to_EDISubmit_XML’)),'<?xml version=\”1.0\” encoding=\”utf-8\”?>’))}

The XML can now be passed to the xpath function without error. For example I wanted to retrieve a purchase order number from my XML and assign it to a property. The expression that worked for me was

@first(xpath(xml(last(split(base64ToString(triggerBody()?[‘ContentData’]),'<?xml version=\”1.0\” encoding=\”utf-8\”?>’))),’/OrderRecords/Order/OrderHeader/@BuyerOrderRef’))

Conclusion

Do Azure XSLT maps ignore the omit-xml-declaration tag by design or is it a bug? As shown above this omission makes handling XML in Logic Apps much more difficult than it should be. I present a workaround above that uses workflow definition language to heal the issue. In particular using a combination of the last and split functions.