Module 5:Routing BizTalk Messages

Time estimated: 135minutes

Module objective:

In this module, you will learn the purpose and scope of the Microsoft BizTalk Server publish and subscribe messaging models and how to configure BizTalk message routing.

Overview

Microsoft BizTalk Server provides a mechanism for routing, processing, and sending messages between business processes. Content-based routing (CBR) is a method of routing messages based on the context and/or content of an incoming message. BizTalk provides two methods of monitoring and tracking message activity, which enables developers, administrators, and business users to diagnose messaging problems. This module shows you how to enable message routing and use BizTalk tools to monitor live and archived message activity.

Lesson 1: Introduction to Message Routing

Lesson objective:

Explain how BizTalk Server 2010 routes and processes messages.

Overview

The BizTalk messaging system consists of components such as receive locations, receive and send ports, pipelines, and the MessageBox database. The component that is responsible for the actual message routing process is referred to as the messaging engine. This lesson provides an overview of how the BizTalk messaging engine works to process messages and how message routing is enabled.

The Publish and Subscribe Architecture

Describe the publish and subscribe routing model used by BizTalk Server for routing and processing documents.

The Publish and Subscribe Architecture

BizTalk Server uses a publish and subscribe (or pub/sub) messaging model. The pub/sub model is highly scalable at both the database and processing levels. This pub/sub routing mechanism can manage large volumes of messages and large individual messages, and can interact with a wide variety of back-end systems. This design also makes adding and changing subscribing components on-the-fly extremely easy.

Publication

Publication is the process by which messages are placed in the MessageBox database. The principal publishing component in BizTalk Server is the receive port, which receives and processes messages into the database. Orchestrations also publish messages as they are sent from the orchestration to the MessageBox database for further routing. Properties defining which messages will be routed can be promoted as the message is being processed through receive pipelines and can also be specified in the business process (orchestration) itself. Each of these processes will be detailed in upcoming modules.

Subscriptions

Subscriptions are criteria on which message routing is determined. Orchestrations, send ports, and send port groups can each subscribe to messages. Each subscription allows the subscriber to initiate or continue the processing of a message. Subscriptions are managed by the MessageBox database.

When a message meets the specifications of a subscription, the message is passed from the MessageBox database to the subscriber. If multiple subscribers exist for a given message, each gets a copy of the message.

The preceding illustration outlines the steps in the publish/subscribe model, as follows:

  1. Subscriptions are created for each subscriber (send port, send port group, or orchestration) by configuring a filter expression. For example, this expression could be for all purchase order messages with totals over $10,000.
  2. A message is received, processed, and published to the BizTalk MessageBox database. Messages can be received through a variety of different adapters, including File, FTP, and HTTP.
  3. Subscriptions, which are maintained by the MessageBox database, are evaluated to determine which subscriber(s) should receive a copy of the message.
  4. Each subscriber will receive a copy of the message (with a unique message ID). The message stays in the MessageBox database until all subscribers have received and successfully processed the message.

At each stage in the processing, data necessary for tracking messages is written to a separate database (the tracking database), where it resides until deleted by administrative action.

What Is the MessageBox Database?

Explain the purpose of the MessageBox database and how message subscriptions work.

MessageBox Database

The MessageBox database stores messages and message properties, and it maintains message subscriptions. The messaging engine delivers the messages from the database to subscribers. The MessageBox databases also store the queues and state tables for each BizTalk host.

Messages are immutable once they arrive at the MessageBox database, but beforehand, messages can be manipulated in a variety of ways, including validating the message against a known schema, promoting specific nodes to be used in message routing, decrypting a message, or transforming a message by using a BizTalk map. Each of these processes is addressed in other modules in this course.

Adding MessageBox Databases

MessageBox databases are the basis of work-item load balancing across multiple servers that perform cooperative processing. With all of the messages and processes that the MessageBox database is responsible for, it can rapidly become a bottleneck in a BizTalk environment. To increase the number of messages that your system can process, you may need to create additional MessageBox databases. With the Enterprise edition of BizTalk Server 2010, you can use the BizTalk Administration Console to create multiple MessageBox databases.

When multiple MessageBox databases are in use within a BizTalk Server Group, the master MessageBox (the first one created) acts only as a router and routes all new messages to the other message boxes for processing. A degradation of performance can occur when there are only two MessageBox databases because the messages are still being processed by only one database since the master database performs only the routing of messages. Therefore, it is highly recommended that when using multiple MessageBox databases you have at least three MessageBox databases.

