Upon closer inspection, it is clear to see that a
pipeline is simply a container for pipeline components. A pipeline has
"stages" as shown in the Pipeline Designer. These stages differ for both
send and receive pipelines, but they essentially allow you to do two
things: first, they provide a way to logically organize the flow of
execution logic within the pipeline, and second, they give the pipeline
component developer different APIs to code against depending on what
type of pipeline component is needed. If custom pipeline development is
something that you haven't tackled before, ask yourself the following
questions before you get started:
What is the end result of my pipeline's execution? What types of message are expected?
Will
my pipeline need to look at the message's data? If it does, how big are
the messages? Can I stream them using the XMLReader, or do I need to
load them into an XML DOM?
Is the pipeline schema agnostic, or does it need to validate the incoming message type?
Does my pipeline need to create multiple messages based on the incoming message or just one?
How
do I handle exceptions within the pipeline? Do I need to log them? Can
the pipeline throw an exception and stop processing, or does it need to
output an error document?
Do I have all the necessary context properties in the message context?
Will I be promoting custom properties?
1. Pipeline Stages
Custom pipelines are divided into receive and
send pipelines. Both types of pipelines have stages unique to either
sending or receiving messages. Each stage of the pipeline has the
ability to contain multiple pipeline components that are designed to be
executed within that particular stage. For example, a receive pipeline
may have several components within the Decode stage. The components will
ex璽cute sequentially from the first to last within the stage. In the
case of stages with multiple components, the output of one component
will be used as the input for the next. The exceptions to this rule are
Disassembler components. These types of components execute on a "first
match" rule: the rule states that the first component in the Disassemble
stage that is able to process the message will be chosen to execute.
The remaining components in the stage are then ignored, and processing
continues with the next stage in the pipeline.⣃a name="IDX-CHP-4-0773">
Receive Pipeline Stages
Receive pipelines have specific stages hat help
in processing the message in a logical fashion. The surface of the
Pipeline Designer is shown in Figure 1. Each of the stages of the pipeline is designed to perform a specific task:
Decode:
This stage is used to perform operations that are required to "read"
the incoming message. Think of the Decode stage as where you would
perform things like decryption, decompression, and any processing logic
that will be required as input data for the subsequent stages.
Disassemble:
Components tagged as Disassemblers are designed to produce multiple
messages based on the input message. Disassemblers often are used to
de-batch the incoming messages into multiple smaller messages. Each of
the messages produced by the Disassembler are then passed to the
remaining stages within the pipeline.
Validate:
This stage is used to ensure the message that has been decoded and
potentially produced by the Disassembler is considered to be "valid"
according to the pipeline rules. Often this involves verifying the XML
schema of the message to be of a certain type. Custom validators are
often created for custom business-level validation logic (i.e., ensuring
that the purchase order number of an incoming message is valid and
exists within a database).
Resolve Party:
This stage is used often in trading partner exchange scenarios. This
stage is usually used to examine the digital certificates of a signed
message to ensure the validity of the sending party.
Send Pipeline Stages
Send pipelines have specific stages that are
related to preparing the message to be sent out of BizTalk. The surface
of the Send Pipeline Designer is shown in Figure 2. Each of the stages of the pipeline are designed to perform a specific task:
Pre-Assemble: This stage is often used to gather any specific information that will be needed by an Assembler and add it to the message.
Assemble:
Assemblers are responsible for combining multiple smaller messages into
one large message. This is often the case when you are aggregating
several messages into a batch. Assemblers are also often used in
flat-file conversion and EDI scenarios to aggregate the outbound flat
file into one large batched file.
Encode:
Encoders are responsible for writing the message in a fashion so that
it can be read by the downstream system. Often this involves ensuring
the proper character set is used, compressing the message, MIME
encoding, or attaching a digital certificate.
