Native serialization error Root element is missing Map Error

Recently I was testing a BizTalk map inside Visual Studios.  The input schema was auto generated using the SQL Adapter and the output was a simple text file.  I was using a sample file provided to me from a past generation from the schema (or so I thought) to test the map. 



When I was testing, I keep getting a blank file as output and a strange error.  The error was: Native serialization error: Root element is missing. 



I had both input and output validation turned on and the input sample file was passing validation.  To confirm this, I took the schema and sample file and confirmed it validated using Visual Studios. 



Since I was not having much luck testing inside Visual Studios, I decided to set up a send & receive port and test the map through BizTalk to see if I could get different result.  This time, I got a subscription not found error.



Odd, since the schema and maps are all deployed.  I check the message that was suspended and noticed it was not mapped; my original message was published and suspended. 



This could only mean the message type was wrong – somehow.  So I took a closer look at the namespace in the sample message.  It was slightly off!  I corrected the namespace in the sample file and everything worked fine.



Overall, the moral of the story is three fold:



1.          Schema Validation inside BizTalk DOES NOT validate namespace; at least it doesn’t if there is only one.


2.          When you get a strange mapping error with no output, check your namespace!


3.          Use extreme caution when typing in the namespace fields when using the SQL Adapter.  Evidently in a past test the namespace was typed incorrectly.  When the SQL Schema was auto generated, this wrong schema was use to make the sample file I was using.



This took me over an hour to figure out so I guess I’m getting rusty at testing BizTalk maps.  Hope this helps someone else out down the road.


Convoys, GetTempFileName, and InterceptorException in Biztalk Server

It’s late on a Friday.  I am still at the client site.  I just canceled my flight home.  It is my anniversary weekend (yep it is on 9/11, sure sucks).  We are hours from going live…  But, what does Exceptions.Types.InterceptorException GetTempFileName Failed mean?



I ran into this problem while testing some recently updated Orchestrations that use Convoys to process messages received from multiple source systems in order.  A small change was made that removed a Send Shape and replaced it with a custom .net component call to a java web service.  Seems simple enough.



When the process encounters an exception, it uses the file adapter to write the file to disk and stops message process.  That all tested perfectly.



When the process completes successfully but no other messages have arrived in the convoy.  That all tested perfectly.



When the process completes successfully but new messages have arrived in the convoy the follow error occurs:



Exceptions.Types.InterceptorException


GetTempFileName Failed.


       


Exception type: StreamingException


Source: Microsoft.BizTalk.Streaming


Target Site: System.IO.Stream CreatePersistentStream()


Help Link:


Additional error information:



Not only do I get an exception, but the process continues forever in an endless loop with a 100% CPU spike.



So, what could be the problem and more importantly how can it be fixed? 



The answer lies with the change that was made by replacing the Send Shape with a .net component call.  This removed a persistence point in the Orchestation.  In fact, it removed the only persistence point for the happy path (i.e. no errors) inside the Orchestration.  So, when this message is processing, a 2nd message arrives in the convoy, and the next Receive Shape is hit the whole process goes down hill.



Solution:  I added an Atomic Scope (persistence point) right after the Receive Shape.  Problem solved. 



A better solution: Isolate the units of work inside the Orchestration into logical units and use Atomic scopes to track progress through the Orchestation.  In the event of a Server Crash, the Orchestrations would restart in more desirable state.


 


Even better solutions?  I’m sure. 


 

Large Messages Can Cause Large Problems in BizTalk

Recently I have seen a lot of talk about large message support in BizTalk 2004.  The most interesting and depressing was on the BizTalk Core Engine WebLog.  It seems that large messages do not work as well in BizTalk 2004 as I would have hoped.



I have had success with some types of large messages using the file adapter and mapping.  I have gotten it to work with messages up to 500 MB but in a production environment this would not be a viable or supported solution. 



During some recent testing, I discovered the follow condition that rather surprised me.



Scenario


I was returning an unpredictable amount of data out of an Oracle database using .net code.  This data can be 1 MB or up to 250MB+ and needed to be processed in a single batch.  This data is then converted into Xml, cast to a message, and mapped with the results written to disk using a Send Shape.  Life was good until the extracted data returned was greater then 220 MB in size.


 


At this point, everything went downhill.  BizTalk Server began to have serious problems.  Receive functions were shutting down and I received the following Warning message in the Application Log:



A catastrophic failure occurred in the BizTalk service. The service will shutdown and auto-restart in 1 minute. If the database is still unavailable, this cycle will be repeated.


 


Error message: Exception of type System.OutOfMemoryException was thrown.


Error source:


 


BizTalk host name: BizTalkServerApplication Windows service name: BTSSvc{E93E7C4A-9E8B-40F6-AD7C-4F53B85F36C4}


 


For more information, see Help and Support Center at



All appears to be well and good since BizTalk seems to be handling the situation as expected… except for when the service actually starts again.  Since the Orchestration that caused the fatal error is still Active (the Orchestration itself did not through any errors), BizTalk starts to process the Orchestration from the last persistence point.  Thus, repeating the cycle in an endless loop.



