What Is BizTalk Server?

If you wanted to explain BizTalk Server to a technology guy, the answer would be:

BizTalk Server is a middleware product from Microsoft that helps connect various systems together.

Let's take an example: If you look at any modern organization, it is probably running its operations using a variety of software products. SAP for their ERP needs, Salesforce for their CRM needs, Oracle for their Database needs, plus tons of other homegrown systems like HR, Finance, Web, Mobile, etc.

At one point in time, these systems needed to talk to each other, for example, customer data that's residing in your SAP system may be required in your CRM system (Salesforce). In a similar way, the contact details you collected from your company website need to go into a few backend systems like CRM, ERP, Marketing, etc.

This business need can be addressed in a layman way by allowing each system to talk to all dependent underlying systems. From our example, the web will have a piece of code that will update contact details in CRM, ERP, Marketing systems, etc. (similar to the way each system will have their own implementation to update relevant systems). If you go down this route you will end up with two major issues: one that creates a spaghetti of connections/dependencies between various systems, and another that, whenever a small change is required, you need to touch multiple systems. There are various other challenges, like understanding the interfaces of all the underlying systems, transport protocol, data formats, etc.

Products like BizTalk server (there are other vendors like Tibco, MuleSoft, IBM Websphere, Message Broker) solves this middleman type problem.

When you use BizTalk Server, all the systems talk to only one central system, i.e BizTalk server, and it's the responsibility of BizTalk to deliver the message to the corresponding underlying system. It takes care of the various challenges I highlighted earlier.

In a real-world example, imagine a BizTalk server as a postman delivering letters. It's impossible for all of us to go and deliver letters to each address, hence we take it to the post office and they take care of delivering it.

If you look at BizTalk from a bird's eye view, you could see that it's a middleware. A middleman who works as a communicator between two businesses, systems, and/or applications. You can found many diagrams on the internet that illustrate this process it as a middleman or tunnel that is used by two willing systems to exchange their data.

If you want to look at it from a more technical standpoint, then you can say it is an integration and/or transformation tool. With its robust and highly managed framework, BizTalk has the infrastructure to provide a communication channel with the capability to provide the desired data molding and transformation. In organizations, data exchange with accuracy and minimum effort is the desired goal. Here BizTalk plays a vital role and provides services to exchange data in the form that your applications can understand. It makes applications transparent to each other and allows them to send and receive information, regardless of what kind of candidate exists for the information.

If you go deeper, you will find a messaging engine based on SOA. To make BizTalk work, Microsoft used XML. People say BizTalk only understands XML. Not true, you can also send binary files through BizTalk. But when you want functionality, logging, business rules, etc., then you can only play in XML. BizTalk has an SOA (Services Oriented Architecture) and many types of adapters are available to interact with different kinds of systems and can be changed and configured at the administrative level.

Next, I'd like to talk about Message Box. Take a look at the following image:

Four major components can be seen.

While it might seem obvious, the receive port is where we receive requests and the send port is where we send requests. But, what are the message box and orchestration bits? 

First, let's talk about the execution flow. The message reaches the receive port through an adapter we configured and it reaches the receive port as we configure its receiver's location and adapter. Then it goes through the pipeline toward the message box. From the message box, the message is sent to it's subscribed port. Note that this message can be sent to more than one port. The message is published in the message box to all recipients. As the port is identified, the message is sent to the port's orchestration mechanism and then is, again, sent back to the message box. It is then sent to the port's map and pipeline. Finally, the adapter sends the message where it should go. Maps are optional, according to your need. The pipeline is compulsory, but few built-in pipelines are available and you can use them if you do not want to do anything in pipelines.

The message box is simply a SQL Server Database. Here we define the message arrive should be sent to which port. The message arrived with the unique signature; we call it the message namespace. This namespace should be unique in the subscription. It helps BizTalk to send messages to the correct location. There is the other type of subscription message and also untyped messages that are routed on the basis of data that contain but those are beyond the scope of this overview.

The receive location is further extended into the receive location, pipeline, and maps. The receive port execution is done in such a manner, the first adapter then pipelines, and then port. The receive location is here as a separate artifact. The configuration of the receive location is important to initiate the service. Here, we define what adapter will be used to get a message. Further, we can introduce a pipeline here. The pipeline is used to perform any operations prior to sending the message to the message box. Normally, we would disassemble any file.

Then the inbound maps are faced, and we can here map the operation. BizTalk Mapper is a tool that ships with a BizTalk Server with a vast variety of mapping operations.

Orchestration is an implementation of your business logic. Microsoft provides a BizTalk template that will install in Visual Studio that has a GUI interface for orchestration, mapping, and other components.

Messages are sent to orchestration on the basis of subscriptions and then again to the Message Box to take note of the changes made during orchestration, and, finally, to the send port. At the send port, we also have a map, pipeline, and adapter to perform any changes at the sending end. This execution occurs in reverse order as compared to the receive port.

This is the execution of any message through BizTalk.