5. Configuring Recoverable Interchanges
There are two places where you can configure a
recoverable Interchange. 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 is being developed.
Recoverable Interchanges is a property of that component.
The second place to configure Recoverable
Interchange Processing is on the receive locationthat will process the
inbound Interchange. The property is part of the per-instance pipeline
configuration screen shown in Figure 6.
6. Using the Default Pipelines
In many circumstances, the default pipelines that
ship with BizTalk 2006 are able to handlemost common tasks. For
example, most do 瘂ot know the default XMLReceive pipeline not only
removes envelopes and disassembles, but also resolves parties and
thumbprint certificates. If you examine the documentation as published
in the BizTalk Server 2006 product, 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 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.a name="IDX-CHP-4-0848">
In many cases, developers will simply default to
using the XMLReceive pipeline in all circumstancesregardless 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 due to the fact that 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 doesnot 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 messageproperties 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.
Need to validate the schema:
The pass-through pipeline has no concept of schema validation.If you
need to verify that the inbound message's data is correct, you cannot
use the pass-through pipeline.
7. Routing Binary Data
Most people do not think that BizTalk can be used
for processing binary data. Since the passthroughpipeline doesn't
examine the message data, and 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 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 passthrough 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, as technically there is no message to
look at since the data is binary.
