BizTalk Server 2004: Receieve Pipeline woes v2
A few days ago I posted an article on certain behaviours we had observed and investigated in relation to BizTalk receive pipelines. If anyone has been reading the feedback to the post, you will be aware that since then I’ve managed to make some further headway in this matter. My previous article simply described the behaviour and offered some speculation. I now know more about the causes. This new article is intended to replace the previous article, which you can still read here. The problems we encountered resolved themselves into two distinct issues. One is an issue with the XmlDisassembler component, and the other is a ‘feature’ of BizTalk’s handling of inbound maps on receive ports. This article describes these two issues, their characteristics and causes and how to avoid them or implement workarounds. It also provides some additional background information on inbound maps and some general guidelines on designing and implementing custom pipeline components. Inbound Maps
BizTalk allows maps to be assigned to receive ports. You can assign multiple maps to a single receive port. Maps are assigned at port level, rather than at the level of receive locations. One of the great benefits of in-bound maps is that you can use them to transform messages before they hit the message box. This makes it easy to ensure that different messages, submitted to different receive locations, are transformed into canonical formats before being routed to service instances by BizTalk’s subscription mechanism. BizTalk decides, on a per-message basis, which available inbound map, if any, to use. It does so by inspecting the context of each message, looking for a promoted property called MessageType. This property is central to a number of BizTalk functions, and specifies the type of the message. The value of the property concatenates the target namespace (if any) of the schema that describes the message type, and the name of the document (i.e., ‘root’) element. The document element name is included as a URI fragment specifier. The MessageType property is chiefly used by the BizTalk subscription mechanism to route messages. It is marked as a promoted property within the message context in order to allow the subscription mechanism to operate on it. The property is generally set by a disassembler component, but could potentially be set by any pipeline component in another pipeline stage. When one or more inbound maps are assigned to a receive port, BizTalk uses the MessageType property to select a map by comparing the value of the property to the source schema of each map. When a match is found, the map is executed over the content of the body part of the message, and the results are assigned back to the body part. If no match is found, no map is executed. This is not treated as an error, and the un-transformed message is delivered to the message box. Stream Processing
Maps are executed after pipeline processing has been completed. They operate on the contents of the body part of the message delivered by the pipeline back to BizTalk. This message may be different to the message initially provided to the pipeline. For example, it is sometimes necessary for pipeline components to replace an existing stream with a new stream (possibly within a new message and message part), although this should generally be avoided wherever possible. Replacing one stream with another is often a sign of lazy pipeline component programming and tends to be inefficient because it generally involves saving away the contents of a stream in a stateful manner in order to subsequently write the content to another stream. The whole point of employing a streaming approach within pipeline processing is to promote an efficient, stateless model of message content processing. The chief philosophical difference between the EPM (messaging) and XLANG/s (orchestration) host instance sub services is...
Please join StudyMode to read the full document