Last week I was getting a response from a service which returned a record. I was simply using xpath function and assigning each record into a destination message. Then I used a transformation shape to map 3 messages source messages to the response message. One of the message was which was assigned a record from the response and the message was being constructed successfully as I was logging the message and saw it in the Orchestration Debugger. But after the Transformation the values were NULL.

All was missing was the namespace in the message and my message type wasn’t correct. If the message types are not correct you will get the following exceptions if you are sending a message to a port. But in my case I wasn’t 🙂

In most of our orchestrations where we need to parse a message lets say for storing data from the message in a database to loop through the records in the message we use XML Parsing. For that we have XpathNavigator class or we can use XMLDocument SelectNodes method which returns an iterator and we can iterate the records in the XML. But consider a complex XML for eg. If there are many parent child nodes and we have to dig deeper into the nodes come back again to the parent and use nested while loops for parsing the whole XML. Well for a good coder this won’t be much of a problem but like a messy coder like me will run into exceptions and bugs. 🙂

Well how about if we take advantage of .NET Serialization/Deserialization? We pass the message as an XMLDocument object to our component method as a parameter we deserialize the xmldocument to an object. But wait which object? From where will it class come from? We just need a proxy class of the web message type. The proxy class will contain the web message type and all of its nodes and then we can deserialize the xmldocument object containing the xml into a much managed object which we can iterate easily. You can generate the proxy class from visual studio command prompt and giving the proper switches will create the proxy class.

If you notice the webservice URI is missing from the command and we need a wsdl of the web service. A simple workaround for this is in our BizTalk Schema project which contains the type of message (schema) is built and then a web message should be published from the BizTalk Web Services Publishing Wizard. Just build your project and run the wizard. In the first step select the “Publish schemas as web services” option. You will get a tree in the next step and yes the web service requires at least a request and response schemas.

Right click the request schema and select the assembly (This assembly should be your BizTalk schemas project).

Select the root node of your schema, in the same way configure the response message as well (of your own choice) and you are done.

In the next step give the URI of the web service and then the hierarchy in your IIS.

By running the command given above you will get the proxy class. Include this class in your component project (which will be most likely a .NET library project). (Note: If you don’t see your schema type class in the intellisense, do check the proxy class and your component project namespaces). In your components method which will be parsing your message deserialize your xmldocument object to the object type of the proxy class. This will be the Root node (If you have one) name of your schema. In my case I used the code below. Xdoc is the object variable name of the type XMLDocument which will contain my xml data. And one more thing which I am sure most of the BizTalk guys will know you can assign your message freely to the XMLDocument type variable in your orchestration.

In the above code I was receiving a response and wanted to insert the records from the response into my table. This made me comfortably access the inner child records and arrays of the XML. May be you would get xml document runtime errors. Do check your XML that if it contains namespaces then deserialization will give exceptions. For this supply the Namespace of the root node in the XmlNodeReader constructor.

Well this error occurs when you have published the web services and BizTalk does not recognize the change in the web services. You can reset the IIS and it works. No need to restart the host instances. As a good practice always publish the web services when the orchestrations which are being published as a web service are stopped or in an unlisted state so this error will not occur.

Like this:

If the trailing spaces of your flat file message is being truncated by BizTalk then the workaround to this is add the (pad_char_type=”none” ) attribute to the (schemainfo and fieldinfo) tags.I used the flat file schema wizard to generate the schema. Before modification my schema looked like this.

The Messaging Engine failed to register the adapter for “SOAP” for the receive location {Location}”. Please verify that the receive location exists, and that the isolated adapter runs under an account that has access to the BizTalk databases.

As this is a permission issue the error occurs because the web service is running on the application pool which security account user is not a member of the BizTalk Isolated Host Users group.

To solve this issue check the application pool security user account in the IIS. Add that user account into the BizTalk Isolated Host Users group. Or change the application pool to the pool which user is already a member of the BizTalk Isolated Host Users Group.