BizTalk 2006 : Custom Components (part 1) - Component Categories, Component Interfaces

It is critical to understand that each of the different types of pipeline components is designedto do a specific task. Most pipeline component developers generally only include one custom pipeline component inside a custom pipeline and try to perform all tasks within that one class. Often this becomes problematic and leads to an overly complex class. When starting development, the goal should be to write many small generic components instead of a small number of specialized ones. Pipeline components should be designed to be reused. Additionally, if it makes sense, the components should also accept multiple schema types and allow the user to choose the inbound/outbound schemas. Too often developers will hard-code the schema into the component and assume that the inbound messages will always be of a certain type. The component should first of all be flexible enough to probe the incoming schema and determine that it can handle the document, and second provide a user interface for selecting the desired schema in the Pipeline Designer.

Before starting a new project, the most important thing is to understand what type of component you need to build. This will depend on

• Whether the component is executed in a receive pipeline, a send pipeline, or both

• What type of work needs to be done

Too often developers simply "default" to writing what they know instead of what theyshould. Having a thorough understanding of how pipeline components work, along with a proper design for what work should take place at which pipeline stage, will help to build more reusable and reliable pipeline components.

Component Categories

As you will soon see, the pipeline component development API is quite heavily based on COMInterop. Most of the specifics of how components are defined are based on what COM category they are tagged with along with what interfaces they implement. Component categories, listed here, exist for each of the different types of pipeline components:

CATID_Any

CATID_AssemblingSerializer

CATID_Decoder

CATID_DisassemblingParser

CATID_Encoder

CATID_Parser

CATID_PartyResolver

CATID_PipelineComponent

CATID_Receiver

CATID_Serializer

CATID_Streamer

CATID_Transmitter

CATID_Validate

These are defined by tagged attributes on the pipeline component's class as shown in the following code:

Imports System
Imports System.ComponentModel
Imports Microsoft.BizTalk.Message.Interop
Imports Microsoft.BizTalk.Component.Interop
Imports Microsoft.BizTalk.Component
Imports Microsoft.BizTalk.Messaging

Namespace ABC.BizTalk.FullFillment.PipelineComponents

  <ComponentCategory(CategoryTypes.CATID_PipelineComponent), _
                   System.Runtime.InteropServices.Guid("4f1c7d50-e66f-451b-8e94-
2f8d599cd013"), _
          ComponentCategory(CategoryTypes.CATID_Encoder)> _
                             Public Class MyFirstEncodingComponent

					  

Note that it is possible for a component to have more than one category type if it has theproper interface implementation. Also note that the component explicitly defines a GUID for COM Interop. This is done by generating a new GUID using the VS .NET GUID Generation tool, and adding it here as an attribute of the class.

^[] Types including interfaces, classes, and assemblies get a unique GUID even if you don't assign oneexplicitly. However, they can change between builds/assembly versions, so in this case it's best to explicitly assign them so you don't break binary compatibility between builds/versions.

Component Interfaces

The specific interfaces a pipeline component implements are what differentiate that pipelinecomponent from another. BizTalk Server ships with a number of assemblies that define application interfaces for custom components to implement. Once a component has an interface implementation, it can be called by the BizTalk runtime. The basic interfaces are defined in the following list. All components and component categories live in the Microsoft.BizTalk.Component.Interop namespace.

• IBaseComponent: Defines properties that provide basic information about the component.

  Public properties:

  • Description: Gets the component description

  • Name: Gets the component name

  • Version: Gets the component version

• IComponent: Defines the methods used by all pipeline components except Assemblersand Disassemblers.

  Public method:

  • Execute: Executes a pipeline component to process the input message and get the resulting message

• IComponentUI: Defines methods that enable pipeline components to be used withinthe Pipeline Designer environment.

  Public property:

  • Icon: Gets the icon that is associated with this component

  Public method:

  • Validate: Verifies that all of the configuration properties are set correctly