In the previous part of this series, I went through the lowest underlying messaging layer architecture, in detail and now, we are going to move on to another important component, pipelines.

Pipelines are there in the send and receive interfaces to process messages entering and leaving the BizTalk server. Going over some of it fundamentals, their goal is to provide a model for looking at a message and provide all the preparing stages. The processing is organized in well-defined stages.

In the receive line, the stages are as follows:

• Decode, decrypt and decompress message content.
• Disassemble an interchange into smaller messages, also includes converting from flat files and parsing message content.
• Validate message data against the pre defined schema.
• Look up the message for its security context to resolve from what party this message is from and eventually come up to a decision of whether to accept or decline the message before it goes to MB.

In the send side, the pipeline process the message in fewer stages than above, as follows:

• Final Processing as a pre-assemble stage, before sending it off.
• The assemble stage where the message is encoded and serialized to the required format.
• Encoding and encrypting the message contents.

There are some built-in pipeline components that can be used:

1. Assemblers and disassemblers for EDI, Flat File, XML and Biztalk itself.
2. Encoders and decoders for MIME/ SMIME, AS2.
3. Validators for XML.

But there are custom components where you can create your own pipeline.

1. Default Pipelines.
2. Basic pipelines which majority need for the message processing.
3. XML Receive – Contains the XML disassembler (builds the message context) and the party resolution components. It is simple to use where it takes a message and promote its properties.
4. PassThruReceive – Contains no pipeline components. It allows the message to pass without any processing. The Biztalk system won’t get any message properties and type out of it.
5. XML Transmit – Contains the XML assembler component. It take data out of the message context and apply an envelop.
6. PassThruTransmit – Contains no pipeline components. It can be used in scenarios like when a message is already in XML and you just want it to be passed along.
7. EDISend/EDIReceive – Contains EDI assembler and disassembler components.
8. ASDSend/ASDReceive – Contains AS2 encoder and decoder components.
9. AS2EDISend/AS2EDIReceive – the EDI and AS2 components, combined in a single pipeline.

Pipeline Configuration

Normally when a pipeline is created, it has a set of static pipeline configuration properties but they can be modified according to the requirements. In case we want to decrypt the message according to our own decryption component key, customized pipelines can be built by modifying configuration parameters. These properties can be set using the admin tools. Send and receive ports, each of them allow for their own separate pipeline configurations, but a customized common pipeline can be reused over a variety of different send and receive location.

These settings are saved in the configuration database. Custom components can be built for any pipeline stage where this component may replace default implementation. They can be developed as .NET (mostly) or COM components. These components can modify messages as they come in, add extra data or modify original. They decrypt and encrypt the data. They can also promote properties as messages come in which can be useful in scenarios where we can’t use the default property promotion.

Custom components can be built for any pipeline stage where this component may replace default implementation. They can be developed as .NET (mostly) or COM components. These components can modify messages as they come in, add extra data or modify original. They decrypt and encrypt the data. They can also promote properties as messages come in which can be useful in scenarios where we can’t use the default property promotion.

Discussing component development in .net, it is a class with a ComponentCategory attribute which indicates that this is a pipeline component. This class declares other attributes like which stage is appropriate for it to run. It can be limited that this component can only be used in the decode stage. Also, some other appropriate interfaces need to be implemented in order to handle everything e.g: name, icon, description of the component. Some examples are given below:

1. iBaseComponent: properties for name, description, and version of the component.
2. iComponentUI: designer validation and icon of the component.
3. iPersistPropertyBag: the most important of them all which enables to load and save the settings of the component. It contains the costumed configuration.
4. iComponent: It executes method where actually all the work happens. In this method,  processing of the message takes place and after which it is passed along to the next component in the pipeline.
5. iProbeMessage: It is used as a special case of the disassemblers. In that stage, the messaging engine is going to come up to first look for this component and iProbeMessage to then ask if it can handle the message or not. This can be used for initial stages to indicate if the message meets the matching criteria.

Modifying Messages in pipelines

Messages are generally immutable where their properties can be promoted but if to modify, the message must be cloned first with all its parts and context. These are some of the components to help modify messages in pipelines:

1. PipelineUtil – points when message routing fails.
2. PipelineContext – This is a handle to access the helpers like the component location in the pipeline, get access to a schema based on name or type, get access of the message factory to create new messages or a new context, etc.

Deployment of pipeline components can be done in two locations.

1. Directory (preferred)- where Biztalk server look for most components.
2. Global Assembly Cache – Must deploy to the GAC if using pipeline in orchestration. But if you are using Visual Studio, you would want to put it in the Pipeline Components Directory under Biztalk installation because it’s probably going to look there for the component.