A single computer running Microsoft SQL Server™ can host several BizTalk Server MessageBox databases before the server becomes overloaded. Determine the performance impact of the computer running SQL Server when implementing multiple MessageBox databases. You can designate local and remote databases as MessageBox databases. Verify that the SQL Server Agent is running on all computers running SQL Server before adding a new MessageBox database so that database maintenance tasks are performed.

Note: Refer to the “How to Add a New MessageBox Database” and “Creating a Highly Available BizTalk Server Environment” topics in the Microsoft BizTalk Server 2010 documentation for more information about adding MessageBox databases.

Disabling New Message Publication

As noted, several separate MessageBox databases can receive and store (publish) messages at any time. If it is necessary to delete or move a MessageBox database, you should first disable new message publication. Also, if you have multiple MessageBox databases, the master database may experience an improvement in performance if new message publication is disabled on the master MessageBox database. Disabling new message publication does not affect existing messages because any existing messages stay in the original MessageBox databases. You can use either the BizTalk Administration Console or Microsoft Windows Management Instrumentation (WMI) to disable new message publication.

Deleting MessageBox Databases

Situations may arise in which you want to delete a MessageBox database from a BizTalk group. For example, you might want to delete a MessageBox used for a series of tests now concluded. You can use either the BizTalk Administration console or WMI to delete a MessageBox database. Deleting a MessageBox database from a BizTalk Group does not actually remove the database from SQL Server. To remove the MessageBox database completely and permanently, you must remove it by using SQL Server Enterprise Manager after it is removed from the BizTalk Group.

What Is Message Routing?

Describe the concept of message routing.

Message Routing

A typical BizTalk Server business process involves receiving, processing, and sending messages. At times, you may receive messages (such as partner-to-partner correspondence) that do not require intensive processing in an orchestration, and that could therefore benefit from a simpler solution. The BizTalk content-based message routing model provides great flexibility in the way that messages are handled. For example, two incoming messages of the same type can be processed differently based on a customer name or a total order amount.

Scenario

One common scenario that requires message routing is when a receive port is configured to receive a single message type, as in the case of a purchase order (PO). Assume that you have created a send port to an ERP system and that you have configured a map that needs to receive a copy of all POs. You can configure the filter on the send port to process all messages received through the specified receive port. Additional send ports and filter expressions could be added to route messages based on other properties.

Examples

The preceding illustration shows three send ports, each with a different filter for content-based routing. All PO messages in which the CustomerName field contains Contoso are to be routed to send port A. All messages with the Price field greater than 1000 are routed to send port B. All messages with a quantity greater then 500 and in which the Price is less then 1000 (which may represent an error condition) are routed to send port C. A message is routed to all send ports for which it meets the filter criteria. Therefore, if a PO is received from Contoso, in which the Price is over 1000, a copy of the message is routed to both send ports A and B but not send port C.

What Is a Port?

Describe how BizTalk Server uses receive ports and locations to receive messages and how it uses send ports to send messages.

Ports

Ports specify how messages are sent and received inside BizTalk Server, as well as between BizTalk Server and external processes. Each port has a direction, a transport type, and a binding, which together determine the direction of communication (one-way or two-way), the pattern of communication (one-way or request-response), the location to or from which the message is sent or received, and how the communication takes place. A port’s binding may refer to the physical location of a read or write, the pipeline used for message processing, or an orchestration.

A port must be associated with:

  • A Universal Resource Identifier (URI—a physical location).
  • A transport (examples are File, HTTP, and BizTalk Message Queuing).

A port may be associated with:

  • A send pipeline, to prepare a message for sending. For example, pipelines can be used for assembling, encrypting, compressing, or performing some other action on a message.
  • A receive pipeline, to prepare a received message for processing. For example, receive pipelines can be used for disassembling, decrypting, or decompressing a message.
  • A map, to transform messages from one type to another.

Note: Pipelines are covered in greater detail in Module 6, “Creating Pipelines.”

BizTalk Message Flow

Describe how messages are processed through BizTalk messaging components.

Overview

The two main functions of BizTalk Server 2010—BizTalk Orchestration and BizTalk Messaging—form the underlying architecture that enables you to integrate and exchange messages with the many types of external systems and applications that exist in your organization and in those of your trading partners.

The BizTalk Messaging engine is responsible for performing the following tasks:

  • Receiving inbound documents through receive ports, which may include the use of a map for message translation or transformation.
  • Parsing inbound documents to determine their specific format in a pipeline. Receive pipelines can also perform data validation to ensure that the message being received is valid compared with a known schema.
  • Extracting key identifiers and identifying applicable routing rules. Filters can be placed on send ports to route documents based on the contents of a message.
  • Delivering documents to their respective destinations. Some of the options available to route documents include file drops, databases, or other business processes.
  • Tracking documents. The BizTalk Group Hub allows developers, IT professionals, and business analysts to monitor message activity and troubleshoot errors as they arise.

