BizTalk Artefacts - Receive Ports and Receive Locations

A receive port is a LOGICAL collection of one or more receive locations that define specific entry points into BizTalk Server. Receive port also specifies Maps which automatically gets executed when receive locations publishes message which matches the input type of Maps. A receive location is the configuration of a single endpoint (URL) to receive messages. The location contains configuration information for both a receive adapter and a receive pipeline. The adapter is responsible for the transport and communications part of receiving a message. For examples File adapter knows how to read a file from a folder/shared drive. The receive pipeline is responsible for converting this message into BizTalk's message so that it can be published into the MessageBox. This receive pipeline is a series of components that are executed in sequence, each providing specific processing to a message such as decoding, disassembling, parsing or validation and party resolution.

Receive Port, Receive Pipeline and its components

Their are four stages of a receive pipeline. They are executed in a defined sequence as shown in above figure. Each of the components in each stage process the message and hand-overs its output to the other component.

1. Decode:  This is the first stage which takes the incoming message from receive adapter and decodes or decrypts it. The MIME/SMIME Decoder Pipeline component or custom decoding component should be placed in this stage if the incoming message is to be decoded from one format to another. After decoding the message is handed over to Disassemble stage.
2. Disassemble: The components of this stage checks the message to see if the format is recognised. The first component in this stage whose format matches the message format is executed. If none of the components are able to recognise the format, message processing fails. The components disassembles the message into individual messages if the message is a batch (or envelop). XmlDisassembler component can be used to debatch and promote MessageType into the message context.
3. Validate: This stage is executed for each message the disassemble stage produces. It validates the message produced by disassemble stage against a schema. Only schema compliant message are processed.
4. Resolve Party: This stage does the job of party resolution, where the Party Resolution pipeline component maps the sender certificate to the corresponding configured in BizTalk Server party. Party Resolution component takes the WindowsUser (populated by adaper or custom pipeline component) and SignatureCertificate (populated by adapter or decoder component) from message context. By using these promote properties the component tries to get the party to which the message belong. So that the message sender can be validated. For more information on Party Resolution please check this article.

Each of the pipeline stages can have 0-255 components with or without custom code as per need.

BizTalk Architecture

BizTalk Architecture Level-2 DFD

In continuation to my previous post which explains BizTalk Server from a very high altitude. This post gives a more drill down view of the BizTalk's core architecture. I have tried to use the same colours and shapes to make it easy to correlate with the previous article.

BizTalk as an integration platform provides flexibility and customizability at every level to make sure that the requirements are met easily. BizTalk provides a variety of artefacts to achieve this. I'll be explaining all the artefacts in the above image in more detail. However, First I would like you to go through the following brief description of the lifecycle of a message in BizTalk Server:

Everything in BizTalk starts with an incoming message from Receiving System (System "A"). This message can be anything ranging from an XmlDocument, Flat File (CSVs or Delimited) or even a SOAP request!

As soon as a message is sent to BizTalk it is taken up by Receive Port which is a group of Receive Locations each pointing to a particular path or URL. Receive location knows which particular Receive Adapter understands the message received. This receive adapter then handles the transport and communication with System "A" and changes the message into a format (most of the time into XMLs) that is understood by Receive Pipeline. The receive pipeline then takes the responsibility of converting this message into BizTalk's message. After Receive Pipeline, Maps if available are executed. They transform the message into a different format as per requirement and then the message is dropped into Message Box.

Orchestrations, Send Ports and Send Port Groups subscribe to message box and constantly checks if the message they are seeking is available in the message box or not. As soon as anyone of them gets the message they pick it up and process it. Orchestrations are optional (most of the time they are available and contains all the complex logic), if they are present they are then executed, if their subscription matches the message in message box. After their execution is complete, they publish their output to message box. Send Ports or Send Port Groups then picks up the message, executes any Map if available in the send port, it then transforms and transmits the message to the Send Pipeline. The pipeline then performs a set of operations and transforms the message into the format that Send Adapter understands. Finally, the send adapter sends the message to the System "B" by using the protocol which System "B" understands.

What is Microsoft BizTalk Server!!!

Microsoft BizTalk Server or BizTalk is an integration server from Microsoft. It enables integration of disparate systems.

Integration is achieved by using different types of adapters which comes with BizTalk (you can make your own as well!) which understands a particular type of system. Adapters are of two types:

1. Receive Adapters: They are used to receive data from other systems.
2. Send Adapters: They are used to send data to other systems.

Broadly, these adapters transform data from different systems into XMLs (eXtensible Markup Language). These XMLs are then processed by BizTalk Server.

The reason behind using XML is that they are understood by almost every system and hence every system provides its own ways to convert its data into XML (and also the other way round).

The below flow diagrams shows a basic interpretation of BizTalk integration model.

Level -0 Data Flow Diagram

Level -1 Data Flow Diagram