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.
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.
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.
