Understanding the publish or subscribe model

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 administrators

• BizTalkMgmtDb: This is a management database that is used to store metadata about the BizTalk Server Group

• BizTalkDTADb: This is a Tracking database that is used to store tracking information and actual messages of what has passed through BizTalk

• BizTalkMsgBoxDb: This is used for storing message parts, message metadata, subscriptions, and so on, which will be covered in detail later

Receiving the message

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.

Tip

Only one Map per input message type is allowed on each Receive Port or Send Port.

Adapter

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

Pipeline

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 *

  Tip

  * Not included in BizTalk, needs to be custom written or purchased from third-party vendors.

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)

Maps

Now, the message is evaluated with the Maps applied on the Receive Port (if any); if the message matches the source message type on a Map, the Map will be applied.

Tip

If the output of the Map executed again matches the source of another Map on the Port, this Map will not be executed; only one Map can be applied to a message on a Port.

MessageBox

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.

Subscriptions

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.

Message Context Properties

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.

Orchestrations

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.

Sending the message

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.

Maps

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.

Tip

Just as Receive Ports, there will only be one Map executed on a Send Port.

Pipeline

Next, the Pipeline will typically do some or all of the following activities:

• Validate the message

• Convert the message from XML to the desired target format

• Encrypt and sign the message if needed

Adapter

Finally, the Adapter will transmit the message to the destination location.