Now, for the interesting behavior…  If this is running in a multi server BizTalk environment at the point the 1st BizTalk Server fails the 2nd one picks up; like I would expect.  I end up getting a completed Orchestration with no errors.  Super!  But, I only get a zero byte file as output.  So, looking inside HAT everything would look like it completed successfully with no errors.  Not good…



Overall, I found that an Orchestration seems to be able to handle about 440 MB of “stuff” before it crashes.  Just make sure you know what makes a copy of the message (like mapping).  Of course, processes with this amount of data would not be supported nor do I recommend actually doing it.  But, it has been fun to play around with and see what fails.



The moral of this story is to be very mindful of your message size.

XLANGs.BTEngine.BTXTimerMessages Delivered, Not Consumed

What?  How?  When?  Why?  Useless?  You have no clue what I am talking about?



What are BTXTimerMessages?


They are messages BizTalk uses internally to control timers.  This includes the delay shape and scope shapes with timeouts. 



How will you see BTXTimerMessage?


You will see these messages in HAT.  They will be associated with running Orchestations.  If they show up, they will be in the Delivered, Not Consumed (zombie) message status.



When will you see BTXTimerMessages?


I see these messages when I am working with parallel actions, atomic scope, and convoys.  My sample, Limit Running Orchestrations, produces these types of message.  I have not been able to pin point the exact shapes or actions that cause these messages to show up. 



Why do you see BTXTimerMessages?


Good question.  I have a theory, but it is probably wrong.  It is that the timer message is returned to the Orchestration after if has passed the point of the delay or scope shape.  Thus, it is never consumed by the Orchestration. 



Are these messages useless?


I think so.  I always ignore them.  They will go away when the Orchestration completes or is terminated.  These do not seem to act like normal zombies in that they do not cause the Orchestration to Suspend.



Ok, so you have no idea what I am talking about?


Let me fill you in.  BTXTimerMessages in the Delivered, Not Consumed status are sometimes seen in HAT when working with Timers.  I have not really determined why they happen, but I suspect they should not show up in HAT at all.  I do not think they hurt anything and I pay little attention to them.  When the Orchestration finally ends or is terminated these messages simply go away.  They are annoying and in long running transactions can start to stack up in HAT.  Although, if you try to terminate these messages they will take down the running Orchestration with them.

How to Allow Unrecognized Messages on Send Ports Using Message Context

Have you seen an error that looks like the one below on your Send Pipelines?


There was a failure executing the send pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLTransmit” Source: “XML assembler” Send Port: “some location” Reason: This Assembler cannot retrieve document specification by using this type: “namespace#rootnode”.



This is caused by not having a unique combination of namespace and root node (MessageType).  BizTalk by default does not like unrecognized messages.  The XML Disassembler has a setting to allow unrecognized messages.  But what about sending unrecognized messages?



To allow unrecognized messages inside the Send Pipeline, just set the XMLNORM.AllowUnrecognizedMessage message property to True inside a Message Construct shape.  This, of course, assumes you have to construct your output message inside the Orchestration. 



The statement inside your Construct shape should look like this:


OutMessage(XMLNORM.AllowUnrecognizedMessage) = true;

Root Node Type Name Vs Node Name

I just wanted to take a second to get everyone on the same page since these properties are VERY important in BizTalk. 

If you are a solo developer or you have never renamed a root node, then you may not understand the importance of these properties.First off, what are they?

Node Name: This is the name that is displayed inside Visual Studio for the root node in the schema and for each field element in a property schema.

Root Node Type Name:  Basically, this is what BizTalk will call your root node.  This does not have to be the same as the Node Name, thus the potential for confusion. 

The root node will default to the same name as your root node name when you first create the node or when you rename the root node by changing the Node Name property.  But, it is possible to change the Root Node Type Name, either by accident or on purpose, to something else that is non-meaningful to anyone.

Ok, but how will this really effect me? BizTalk sets a message context property called BTS.MessageType.  This is a concatenation of the document namespace and Root Node Name.  This message type property will show up in HAT and can also cause problems when working with non-unique root nodes with no namespace, but that is a whole other post.

What purpose does this serve? This will allow you to have two schemas with no namespace or the same namespace and the same root node name, but different root node type name.  The benefits of this may not be obvious, but it will allow you to set the message type property inside the pipeline.  This is required if you want to use the message for routing, mapping, or inside a strongly typed orchestration. 

If you do have two messages with no or the same namespace and the same root node type name you may get the follow error at runtime:

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "d:\bt\in\*.xml" Reason: The disassembler cannot retrieve the document specification by using this type: "Root123". Either the schema is not deployed correctly, or more than one schema is deployed for the same message type. 

The same holds true for schemas name and type name on the file properties of a schema.  The schema name has a Type Name property that is used inside the BizTalk Type Picker to reference that schema.  If this name gets changed on accident, it may become difficult for other developers to reference your schema.

CRITICAL: Unlike the Root Node, the file Type Name property will NOT change if the schema is renamed.

Take Away: Be mindful of the Type Name properties on the file and root node level and double check them to make sure they are set correctly.