Upon closer inspection, it is clear 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.
1.1. Receive Pipeline Stages
Receive pipelines have
specific stages that 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 zero or
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.
1.2. 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 is 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.
2. Understanding Pipeline Execution
Pipeline components execute in a
sequential order starting from the first stages and working down to the
last. The exception to this rule is the Disassembler component, which
will execute sequentially within the Disassemble stage of the receive
pipeline until a component is found that is able to process the message.
The first Disassembler component that accepts the message is executed,
and then the resulting messages are passed to the remaining stages of
the pipeline. When pipeline components execute sequentially, the output
of one pipeline component is used as input to the next one in the
sequence. Note the Disassemble stage in Figure 3.
These components will fire sequentially until one of them determines
that they can handle the incoming message. In this scenario, the first
component that understands the message will execute.
