At its core, BizTalk is a publish/subscribe engine, nothing more nothing less. Whenever a message is received, BizTalk will look through all subscriptions and pass a copy of the message to all the subscribers, if any. The following are the three kinds of artifacts inside BizTalk that can subscribe to messages:
Send Ports
Orchestrations
Request-Response Receive Ports
If messages, for some reason, cannot be sent to one or more of the subscribers, BizTalk will store the message for resuming or later analysis as to why the message could not be delivered. When all subscribers have processed their messages, BizTalk will no longer need to hold on to the message, and the message will be removed from BizTalk. A new subscriber will not be able to subscribe to messages that have already been processed and delivered inside BizTalk.
The following model shows how the BizTalk publish/subscribe mechanism works:
The previous diagram shows a BizTalk Server Group. The BizTalk Server Group consists of at least four databases, which are as follows:
SSODB: This is used to store passwords and other configuration parameters that should be hidden from even administratorsBizTalkMgmtDb: This is a management database that is used to store metadata about the BizTalk Server GroupBizTalkDTADb: This is aTrackingdatabase that is used to store tracking information and actual messages of what has passed through BizTalkBizTalkMsgBoxDb: This is used for storing message parts, message metadata, subscriptions, and so on, which will be covered in detail later
First, BizTalk Server will receive a message through the Receive Port. A message is received in a Receive Port through one of the Receive Locations associated with the Port. A Receive Port contains one to many Receive Locations. Each Receive Location contains one Adapter and one Pipeline. Each Receive Port can hold any number of Maps, but no Map is required.
The Adapter, responsible for communicating with the various applications/protocols needed, receives or picks up messages or batches of messages, writes metadata to the Context (message metadata) of the message, and sends the message to the Pipeline.
Some examples of Adapters are as follows:
FILE
FTP
SQL
HTTP
Web Service (WCF)
SAP
Third party
Custom build
The main purpose of the Pipeline, on the receive side, is to recognize the message type and transform the native format of the message into XML, if needed. Out of the box, two Receive Pipelines are available: PassThruReceive and
XMLReceive. Of these two Pipelines, only XMLReceive will recognize the Message Type, whereas PassThruReceive will send the message onwards to the MessageBox as an unknown type.
Some examples of native formats are as follows:
XML
Flat Files (comma separated values, positional, and so on)
EDI (X12, EDIFACT, and so on)
Excel *
PDF *
The Receive Pipeline will do parts or all of the following activities:
Decrypt the message if needed
Convert the native format into XML
De-batch the message
Promote properties (write metadata to the Context of the message)
Validate the XML message to a Schema
Resolve the sender of the message if signed (see more about this in Chapter 2, Developing BizTalk Artifacts – Creating Schemas and Pipelines)
The MessageBox is a SQL Server database where all messages received by BizTalk are stored, evaluated with all subscriptions, and sent to matching subscriptions.
The main purposes of the MessageBox are as follows:
Storing all subscriptions
Storing all messages (both bodies and Context) entering BizTalk
Storing all Host queues
Evaluating subscriptions
Distributing messages to the matching subscribers
Storing failed and awaiting messages
Whenever a message is received by BizTalk, the receiving message agent will store the message in the MessageBox. During the publishing of the message, the agent will check all the subscriptions inside the MessageBox with the Context of the message, and all matching subscribers will get a reference to the actual message in their respective Host queues. When all subscribers have successfully processed their messages, the message is no longer required in the MessageBox and it will be removed. The MessageBox also consists of all the subscriptions inside the BizTalk Group. Subscriptions are primarily made by Send Ports and Orchestrations; they will be discussed in the following section.
A subscription in BizTalk means that if certain parameters concerning the message are met, the subscriber will get a copy of that message.
A subscription could look something similar to the following pseudo code:
((Message Type = Order) and (Customer = HP)) or (Message Type = Invoice)
This would result in the subscriber getting all invoices entering BizTalk and also all orders from HP.
Subscriptions are made by Send Ports, Orchestrations, or Request-Response Receive Ports. If a Send Port subscription is met, the message will be sent through the Send Port to the target system/location. If an Orchestration activation subscription is met, a new instance of that Orchestration type will be initialized (read more about Orchestrations in Chapter 4, Developing BizTalk Artifacts – Creating Orchestrations). All the matching subscriptions will get a copy of the message, so a one-way message entering the MessageBox can easily have more than one subscriber, and therefore, be replicated to multiple subscribers.
We will further look into Send Port subscriptions in the Setting up a Send Port section later in this chapter.
When subscribing, it is not possible to subscribe to any content of the actual messages entering BizTalk, but only to what information is stored in the Context of the message. The message metadata is called Context Properties; on receiving the message, the Adapter, Pipeline, and Map will possibly add information to the Context.
Context Properties can either be Promoted or Not promoted. Properties that are promoted can be used for subscribing to the message. However, Not promoted properties cannot be used for subscribing to the message.
An Orchestration can receive messages from the MessageBox, based on its subscriptions. The subscriptions can either be an activating subscription (which will start a new Orchestration) or an instance subscription (which will deliver the message to an existing running Orchestration). If an Orchestration needs to send or receive messages during the execution, it will happen through the MessageBox, with the Orchestration submitting messages just as the Receive Ports and receiving messages similar to the Send Port.
When a message is sent to a Send Port, the process is almost reverse of what happened in the Receive Port, except that the location concept doesn't exist on a Send Port.
First, if Maps are applied to the Port, BizTalk will try to match the type of the message in hand with the source Message Type of the Map(s) on the Port; if a valid Map is found, it will be applied to the message.