BizTalk 2009 : Getting Started with Pipeline Development (part 2) - Understanding Interchanges & Overview of Recoverable Interchange Handling

3. Understanding Interchanges

Most BizTalk developers really do not understand or appreciate fully what an Interchange is. An Interchange is a message or series of messages that flow through the Messagebox. Generally, one message = one Interchange. The Interchange is uniquely identified by the InterchangeID-promoted property. In many cases, the Interchange contains more than one message. This is often the case when processing flat-file documents or XML documents that contain envelopes. In this case, there will be one Interchange with as many messages as were contained in the original envelope. Each message would have the same InterchangeID; however, they would all have unique MessageIDs. In pipeline development, only Disassembler and Assembler components need to be concerned about this, since all other components receive one message and return one message. Disassemblers will receive one message and de-batch it into many messages, and the reverse is the case with Assemblers.

In terms of BizTalk processing, an Interchange is the message or series of messages that are received by a receive port and run through a receive pipeline. Interchanges with multiple documents generally relate to batch messages that are de-batched by a Disassembler component within a pipeline. If an envelope message were received with 20 documents inside, the Interchange would contain 20 messages. Each message would contain the same InterchangeIDs within the message context and distinct MessageIDs, as shown in Figure 4.

Figure 4. Description of an Interchange

In BizTalk Server 2004, if a document within the Interchange or "batch" be considered invalid either because of a "subscription not found" error or because the data within the message does not conform to the schema specified, every message within the batch would fail. This had dramatic repercussions for systems that did not want this functionality. Since BizTalk 2006, there is an option on the pipeline to allow it to not fail should one message be bad, continuing processing of the batch and failing only the individual messages that are in error. The remaining messages in the batch would be allowed to proceed. The message that failed can be subscribed to and routed to a generic error handling mechanism such as an orchestration or a port.

4. Overview of Recoverable Interchange Handling

Recoverable Interchange Processing (RIP) is a mechanism whereby the Messaging Engine will allow you to subscribe to special properties that are promoted by BizTalk when an error condition occurs. Typically, this is used in de-batching scenarios where a pipeline will be creating multiple messages in an Interchange. Should an error occur, the recoverable Interchange setting will allow the pipeline to throw an error only on the documents that failed and permit the remaining documents to be passed through the pipeline.

4.1. Message Suspension

If a message is in error and the component processing the message is using recoverable Interchanges, the message in error will be suspended and placed in the suspended queue; other messages will be propagated down the pipeline for further processing.

Once the messages within an Interchange are propagated down the pipeline or placed in the suspended queue, the further processing of those messages is treated transactionally as before. If a message fails at any point during its processing path, except in its routing (for example, no matching subscriber), all of the messages within the Interchange are thrown away, and the originating Interchange is placed in the suspended queue.

4.2. Message Failure Points

If you worked with BizTalk Server 2006 you likely know that failure in the message stages defined here result in the entire Interchange being suspended:

• Validate

• Resolve Party

• Map

BizTalk Server 2009 offers significant improvement and extends Recoverable Interchange Processing to Validate and Map stages. Interchanges that fail processing because of errors in the Resolve Party stage will become suspended. These Interchanges can then be resumed from within the BizTalk Administration Console. However, the Interchange will still likely fail unless the underlying cause of the failure is addressed.

Receiving the following errors will not cause the XMLDisassembler component to stop processing messages from an Interchange:

• Schema not found

• Schema ambiguity (more than one schema exists for the same message type)

• XML validation failed

• Flat-file parsing failed

Interchange processing will stop within the XMLDisassembler component if the message data is not well-formed XML. Since the data is read as a stream, a good check is to see whether document properties that would cause System.Xml.XmlReader to error are present. If they are, the XMLDisassembler will fail as well.

Messages that are extracted from Interchanges but fail because of a "No matching subscription found" error can be successfully resumed. All that is needed in this case is to ensure the BizTalk port or orchestration that has a subscription for the message is enlisted. The message can then be successfully resumed.

The two examples that follow illustrate the differences in Interchange processing as affected by RIP.

Example 1: Standard Interchange Processing Behavior for the XMLDisassembler Component

The following XML is for a document that will be submitted to a receive location and then to the XMLReceive pipeline. This XMLDisassembler on the XMLReceive pipeline is configured for Standard Interchange Processing:

<MyBatch>
      <SubDoc1>MyDataValue1</SubDoc1> //No Error
      <SubDoc2>MyDataValue2</SubDoc2> //Routing Error
      <SubDoc3>MyDataValue3</SubDoc3> //No Error
      <SubDoc4>MyDataValue4</SubDoc4> //Pipeline Failure - will be recoverable
      <SubDoc5>MyDataValue5</SubDoc5> //No Error
</MyBatch>

					  

This batch of messages contains five messages, all of which will be successfully extracted and put into the Interchange. SubDoc1, SubDoc2, and SubDoc3 are processed through the pipeline and are ready to be published.

SubDoc 4 creates an error at the Disassemble stage in the pipeline. This causes all the messages that have already been processed to roll back and the original Interchange message to be suspended as resumable. The net effect is that no messages are published to the Messagebox. The batch is suspended because in Standard Interchange Processing, any pipeline failures cause the entire Interchange to be discarded, and any messages that may have been successfully disassembled are to be thrown away and suspended.

Example 2: Recoverable Interchange Processing Behavior for the XMLDisassembler Component

Using the same inbound batch document as shown in Example 1, if you set the XMLDisassembler to use RIP, the execution that will occur in the pipeline processing will be dramatically different. SubDoc1, SubDoc2, and SubDoc3 successfully pass through the pipeline and are ready to be published to the Messagebox. SubDoc4 generates an error in the XMLDisassembler and will be suspended. SubDoc5 passes through the pipeline and is able to be published to the Messagebox.

Once the entire Interchange is processed, SubDoc1, SubDoc2, SubDoc3, and SubDoc5 are successfully published to the Messagebox. SubDoc4 is placed in the suspended queue. SubDoc2 is then sent to the suspended queue because of a "no subscriber found" error.