What Is Property Promotion?

Describe how promoted properties work to enable content-based routing.

What is Property Promotion?

In BizTalk Server, promoted properties enable various BizTalk components to access key items of data contained in a message. Promoting a property makes the data within that node of the schema accessible to messaging processes. In addition to the properties that you may choose to promote, various adapters promote contextual properties for routing purposes. The information about the promoted properties is contained in a specially formatted XML schema known as a property schema. Properties from a single message can be promoted to different schemas depending upon your needs.

For example, if you need to route all invoices with a total dollar amount over $500, you would promote the amount node in the source schema. The amount node would then be available for use in a filter expression to create subscriptions.

Performing a quick promotion on a schema node promotes the node to the default property schema defined for the XML schema in question. If a property is quick promoted and no default schema yet exists, Microsoft Visual Studio® will offer to automatically create the schema for you. Quick promotion is done by right-clicking the node and then clicking Quick Promote.

By using the option to view promotions in Visual Studio, you can manage the promoted properties (including removing the promotion if no longer needed). This view also includes the ability to distinguish specific nodes. Distinguished fields are used in orchestrations and will be discussed later in Module 10, “Creating Transactional Business Processes.” Visual Studio provides a property schema template for creating your own property schemas.

Promoted Properties

Property promotion enables BizTalk messaging services to route messages based on the context and content of the message. You want to promote properties only when required for message routing, message correlation (a special form of message routing, which will be covered in Module 9, “Automating Business Processes”), or property-tracking. Excessive property promotion can adversely affect BizTalk Server performance.

Demonstration: Promoting a Property

Learn how to promote a schema property by using the Quick Promotion option in the BizTalk Schema Editor.

Promote Properties

  1. In Windows Explorer, navigate to C:\AllFiles\DemoCode\Module5\Demo, and then double-click Demo.sln.

The following demonstration is not dependent upon completion of the previous demonstrations. This solution provides artifacts and file paths that differ from those used in the previous demonstrations.

  1. In Solution Explorer, double-click PurchaseOrder.xsd to open the schema.
  2. Right-click the <Schema> node, and then click Expand Schema Node.
  3. Right-clickState, point to Promote, and then click Quick Promotion.
  4. In the Microsoft Visual Studio dialog box, click OK.

This is a notice that Visual Studio will create a property schema that will contain this promoted property. In Solution Explorer, notice that the schema named PropertySchema has been added to the project.

  1. PropertySchema.xsd will open in the Schema editor window, and a newMicrosoft Visual Studio dialog box will appear, asking you if you want to reload PropertySchema.xsd. Click Yes.

Notice that the node you promoted is part of this schema.

  1. Right-click Property1, and then click Delete, and then click Yes.

The Property1 node serves no purpose and can be safely deleted.

  1. On the File menu, click Save All.
  2. In PurchaseOrder.xsd,right-click OrderTotal, point to Promote, and then click Quick Promotion.
  3. Another Microsoft Visual Studio dialog box will appear, asking you if you want to reload PropertySchema.xsd. Click Yes.
  4. In Solution Explorer, right-click the Messagingproject, and then click Deploy.

The next demonstration requires that this project be deployed.

  1. Pausethe bt10d-demos virtual machine.

Lesson 2: Configuring Message Routing

Lesson objective:

Configure BizTalk Server message routing.

Overview

BizTalk Server enables you to route messages directly to a send port or to an orchestration based on the contents of the message. This feature is very powerful because it can increase flexibility of business processes by eliminating the need to deterministically configure the flow of messages.

Steps for Enabling Messaging Routing

Identify the steps for enabling the routing of messages in BizTalk.

Enabling Message Routing

To enable message routing, you must perform the following steps.

  1. Promote the nodes in the source schema that will be used for content-based routing of the message.
  1. Create and configure both a receive port and a receive location for incoming messages. Receive ports and receive locations are used to receive messages from internal applications and from external trading partners.
  2. Create and configure any send ports or send port groups that will be used for the routing of the message.
  3. Configure the filter expressions on the send ports or send port groups to create the message subscriptions used to route messages to subscribers.
  4. Enlist and/or start the send ports. Enlisting a send port creates the subscription in the MessageBox database but will not begin processing messages until it is started.
  5. Enable receive locations, which will begin processing messages from the endpoint.

Send ports should (at the least) be enlisted before receive locations are enabled. If messages are received into the MessageBox and there are no subscriptions, the messages will be suspended.