BizTalk Server: Basic Architecture
Introduction
BizTalk at its core is a software tool, which has can process large numbers of different transactions for an enterprise. BizTalk is an integration tool, used for smooth, secure, robust, durable communication between two or more business partners. There are number of good articles, explaining the architecture of BizTalk. This article summarises information from a number such articles and include some of my thoughts/experience about it.
Publish-Subscribe mechanism
Microsoft BizTalk uses the Publish-Subscribe pattern. In this the Publisher can publish the messages with/without prior knowledge of rthe Receiver. Similarly a Subscriber can subscribe to messages with/without any idea of the sender. In BizTalk, Publishing a message is like publishing it in a message bus, any subscriber waiting for that particular message will get a copy of the message.
By using this mechanism, developers can ensure loose coupling between sender and receivers. For further information please follow this link
Architecture
Components
There are four main components in BizTalk architecture:
- Receive Port
- Message Box
- Orchestration
- Send Port
In BizTalk every valid message gets executed through at least two of above components.
Receive Port: Receiving the message
As the name suggest, the sole purpose of Receive Port is to get the message from partner. BizTalk comes with variety of out of box adapters which we can use for communication. It supports the communication via adapters such as FILE, HTTP, FTP, POP3, SQL etc. We can also use some advanced LOB adapters such as WCF-SQL, WCF-SAP etc. Receive Ports are Publishers of message.
Receive Port contains three sub-parts in it:
A. Receive Adapter
In this section, we need to specify which adapter we want to use for communication. Depending on the selected adapter, we need to configure the different required properties for that. To know more check the link
B. Receive Pipeline
Once we receive the message from Receive Adapter, it gets executed through Receive Pipeline. Here, we can do required transformation, disassemble of payload from bunch. Receive Pipeline can have four different stages. Each stage can contain 0 to 255 components in it (Except for disassemble stage—It can contains at the max one component.)
Stages of Receive Pipeline along with their purpose are as below:
- Decode Stage : To decode or decrypt the message.
- Disassemble Stage : To parse or disassemble the message.
- Validate Stage : To validate the incoming message
- Resolve Party : To map Sender’s Security ID or Sender certificate to the SourcePartyID.
BizTalk ships with some of the components which serves the purpose almost every time. If we have some requirement which cannot be handled by available components then Developers can create their own custom pipeline components. To know more, check the link
C. Inbound Maps
After the execution of Pipeline, we can apply the mapping transformation on the incoming message. We generally use this type of mapping when we want to create some canonical schema. EPM (End Point Manager) takes care for executing the map based on incoming message type. To know more about configuring the inbound map, check the link.
MessageBox – Heart of BizTalk
MessageBox is a heart of BizTalk Publish Subscribe Architecture. It is comprises of two components -- one or more SQL Databases and Messaging Agents. SQL Databases for storing the persistent stage of messages, routing etc. and messaging agent is for message routing purpose (Message publishing, subscription, retrieval).
MessageBox receives the messages which are published by Receive Port, and checks for its subscribers. There are two types of possible subscribers -- Orchestration, Send Port. To know more on MessageBox Database, check the link.
Orchestration (The Business Logic)
An Orchestration is a graphical representation of business logic. In short, we can design the flow message using different available shapes in orchestration. This can be an optional component in the solution. In many of the cases this is not required at all. It comes in picture when we have some complex logic which is not doable by messaging solution.
By implementing Orchestration, message in messageBox gets subscribed in orchestration, after executing the business flow, message is been published in messagebox again by orchestration. This leads to an extra trip of message (MB -> Orchestartion -> MB). Hence developer should try to avoid using orchestration, unless and until it is really required.
Orchestration acts as both Subscriber and Publisher of message.
Send Ports
As the name suggest, the sole purpose of Send Port is to send the message to partner. BizTalk comes with variety of out of box adapters which we can use for communication. It supports the communication via adapters such as FILE, HTTP, FTP, POP3, SQL etc. We can also use some advanced LOB adapters such as WCF-SQL, WCF-SAP etc.
Send Port contains three subparts in it:
A. Outbound Maps
Before the execution of Pipeline, we can apply the mapping transformation on the outgoing message. We generally use this type of mapping when we want to send the message in Partner specific format. EPM (End Point Manager) takes care for executing the map based on outgoing message type.
B. Send Pipeline
The message which we want to send out, it gets executed through Send Pipeline. Here, we can do required transformation, assembling of payload in bunch. Send Pipeline can have three different stages. Each stage can contain 0 to 255 components in it.
Stages of Send Pipeline along with their purpose are as below:
- Preassemble Stage : To perform action before message serialized.
- Assemble Stage : To Assemble/Serialized the message.
- Encode Stage : To encode/encrypt the incoming message
Like Receive pipeline, we can create custom pipeline components for send Pipeline as well.
C. Send Adapter
In this section, we need to specify which adapter we want to use for communication. Depending on the selected adapter, we need to configure the different required properties for that.
See Also
Another important place to find an extensive amount of BizTalk related articles is the TechNet Wiki itself. The best entry point is BizTalk Server Resources on the TechNet Wiki.