Subscribing to an event and
pulling messages from BizTalk Server is a fairly straightforward task. 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 are inbound 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.
1. Strategy for Edit and Resubmit
Subscribing to the WMI event 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.
2. Pulling Data from the Suspended Queue
In pulling the data from the suspended queue, you
could just pull the data itself and try to process 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.
3. 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.
4. Clients for Editing the Message
For editing a document, there are two obvious
options. One is to use an ASP.NET page that will 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 such as formatting issues
with XML and HTML tags, 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.
5. Additional Workflow
In this implementation, orchestration is not used to
control the flow of the SuspendedMessage 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.
6. Moving Correct Data Back into BizTalk
Once data is corrected, it needs to get back into the
Messagebox. One option is to add a web service 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 a direct 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.
7. Sample Flows for Edit and Resubmit
Figures 1 through 3
represent possible flows for editing and resubmission of messages to
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.
The flow in Figure 2
leverages an orchestration to route the message to Windows SharePoint
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-running orchestration 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.
