Biztalk Receive Pipeline Woes
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
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