BizTalk 2006 : Editing and Resubmitting Suspended Messages (part 1)

Subscribing to an event and pulling messages from BizTalk Server is a fairly straightforwardtask. A bigger problem is that now that you have the suspended message, how do you fix it and get it back to BizTalk? Ultimately the answer will depend on the roles involved, the technology that is used, and the business process necessary around handling the messages.

For the purpose of this implementation, the suspended messages that are addressed areinbound messages that fail validation. This can often happen when a message is sent into the integration solution that is malformed. Other errors may occur, but this is the most common scenario for resubmitting messages.

Strategy for Edit and Resubmit

Subscribing to the MSBTS_ServiceInstanceSuspendedEvent and calling the SaveToFile method allows access to the suspended message and its context.^[] If it has multiple message parts, each is saved to a separate file. The context file contains the message and message part information. This gives developers all the information they need to handle the message.This implementation will use those concepts. After this point, there are a number of different decisions that you will need to make. The rest of this section briefly addresses a number of those decisions.

^[] These subsections and upcoming exercise originally appeared in "Edit and Resubmit from Suspend Queue" (REED000632).doc. Copyright by Microsoft Corporation. Reprinted with permission from Microsoft Corporation.

Pulling Data from the Suspended Queue

In pulling the data from the suspended queue, you could just pull the data itself and try toprocess the message, but then you are lacking any context for the origination of the message. Most likely this context will be necessary in order to route the message to the appropriate support personnel, resubmit the message, or take other steps with the message. To handle this problem, the same Windows service that you will create to capture the suspended event will create a new canonical format based off the message context and the message data.

Canonical Format

One strategy this implementation is using is a canonical format for the suspended message, SuspendedMessage.xsd. This contains a context section for the message that can contain any particular contextual information that needs to be passed along. For example, the receive port name may be included. The other part of the message contains the message parts themselves. In the walkthrough described later in Exercise 1, the data is stored in an element that is marked as a CDATA tag. CDATA sections are ignored by XML parsers and allow you to include any data you want in them, regardless of format.

Clients for Editing the Message

For editing a document, there are two obvious options. One is to use an ASP.NET page thatwill take the raw data file and display it in a text box. The other is to use InfoPath, which could consume the canonical XML document and display that in a form. InfoPath is a natural fit for this, except that the data you want to edit is one element in your XML document, but represents your entire message. If the message is a flat file, it could contain invalid XML characters. To get around this problem, you could place the data in a CDATA section. The challenge though is what control to use in InfoPath. There are restrictions on using a rich text-box control, which would otherwise be a great choice. A text box is possible with XML documents. Also in InfoPath SP1, you can specify the text box to show carriage returns.

Additional Workflow

In this implementation, orchestration is not used to control the flow of theSuspendedMessage XML file. If this example were expanded, it would be advantageous to use an orchestration. With an orchestration, the SuspendedMessage XML document could be sent into the orchestration, do some additional processing, call rules, and then route the document to the appropriate user or group of users who need to fix the message. Once the user fixes the message, it could be routed back to the orchestration, and the orchestration could do further processing. Also, by using an orchestration, you could later leverage BAM to be able to get additional insight into your suspended messages.

Moving Correct Data Back into BizTalk

Once data is corrected, it needs to get back into the Messagebox. One option is to add a webservice receive location to the same receive port where the messages were originally sent. This will allow orchestration-bound ports and subscribers to a receive port to still receive the message. The disadvantage is an extra receive location is necessary for each receive port that needs to handle suspended messages.

Another option for moving data back into BizTalk is to have a generic orchestration do adirect binding and send the data directly to the Messagebox. As long as no routing is based on the receive port, you will still be OK. However, if the message is a non-XML file that must first be disassembled, you need to send it back through a receive location for pipeline processing.

Sample Flows for Edit and Resubmit

Figures 1 through 3 represent possible flows for editing and resubmission of messagesto BizTalk Server. These are just possibilities that have their own pros and cons. Hopefully, this will give you some additional ideas on how to best handle suspended messages for your particular solution.

Figure 1 illustrates the easiest, although most manual, of the three flows.

Figure 1. Editing and resubmitting with file receive

The flow in Figure 2 leverages an orchestration to route the message to WindowsSharePoint Services. This strategy would allow the solution to be able to route messages to different groups and people based on their roles. The Business Rule Engine could be used to implement the routing logic. The Business Rule Engine could provide the URL and adapter information for message resubmission based upon a given message type. When resubmitting the document back to BizTalk, the client would send the message back to a web service that is specific for that particular message type. A solution could have the flow shown in Figure 2.

Finally, the flow in Figure 3 builds off of that in Figure 2 and uses a long-runningorchestration to keep track of the progress of the message. This allows further processing to be done if desired. The solution also submits directly back to the Messagebox, which may or may not be desired depending on whether the message requires processing in a receive pipeline.

Figure 2 . Editing and resubmitting with routing and SharePoint

Figure 3 . Editing and resubmitting with orchestration correlation