The message box is probably one of the basic concepts of BizTalk 2004 and also widely explained over the Internet. However, my purpose of writing this here is to jot down my understanding. Also if any BTS 2004 expert stumbles on it, he might take a chance to review and provide his comments which may further enhance my understanding.
So as it goes, the discussion here would start with the basics of a BizTalk message, further explaining the “Publish-Subscribe” architecture that is followed by the BizTalk Engine to explaining the actual role of message box in a simple orchestration.
So what are the Messages?Messages are the basic elements of the BTS 2004. BizTalk being a "message-oriented" middleware, they form the core part of the workings.
Each piece of information that is processed by BizTalk is in form of "Messages", including the data that is passed over the WebService calls or the File receives.
Each message in BizTalk is treated as a multi part message with each part consisting of binary data that can represent an Xml document or a serialized .net class or just another message part.
Each message follows a defined Xml schema and has a document type that is same as the root element of the schema.
A message, by its nature, is immutable. This means that a message once created, cannot be modified at anytime during or after its processing. A message can be constructed either by the adapters or in the orchestration using the Construct Message shape. Construction of a message involves creating an entry in the message box database.
To modify a message, the message is copied over to another instance of the message and then modified. The original instance remains the same. This is useful for the message tracking feature offered by the BizTalk. The procedure helps the BizTalk Server to track the state of the messages at each step in the process.
Each message that is processed by BizTalk Server will posses a unique identifier (GUID) with which the message is distinguished in the message box.
In addition to this, a message can have its fields promoted as properties. Promotions help the filtering of the messages from the message box.
The promoted properties of the message are stored in a separate property schema that can be loaded in the memory as a property bag. This helps determining the properties of the message instance without loading the entire message in the memory. Hence property fields are used for filtering in the message subscriptions.
The Publish / Subscribe Architecture
Fundamental to BizTalk is the Publish / Subscribe Architecture. This architecture basically comprises of 2 main components. A publisher, who would be responsible to publish the message in the message store and a subscriber, who will subscribe to messages of a particular format so that he gets them whenever they are published.
Publishing refers to the process of inserting the messages in the message box database. Normally, a receive port, an orchestration or solicit send port would be involved in publishing any message to the message box.
A receive port would receive the message from the pipeline and publish it to the message box for an orchestration or a send port to pick up. An orchestration would publish the message usually while sending it using the send shape.
A solicit response port would actually publish the message when it receives a response from the end system.
The subscribers would indicate the message they would like to receive by a set of criteria or filters.
Thereby, whenever a message is posted or published to the message box database, a subscriber will be able to get the message based on the filters or criteria mentioned while subscribing. The filters can be specified only on the promoted fields on the message.
The Message BoxThe message box is the heart of this messaging system. It manages the communication and routing of the messages to and from the BizTalk Server. The message box essentially comprises of one or more SQL Server databases and a Messaging Agent.
The SQL Server database(s), commonly known as the message box database is responsible mainly for persisting the messages, message parts and the promoted properties. Apart from this, the message box database also contains several stored procedures that determine the business logic for various tasks like Finding Subscribers, Message Routing etc.
The Messaging Agent provides a layer of abstraction over the message box database. It uses the .Net COM interop to expose a set of APIs that the BizTalk Core engine can use to communicate with the message box database.
In effect, the messaging agent abstracts and encapsulates the Message Box Database.
The Agent is used as an interface by the BizTalk Core engine as well as other publisher components including the Adapter framework.
The Big pictureGetting together the above mentioned pieces, let us try to get the whole picture with a sample orchestration.
Let’s consider a simple file transfer orchestration for the purpose.
The orchestration would simply receive a XML message from the file adapter, work over it, passing through a simple map and the modified message will be sent to another file system location using the File Adapter again.
A File drop in the file receive folder would invoke the receive location that will pickup the message handing it over to the File Adapter.
The Adapter takes up the responsibility from here to get the data in the Biztalk paradigm.
Once through the adapter, the message is handed over to the pipeline where it will be validated and any format conversions, if required will be carried out.
The pipeline ensures that the message is converted in a valid xml and then posts the message to the message box. Based on the message type and the promoted properties, the Message Agent will find the subscribers that will be interested in consuming the message. A routing failure occurs if there is no subscriber interested in the published message. This condition would normally occur if the receive location is enabled, but the orchestration is not enlisted / started.
The consumer here is the orchestration that is waiting for this message. Alternatively, a consumer can also be a send port to which the message can be directly routed to. (The mentioned scenario can also be executed with help of a receive and send port and a map without any orchestration).
The subscriber here will be the logical receive port that is configured in the orchestration.
As a consumer, the receive shape will consume the message and activate the orchestration. The message is carried over to the transform shape. The transform shape, as we know has to be in the Construct Message scope. The cause for this enforcing can be traced back to the same fact, that messages, by design, are immutable.
Therefore, when transforming, it is mandatory to create a new instance of the message. This is enforced by the Construct Message scope. The Transform shape will create new message using the maps defined.
This message will be carried over to the send port will eventually write the message to the file using the File Adapter.
Hence, as we look at it, the BizTalk Message Box database forms an integral part in any of the processes that can be carried out by the Microsoft BizTalk Server 2004. As seen, even in cases where we would not need an orchestration, the message box would be involved in transportation of the messages from the physical receive locations to the send ports.
Happy Biztalking!!
