5. Configuring Recoverable Interchanges
There are two places where
you can configure a recoverable Interchange for the Disassemble and
Validate stages. The first is in the Receive Pipeline Designer, as shown
in Figure 5.
The ability to configure Recoverable Interchange Processing is
available at design time when a custom pipeline that contains either a
flat-file Disassembler or an XMLDisassembler or an XML validator is
being developed. Recoverable Interchanges is a property of that
component.
The second place
to configure Recoverable Interchange Processing is on the receive
location that will process the inbound Interchange. The property is part
of the per-instance pipeline configuration screen, as shown in Figure 6.
To enable Recoverable
Interchange Processing at the mapping stage you have to add the
BTS.SuspendMessageOnMappingFailure property to the message context and
set the value of the property to true in a pipeline component as
follows:
public IBaseMessage Execute(IPipelineContext pc, IBaseMessage msg)
{
msg.Context.Write("SuspendMessageOnMappingFailure", "http://schemas.microsoft.
com/BizTalk/2003/system-properties",
true);
...
}
Unfortunately there is no design-time support for configuring Recoverable Interchange Processing for the Mapping phase.
6. Using the Default Pipelines
In many circumstances,
the default pipelines that ship with BizTalk 2009 are able to handle
most common tasks. For example, most developers do not know the default
XMLReceive pipeline not only removes envelopes and disassembles but also
resolves parties and thumbprint certificates. If you examine the
product documentation, the default XMLReceive pipeline already includes
the default XMLDisassembler and Party Resolution components. Both of
these components can be configured in the per-instance pipeline
configuration screen, as shown in Figure 4-6. In short, if your send or receive pipelines look like those shown in Figure 7,
you don't need to create them. All you need to do is define an envelope
schema inside the schema editor and ensure that each of the documents
contained in the envelope are included in the schema as XSD:Includes
in the case of the receive pipeline. The default XMLReceive pipeline
will do the rest of the work for you. In general, it is always
preferable to use the default pipelines versus building a custom one.
The same is true for the default XMLTransmit pipeline. It contains an
Assembler component that will assemble all messages passed to it in the
Interchange.
In many cases, developers
will simply default to using the XMLReceive pipeline in all
circumstances regardless of what type of document they are processing
and the end target for the message. It is important to note that you do not
need this pipeline to process XML documents. You need the XMLReceive
pipeline to promote properties and validate schemas, but if you know the
destinations for the messages without having to route them, you can use
the pass-through pipeline. The XMLReceive pipeline adds a fair bit of
overhead to the receive-side processes because it is running the
Disassembler and promoting properties into the context. There are
several circumstances in which you need the XMLReceive pipeline, some of
which are as follows:
Need to promote properties from the message's data:
The pass-through pipeline does not promote properties, so any custom
properties you define in the schema will not be recognized. Note that
default properties that were promoted by the adapter will still be
available.
Need to route messages to an orchestration:
An orchestration needs to have the message properties promoted in order
to determine message types. If the end target for the message is an
orchestration and the orchestration is expecting a specific schema, you
need to use the XMLReceive pipeline since this pipeline has the
XMLDisassembler component, which sets the messagetype property.
Need to validate the message:
The pass-through pipeline has no concept of message validation. If you
need to verify that the inbound message's data is correct, you cannot
use the pass-through pipeline. By default, the XMLReceive pipeline also
doesn't perform any validation. If you need to turn this feature on, you
have two options at your disposal depending on what type of validation
you want to perform. If all you need to do is validate incoming messages
against specific schemas, you can configure XMLDisassembler by setting
the Validate Document Structure property. For other types, such as
business-level validation, you will have to write a custom validating
component.
7. Routing Binary Data
Most people do not think that
BizTalk can be used for processing binary data. Since the pass-through
pipeline doesn't examine the message data and since the BizTalk
Messaging Engine uses streams as its data representation, it is quite
easy to move binary data from one source to another. If you need to
promote custom properties for an incoming message, you will need to
write a custom Disassembler, but if you know the locations, all you need
to do is choose pass-through for both the receive and send ports and
ensure that the send port has a valid subscription for the message. Most
commonly this is done by creating a filter that matches based on BTS.ReceivePortName. If you want to route data based on the MessageType
context property, you will need to create a custom pipeline component
that promotes a value into the context. By default this will not happen
with the pass-through pipeline, because technically there is no message
to look at since the data is binary.
