In the first part of this BizTalk for beginners series, I wrote about the BizTalk model and its server Architecture.

In this post, we’ll have a look at Biztalk’s messaging architecture. It is built on service architecture which helps the orchestration layer in it’s function, that runs on top of it. The messages exchanged within the Biztalk architecture are in an XML format. Messages from external processes can be configured to receive via ports into the Biztalk framework.

One of the most important component that aids the functionality of the messaging architecture is the Message Box. Upon receiving a message, the Biztalk must determine where it should be forwarded which can be sent using ports and/or certain instance(s) of orchestration. It acts as a publish and subscribe engine for flexible message routing, by providing a persistent storage where the details about subscribers and all the required data sets are stored in one or more SQL databases. To interact with the database, Message Agent provides tools and interfaces for Biztalk developers.

      The messaging architecture can be described in the image below, as instances of Biztalk Server hosts providing different functionalities. One of such instances provide receive port group and send the port group to get external messages from the external processes and send them off to other systems respectively. These are logical entry and exit points of the system. On arrival of a message, the messages are published to the Message Box where it looks for it’s subscribers and forwards it to them. The subscribers here can be sent port(s) and/or orchestration(s) that had earlier subscribed to that message type. After processing the message contents, the orchestration process may generate one or more messages which are then again published to the MB so that they can be sent off to a required system through their configured ports.

      Now going over the term, the message from the perspective of Biztalk. A Biztalk message contains a context and multiple parts. A context has got the metadata that are used by Biztalk for routing decisions and (maybe) in orchestration. It actually is a collection of name and value properties normally containing details like where the message was received, adapters that were applied on it, identifiers, timestamps, etc. The parts have the original transported data which can be anything from XML to flat files or raw bytes. Incoming messages are converted to objects, it’s properties are taken out and populated and parts get set from the original message data.

    The metadata in a Biztalk message contains its properties. These properties are often defined by the system, but it can be defined separately by developers as well. System-defined properties are in the root namespace and initialized by the prefix BTS. Some of these properties are defined as follows:

        There can be two types of user-defined message properties, promoted (requires a property schema) and distinguished properties. Both are available at orchestrations, but the promoted ones can also be used for routing decisions. They have different syntax declaration. Distinguished properties use a dot notation while promoted property is more of an indexer. Unlike distinguished property, promoted ones can be.There is a size limit for promoted property values (max: 256 chars) because they are going to be written in database tables so that routing gets figured out quickly and hence, querying subscribers for a particular message must be real time. On the other hand, larger data items can exist for distinguished properties. They can be declared in scenarios where the whole message body then need not be reloaded in orchestration.

      Biztalk supports the notion of promoting fields in a schema so that these fields are available during message processing. This can be done with BizTalk editor. Promoted properties require a property schema (common name for values) that are used to build subscriptions.

    Now some basic principles about the subscription architecture, there are two types of subscribers, orchestrations and send ports. Filters are setup to evaluate subscribers for a particular message. These can be in the form of checks for a particular property in the message, expression operators (>,<,!=,=) or combined statements using AND and OR are declared in that case.

    Ports are the logical boundaries to enter and leave BizTalk system. Receive port group are a collection of receive locations. There are associated adapters (get data from the external source), pipelines and maps with every port that are applied to every incoming message in the order mentioned. The pipeline prepares the message in stages to be published to the MB by parsing and promoting the context properties. The maps are applied to normalize the message and to apply the schema. Send port group is a collection of send ports. They also have maps (transform BizTalk to appropriate schema), pipelines and adapters (that transmit the messages out) in line for the outgoing messages applied the same order they are mentioned.

So basically that covers important details about the messaging architecture and in the upcoming part, pipelines will be discussed.