Error: Root Element is Missing

<pre>InstanceId: d1c2f87c-825b-4c6e-b01c-c93e50d63502
Shape name: msgABCDetail
ShapeId: 33d0d3ac-ae45-408c-8224-f42725877a2b
Exception thrown from: segment 4, progress 22
Inner exception: Root element is missing.
</pre>

Explanation 1

This error occurs in an orchestration, typically after you have run a map, and the map doesn’t create any output. It basically means your message or map output is empty, and you are trying to convert it to load it into a variable of System.Xml.XmlDocument.

You can simulate the same error in PowerShell like this:

<pre>
$xmlcontent = $null 
$xml = New-Object -TypeName System.Xml.XmlDocument
$xml.LoadXml($xmlcontent)
</pre>

Sadly, instead of saying null or empty xml string, it tells you “Root element is missing”.

Now back to my BizTalk scenario. The map is in a construct statement, and presumably the message created in the construct statement should not be empty.

The way to test or fix this is as follows:

1) Obtain a copy of a the message that goes into the map (might have to add debug or write message to disk or trace), and save to disk.

2) Test that message in Visual Studio using the right click “Test Map” option on the map (first set the “TestMap Input Instance” property to the filename you saved from the step above.

3) Typically the issue is a namespace or higher level node is missing. This causes none of the xpaths in the XSLT to match, and thus nothing is generating on the “right side” of the map. When you test the map, the Output window will show something like this: “The output is stored in the following file: xxx.xml”. If you cntl-click on that file, that file will open. In all likelihood it will be empty (blank). [If it has data in it, there is a chance the code you are running doesn’t match the current version of the source code/map you are testing, indicating you might need to redeploy.]

4) To check further, you can also check the file against the schema, to make sure it is valid. This may help indicate an element name or namespace that is wrong that could cause the map to result in empty output. Set the schema property “Input Instance Filename”, then right click on the schema and select “Validate Instance”. If it fails, you might try generating an instance, then use a file compare or your own eyeballs to compare the generated instance to the instance you were validating (experience teaches you what to look for).

Here’s a specific case I dealt with today. My data file had a root element named eisresultset. It was built by xpathing to a node of the data data returned to us by a vendor. Due to the way the vendor packs the data in a generic XmlDoc packet, the WSDL did not build the schemas for us, and I had to do it manually. When I built the schema for esiresultset, I misspelled the root element name and had esiresultset. The reversal of those two letters make a huge difference!

When I validated the data instance against the schema, the output window told me clearly:
e:\MyDir\MySubDir\map_EsiResultSet_To_DBTableMotoDetails_TestIn1.xml: error BEC2004: The ‘eisresultset’ element is not declared.

The second mistake I made, was in my map, I had mapped eisrecord, a separate schema with that repeats inside of eisresultset. So mapping a schema that starts with a higher level element than what I mapped would never result in a good map output.

Explanation 2

If you set an XmlDoc to your message, and then load that XmlDoc with something else, you may be wiping out your message with that next text.

For example, on another date then the original blog post with Explanation 1 above, I was using my own trace to SQL C# routine. I frequently do this:

<pre>
xmlDoc = msgIn; 
#and then call # that writes to Database Trace 
</pre>

Then I was testing getting ISA/GS Headers and to test the results I did this:

<pre>
xmlDoc.LoadXml("<Wrapper><ISASegment>" + strISASegment + "</ISASegment>" + 
               "<GSSegment>" + strGSSegment + "</GSSegment></Wrapper>"); 
#and then call # that writes to Database Trace 
</pre>

Of course, xmlDoc is an orchestration variable of type System.Xml.XmlDocument.

I lost 2 or 3 hours of work chasing this down, do all the steps I outline in “Explanation 1” above, as those steps showed no problem whatsoever.

So basically, xmlDoc was pointing to the same memory as the message, and loading a new doc on top of it, with a different root element and totally different fields. Thus the map would not match the root elements, and would not create any output.

The solution was to use a separate variable, XmlDoc2 for debugging the ISA/GS headers.