Basics of BizTalk Runtime Architecture

To master BizTalk Server, you must first understand its heart: the Publish-Subscribe engine. Unlike traditional point-to-point systems, BizTalk is completely decoupled. This means the sender of a message doesn’t need to know who the receiver is.

The four main pillars

BizTalk runtime architecture primarily has four major components:

• Receive Handler;
• Message Box;
• Orchestration;
• Send Handler.

Receive handler

The Receive handler, held responsible for receiving messages from the channel, contains one or more receive locations.

The journey begins at a Receive Location. The Receive location is a combination of the receive adapter and the receive pipeline.

• Adapters: These handle the “how” (FTP, SQL, WCF). They pull data or listen for incoming streams.
• Pipelines: Once received, the message is “cleaned.” The pipeline converts native formats (Flat File, JSON) into XML and promotes key data into the Message Context. This metadata is what enables routing.

Receive pipeline has four stages:

• Decode: is used for components that decode or decrypt the message like verifying message signatures to ensure integrity, or decoding the S/MIME messages.
• Disassemble: This stage is used for components that parse or disassemble the message. The message gets converted entirely into the XML format so that the messaging engine can understand it.
• Validate: check to see if the message is in the correct format or not.
• Resolve Party: like the decode stage, deals with message security using encryption and digital signature with the help of certificates. (map the sender certificate or the sender security identifier (SID) to the corresponding configured BizTalk Server part)

MessageBox

MessageBox is the publishing area. The messages read from the channel are published into the MessageBox. This that act as the central hub.

• Subscription Matching: The engine looks for any Subscribers (Send Ports or Orchestrations) whose filters match the message’s properties.
• Publishing: After the pipeline, the message is “published” to the MessageBox.

Orchestrations

The Orchestration Engine (The Logic). Orchestrations execute business logic. They play both the subscriber and publisher roles. An Orchestration subscribes to the message – basically, they acquire a subscribed message instance from the MessageBox and carry out business processing. It can perform complex logic, loops, and transformations. When finished, it publishes a new message back to the MessageBox for a Send Port or another orchestration to pick up.

Send handler

The send handler plays the subscriber role. It fetches a message from the MessageBox and pushes it through a channel. Send handler is a combination of the send pipeline and the adapter.

The send pipeline contains three stages:

• Preassemble: pre-processing of the message before it needs to be assembled.
• Assemble: responsible for assembling or serializing the message and converting it to or from XML, in other words, converting the message to a format that can be understood by the external system.
• Encode: is used for components that encode or encrypt the message.

The Decoupled Advantage

Because of this architecture, you can add a new Send Port (a new subscriber) to an existing process without ever touching the code of the original sender. This “pluggability” is why BizTalk remains a powerhouse for enterprise-grade integration.

Key Takeaway for Developers

Always remember: No Subscription = No Delivery. If your message is disappearing, check your promoted properties and your filter expressions.

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.