This week, while migrating a BizTalk Server project to Azure Integration Services (AIS), we reused several existing BizTalk maps inside Azure Logic Apps. During this process, we ran into a classic but frustrating issue.
All components deployed successfully. However, when we executed one of those maps using a Transform XML action, the workflow failed at runtime with the following error:
ActionFailed
An error occurred while transforming the given input with the provided map.
Details: ‘Data at the root level is invalid. Line 1, position 1.’
📝 One-Minute Brief
While migrating BizTalk maps to Azure Integration Services, a Logic Apps Transform XML action failed at runtime with a generic parsing error. The root cause was a hidden UTF‑16 LE BOM in the XSL, which Logic Apps does not ignore, causing the transformation to fail immediately.
Cause
This is a classic, generic, and highly unhelpful error. It can also have several different root causes. These are some of the possible causes:
- The input is not XML: The data sent to the transformation action may not be XML. Logic Apps can pass JSON, plain text, a Base64‑encoded payload, or even an empty body.
- The XML is Base64‑encoded: Many connectors—such as Service Bus, FTP, HTTP, and Blob Storage—deliver message bodies encoded in Base64. BizTalk handled this decoding automatically. Logic Apps requires you to explicitly decode the payload.
- Invalid XSL structure: An invalid XSL structure is always possible. However, you can usually identify and fix this issue quickly.
- Byte Order Mark (BOM) or invisible characters: This is the most unusual cause and often the hardest to diagnose. However, it is frequently the real reason behind this error.
- Some systems send XML with a UTF‑8 BOM or invalid leading characters. When this happens, the XSLT fails immediately.
- More importantly, the XSL file itself can contain a BOM. This depends on the encoding used when saving the file. If the XSL includes a BOM at the beginning, the transformation may fail.
The Byte Order Mark (BOM) is a special Unicode character placed at the start of a text file or data stream. It helps software detect the file encoding and, in some cases, its byte order.
In our case, we saved the XSL file as UTF‑16 LE with BOM. Logic Apps does not ignore this BOM. As a result, the parser treated it as an invalid character before the < of the XML.
This character is difficult to detect. When you open the file in a text editor like Notepad++, it remains invisible to the naked eye.
But here is a tip: if you compare that XSL file with another XSL that works properly in WinMerge, this BOM character will be highlighted:
Solution
Once you know the root cause, the solution is simple to implement. In our case, it was because the XSL was saved as UTF‑16 LE BOM, which contains the BOM character at the beginning of the file.
To solve this, we removed that character just by saving the XSL file as UTF-8.
Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.
