Just another technology enthusiast

Posts tagged ‘component’

Why you can’t access some promoted / distinguished properties inside the pipeline.

Some of us when new to building custom pipeline components would have faced this problem, especially with long messages.

You have a custom pipeline component placed downstream after the disassembler component and expect that the disassembler component would have promoted / written the required schema fields into the context, so that your component can reach out to the context and access them, but you find that it fetches a null even when the message has a value.

This is because the pipeline works in a streaming fashion, which means, all components in the pipeline gets started as the message flows through them. For example, before the disassembler has finished its work, your custom component kicks-in and tries to access the context. Now if the value that you are looking for is somewhere at the end of a lengthy message, it would not yet have got read by the disassembler to be able to promote it into the context, but your custom component already tried fetching it and failed.

One easy solution to this is to read the entire stream from your custom component before accessing the context, this will make sure that all previous components have finished its job and have promoted / written the value into the context. However this is not a good approach as you will end up reading the whole message into memory and may cause an Out-Of-Memory error. You will also anyway need to convert it back to a stream and reset the stream pointers before you can pass it on further since the whole BizTalk architecture is stream based.

Another option (the correct way, but a bit more complex) is to wrap the stream in your own stream and hook to its events to notify when it had finished the reading fully, so that you can go ahead and access the context.

If you are building a custom pipeline component, maybe its worth checking out an undocumented class called XpathMutatorStream, defined within the Microsoft.BizTalk.Streaming namespace (available only in the GAC, Microsoft.BizTalk.Streaming.dll)

Check out the following article by Martijn Hoogendoorn for more on this:  http://martijnh.blogspot.com/2006/03/xpathmutatorstream.html

Did you know that XMLReceivePipeline by default does not validate the contents / structure of the message?

The XMLReceivePipeline, based on the MessageType of the input message, will try to lookup a document specification (schema) and if it finds one, will do all the required property promotions / distinguish fields as specified in the schema and also promote the MessageType. If there is no schema deployed in BizTalk that match the MessageType of the input message, it simply throws an error as shown below.

Finding the document specification by message type <MessageType of the input message> failed. Verify the schema deployed properly. 

On the other hand, if you are using a custom pipeline with “XML disassembler” component and you have added your schema in the document schemas collection, it will check to see if the MessageType of the input message match any of the schemas specified in the Document schemas collection ONLY, if not, it will throw an error a shown below.

No Disassemble stage components can recognize the data.

Note that, this error occurs even if you have a schema deployed in BizTalk that matches the MessageType of the input message, but is not available in the Document schemas collection of the custom pipeline.

To validate the input message including its contents and structure, you need to create a custom receive pipeline and add both the XmlDisassembler and XmlValidator components. On the XmlDisassembler you set the “Validate document structure” to true. XmlValidator will validate the contents as specified in the schema.