To put it in simple terms, the BizTalk 2006 server streamlines business processes by interconnecting various IT systems. It’s important for managers and IT staff to understand the basics of how the various systems are tied together.
We must first understand the basics of message flow in order to understand how Microsoft BizTalk Server 2006 works. Or in layman’s terms, how the BizTalk server processes business requests between different applications.
First step of message flow – “receive port” receives a message
A receive port has three components, the first being an adapter that communicates an incoming message in a specific way. BizTalk 2006 uses adapters, which are the fundamental building blocks that make interoperability possible – when a BizTalk server is being setup, the developer decides the adapters a particular application needs to use.
Next, a receive pipeline validates the message’s digital signature by transforming the message from its original format into what’s known as an XML structure. An increasing number of applications have XML capabilities built in but many do not. Therefore, a pipeline is constructed from a number of stages that contains one or more components…each component handles a particular part of message processing.
The third part of the receive port, known as data mapping, transforms the message into something useful. Developers create maps tailored to their specific needs and it’s their responsibility to decide what the XML structure coming from the pipeline will look like – or rather specify what the XML schema will look like.
A message is then delivered into the message box, a SQL server database
Once a message reaches the end of the receive port, it goes to a message box – a storage unit of different subscriptions, which a particular orchestration and send port subscribes to.
For instance, one subscription in the message box may be for all messages containing the phrase “invoice”. Messages from the receive port containing this “keyword” will route itself to that subscription in the message box. The orchestration then processes the request that will be sent to the other application.
Developers in the field define these properties that are custom made to the company’s needs.
After an orchestration processes a message, it produces another message that is sent to the other application. This message is sent back through the message box as an XML formatted message and picked up by a send port, where the message transfers on to the other application. The outgoing message box subscribes to the same properties/keywords as the incoming one.
Send port process is essentially the opposite of the receive port process
When a send port picks up an orchestrated message, the process is effectively a reversal of the receive process.
A message is first mapped into a useful format. Then the format is changed from XML format to a readable format for the other application by a send pipeline. Finally, the send adapter transmits the message to the other application.
Of course, this is a simple explanation of the process Microsoft BizTalk 2006 follows to integrate different systems into one cohesive unit. Continue reading this white paper from XComPC.com to learn more in-depth how BizTalk 2006 makes business processes function more effectively.