BizTalk Server 2004 Convoy Deep Dive

BizTalk Server 2004 Convoy Deep Div...

Collapse All

Stephen W. Thomas

April 2005

Applies to: BizTalk Server 2004

Summary: This paper discusses examples of business scenarios that require convoy message processing, explains convoy theory and messaging, and reviews each included sample. (13 printed pages).

Download sample code

Overview

Microsoft BizTalk Server 2004 supports the use of convoy message processing, a new messaging pattern. Convoys are a messaging pattern and not a feature of BizTalk Server 2004. A convoy is not something a customer can use, like the Rules Engine, but instead it is something that the business process dictates and requires.

This paper discusses examples of business scenarios that require convoy message processing. After establishing a business need through the scenarios, this paper explains basic convoy theory and the different types of convoy messaging patterns. This paper discusses a solution to each business scenario and reviews each included sample.

Business Scenarios

Before discussing convoys, you should understand the need for convoys at all. Convoys occur because of a business requirement to process messages in a way that the traditional publish and subscribe messaging system inside BizTalk Server 2004 cannot handle. BizTalk Server 2004 must handle these messages differently to guarantee meeting the business requirements. The publish and subscribe messaging system can handle traditional handshake (request and response) style messages without special considerations.

In order to understand better what business requirements require convoy messaging, consider the three business scenarios outlined in the following section.

Scenario 1: Hospital Admits a New Patient

Business Overview. A hospital admits a new patient. The hospital requires several pieces of information from the new patient including insurance information, past medical history, and contact information. Several different people collect this information including an insurance specialist, a nurse, and a receptionist. Several different systems process this information. The order in which collection and submission of this information occurs is not guaranteed. This is because some information collectors may be busy with other patients, the medical records department may be behind in their schedule, or the insurance system may be not functioning correctly. Assembling this information for the patient in an organized manner must occur throughout the time the patient spends at the hospital. This guarantees that the patient receives accurate care and correct billing.

Technical Overview. This process involves receiving several different pieces of information about a new patient in any order. All the pieces of information are required before the business process continues and admits the patient. This reduces the number of non-payments by guaranteeing the admission of only those patients with all the requirements. This also creates a race condition in which any one of the various messages can be the first to arrive and start the business process for the new patient. Because this is a new patient, no patient number is available for correlation or reference. Accomplishing correlation in this case occurs by using date of birth, social security number, or a combination of other demographics. Any one of the three messages may be required to start a new orchestration; this creates a race condition inside the message box.

Design Considerations.

How can you allow any message to arrive first and start the business process?
How can you correlate subsequent messages to the first message?
How can you handle messages that arrive while the workflow system is down for an upgrade?
How can correlation be handled without the traditional handshake of a send and receive message processing?

Scenario 2: Retail Company Batch Orders

Business Overview. An online retail company receives new orders from direct clients and sub dealers throughout the course of the day. All orders received before 2:00 PM must go to the warehouse in a single batch and the sequence of the receipt of the orders has to be preserved. This enables the earlier orders to have priority in case any items are out of stock in the warehouse. You build this batch order by assembling all orders for that day in a single file that has batch header information. At 2:00 PM, all orders for that day go to the warehouse for processing. All orders received after 2:00 PM require starting a new batch. Processing occurs the following day.

Technical Overview. This process requires processing all incoming orders in the order of receipt through a single process. A singleton business process is required to receive all messages in the order of receipt to guarantee the overall processing order. In this case, any arriving order could be the first order in a new batch. This creates a race condition because any new arriving message might need to start a new business process. This race condition requires only the first order in a new batch to start the business process and necessitates routing all other orders to the same business process until the batch closes at 2:00 PM. This poses an interesting question: What happens if after reaching the Delay shape, messages still arrive into the soon-to-be-ending business process?

Design Considerations.

How can you guarantee the same business process processes all orders?
How can you handle messages that may arrive to the soon-to-be-ending business process?
When should you create a new business process?
How will correlation be handled without the traditional handshake of a send and receive message processing?

Scenario 3: Standardized Test Taking and Grading

Business Overview. A student is getting ready to take a standardized test. As part of the testing process, the student registers for the test. After registered the student checks in at the testing center on the correct date and takes the test. Upon check out, checking the student's identity occurs again and the student leaves the testing center. Finally, the student's test arrives at the grading center. Only after the completions of all these steps in order, can the student's test be graded and a score recorded.

Technical Overview. Completion of this business process requires receipt of several different types of messages. In this case, there is a predefined order to follow in which to process these messages. After receipt of the four single messages, sending a single notice occurs to allow the student's test to be graded.

Design Considerations.

How can the same business process receive many different types of messages in the predefined order?
How can you correlate subsequent messages to the first message?
How can correlation be handled without the traditional handshake of a send and receive message processing?

Convoy Basics

Convoys exist in the world any time multiple single items must be related together in order to achieve something that the individual item cannot accomplish by itself. This concept generalizes into a basic design pattern. This is convoy processing.

Convoy processing can be additionally broken out into two separate categories as shown in the following list:

Sequential convoy - Items that are in a order, one after another
Parallel convoy - Items that are in any order, but must all be present before something occurs

The main difference in the two types of convoys is the order of receipt of the items.

Sequential Convoys

Sequential convoys are a set of related items that have a predefined order. The items do not have to be exactly the same. Grouping together requires that all they have to have is a purpose to group. Shown below is this basic pattern.

Figure 1 Sequential convoy

A real world example of a sequential convoy is a group of friends headed to a party traveling in separate vehicles. The overall goal is for all of them to reach to the party but in this case, only the first person has the directions. It is up to the lead vehicle to make sure they drive to the correct location and that all the other vehicles following are not lost. In order to make sure they all stay together, the leader instructs each following vehicle to put a blue flag on the vehicle's antenna. There are many other vehicles on the road going home, to work, or to another party but only the vehicles going to this party in this group have the blue flag.

Parallel Convoys

Parallel convoys are a set of related items that can be in any order. BizTalk Server 2004 must receive all the items before achieving the final goal. Shown here is this basic pattern.

Figure 2 Parallel convoy

Another way of thinking of parallel convoys is like a door with many locks. The locks can be unlocked in any order. Only when the last key is turned will the door open. The key ring may have many different keys on it, but only one set matches this combination of locks.

Convoy Messaging in BizTalk Server 2004

In the three business scenarios outlined earlier a central question exists: How can you handle the correlation without the traditional handshake of send and receive message processing? The answer to this question is convoy message processing.

BizTalk Server 2004 uses a publish and subscribe system to route messages to a specific destination. These destinations can be a send port, a receive port on a new orchestration instance, or a receive port on an already running orchestration instance. Creation of subscriptions occurs in the following two ways:

By creating them at design time as a send port or receive port in an orchestration
At runtime by sending a message out of an orchestration that expects a response back into the running business process.

In both of these cases, BizTalk Server 2004 knows all the properties used for subscription matching beforehand when it creates the subscription.

Convoy messages do not fit into this traditional pattern because BizTalk Server 2004 does not know the exact properties used for the subscriptions during creation of the initial subscriptions. This is because only the receipt of the first message in the convoy contains the information needed for grouping together additional messages. Only after the receipt of the first message in the convoy are the values of the correlation properties for all subsequent messages known.

Convoys may require the receipt of multiple messages before any business process has the chance to start. This is because you implement convoys by using multiple receives inside a business process. This creates the potential of a race condition on the message box because of the need for successful routing of all these messages to this to-be-created or already-created orchestration instance. Handling this race condition occurs at the database level during subscription matching. Because any message received by BizTalk Server 2004 may potentially be the first message in a convoy or belong to an existing convoy, checking all messages for the existence of convoy properties occurs at subscription matching time.

BizTalk Server 2004 detects and reacts to convoy message processing at the time of the enlistment of an orchestration implementing this kind of pattern. At enlistment, the runtime creates a general subscription and identifies it as part of a convoy. After filling this subscription, creation of a temporary subscription occurs based on the values in the pre-defined correlation properties. Convoy set is the term used for this temporary subscription. Evaluation of all subsequent messages that match the general subscription occurs against the convoy sets for a match and eventually routing to an existing port.

The handling of the race condition before creating a business process allows for full support for many types of business scenarios that require convoy message processing.

In traditional correlation scenarios, no race condition exists. This is because a traditional handshake occurs between the sending out of a message from a business process and the receipt of the response back into the same business process. This kind of scenario contains a handshake between the exchange of the messages between the various systems. Handling by traditional subscription occurs because the system has time to create the response subscription when it sends out the initial message. This kind of message processing would not require convoy message processing. In convoy scenarios, this kind of processing is not possible because no handshake exists.

Following some simple requirements when you work with convoy messaging patterns in BizTalk Server 2004 enables the runtime to treat the receiving messages as a convoy. Consideration for using convoy processing with a business process involves following these rules:

The correlation set used on the Receive shapes may not contain more than three properties used for correlation. A correlation set is a list of properties with specific values that you use to route messages a specific business process. This is because these values identify and store at the database level. This has support for a maximum of three parameters.
Parallel and sequential convoy may coexist in the same business process, but they may not share any correlation sets with each other. This is because each correlation set may only belong to one convoy.
BizTalk Server 2004 does not support convoy processing when passing in an already initialized correlation set into a new orchestration using the start orchestration. This is because convoy sets handle at the database level, independent of already running orchestration instances.

Convoy messaging patterns in BizTalk Server 2004 can fit into two different messaging design patterns:

Parallel (concurrent) receives
Sequential receives with uniform or non-uniform inputs

Defined in the following section are these messaging design patterns.

Parallel (Concurrent) Receive

Parallel (concurrent) receive message processing occurs any time the business process requires that two or more messages must be received before the rest of the business process may continue. Additionally, these messages can arrive in any order into the business process. This messaging pattern is supported in BizTalk Server 2004 by using a parallel receive convoy.

In order to handle this kind of messaging pattern inside an orchestration, you must use the Parallel Action shape. Add a Receive shape to each parallel branch in the shape, one for each message that you must receive. If this shape is the first shape in the orchestration, all Receive shapes must be able to start the orchestration. You do this by setting the activate property to "True" on each of the Receive shapes inside the Parallel Action shape. The incoming messages may be received from different ports and be of different types.

Use a correlation set to relate all the incoming messages together. Each of the Receive shapes inside the Parallel shape must initialize this correlation set.

Figure 3 shows an example of a parallel (concurrent) receive convoy as the first action inside the orchestration. In this case, only the first message received for a specific convoy set starts a new business process. All other messages route to the already running instance of the business process.

Figure 3 Concurrent receive convoy

Typically, you handle parallel convoys as the first shape inside an orchestration. This is not required. If the business need occurs, BizTalk Server 2004 also supports non-activatable parallel convoys. In this case, the parallel convoy is in the middle of the business process waiting for multiple return messages.

Sequential Receives

Sequential receive convoys can be additionally broken down into two sub-categories:

Uniform sequential receive convoys
Non-uniform sequential receive convoys

Uniform Sequential Receives

Uniform sequential receive message processing exists when many instances of a message is received and all must be handled by the same business process. You handle this kind of messaging pattern in BizTalk Server 2004 by using a uniform sequential receive convoy.

In order to build a business process to handle this kind of messaging pattern, you put two successive Receive shapes into the orchestration. These must both receive the same message type from the same port. If the first Receive shape is the first shape in an orchestration, it should be able to start a new orchestration. You do this by setting the Activate property to "True" on the first Receive shape. This first Receive shape must also initialize a correlation set used for the subsequent Receive shape. The second Receive shape must follow this correlation set. A common implementation of this design pattern is in a batching scenario. This positions the second Receive shape inside a Loop shape to enable receipt of many additional messages by the business process. In some cases, you need additional logic to guarantee the first message processes just like subsequent messages.

Figure 4 shows two messages in a sequential receive convoy. These two messages are of the same type and arrive from the same port inside the orchestration. The first Receive shape in Figure 4 is set to activate the orchestration and initialize the collection set. The second Receive shape follows this correlation set.

Figure 4 Uniform sequential receive convoy

Non-Uniform Sequential Receives

In the non-uniform sequential receive design pattern, the receipt of two or more different types of messages occurs in a known order before the rest of the business process can continue. Definition of the order of the received messages occurs inside the business process, although BizTalk Server 2004 does not enforce the order other than for the first message.

To implement this message pattern in a business process, position multiple Receive shapes in order inside the orchestration. If the first Receive shape is the first shape in the orchestration, it must be able to start a new orchestration. Do this by setting the Activate property to "True" on the first Receive shape. The first Receive shape in the convoy initializes a correlation set followed by all subsequent Receive shapes. The individual messages must all originate from the same port and this port must be marked for ordered delivery. The individual message types are each associated with a separate operation inside the port. Figure 5 illustrates this kind of design pattern.

Figure 5 Non- uniform sequential receive convoy

Basic Convoy Theory

BizTalk Server 2004 has support for convoy message processing built into the core messaging engine. You manage the overall process to handle convoy message processing in three steps:

Compile Time. At compile time, you identify and handle a convoy message pattern accordingly.
Subscription Creation Time. At deployment, you create the base convoy subscription and identify convoy properties. This sets the framework for you to create convoy sets based on the properties associated with incoming messages.
Figure 6 shows a base subscription followed by virtual subscriptions created as new business processes that contain convoys start. The term "virtual subscriptions" represents the behind the scenes database level correlation and routing that is occurring.
Figure 6 Convoy subscriptions
Subscription Matching Time. As messages arrive, the system checks for the presence of properties that are part of a convoy. This occurs for every message that enters BizTalk Server 2004. If the message contains propertied used in a convoy, additional checks are performed. Shown here is a simplified version of the message subscription matching processing.
Figure 7 Simplified message subscription matching flow

Best Practices

This paper illustrates how BizTalk Server 2004 deals with convoy message processing. Realize that convoys are not always the best solution to the problem at hand. You should use convoys when the business needs require convoy message processing.

All convoys implement singleton processing with regard to the convoy set they represent. Sometimes, this can be a significant bottleneck in the system. Think back to real world example of the group of vehicles headed to the party. If one vehicle has a flat tire then all the vehicles must stop.

Convoys also have a side effect called zombies. A zombie is a message or orchestration that resides in the "Completed with discarded messages" status. This occurs any time a message routes to a business process that is in the process of ending, or any time unexpected messages arrive into a business process. The sample walk through in the following section covers zombies and covers how to handle them. The best approach available now is the WMI event that commences when a zombie occurs. This shows in the ZombieWMI component.

Solved Business Scenario Samples

The three business scenarios discussed earlier are all excellent examples of business processes that require convoy message processing in order to solve the required tasks.

There is a detailed discussion of each sample to help gain a deeper understanding of convoys.

Sample setup: Run the included MSI. All samples install into C:\ConvoyDeepDive directory. If you have not already downloaded the MSI, you can obtain it here.

Scenario 1: Hospital Admits a New Patient

The Hospital Admits a New Patient Scenario is an example of a business scenario that requires parallel convoy message processing. The business requirements dictate the receipt of three different types of message before admitting the patient into the hospital. These three messages are the Insurance, History, and Patient messages. Any one of these messages can be the first message to arrive for the patient and this creates a race condition. To solve this, three Receive shapes are put into a Parallel Action shape and each receive is marked as Activate = True. This enables any one of the three messages to start the orchestration. Shown here is this message receipt pattern.

Figure 8 Admit a new patient

Use a correlation type called corrPatientInfo to identify the properties used to tie the individual messages together. A correlation type is a list of properties that eventually populates with values for use in routing messages. HospitalData.xsd, a custom property schema defines these properties and references each of the three individual message schemas. The nodes that contain the correlation values do not have to have the same name across the various messages. They just need promotion to the same node using the property schema. The properties used for correlation are the patient's date of birth, Property Schema Node Name: DOB, and social security number, Property Schema Node Name: SSN, as these uniquely identify a new patient. What follows is the definition of the correlation type, and patient properties used in this business process.

Figure 9 Definition of the correlation type

Figure 10 Patient properties

Use a correlation set called corrPatientMessage on the Receive shapes to create a new instance of the correlation type based on the properties received by the first message in the set. Remember, this occurs independently of an actual running orchestration instance. Each of the three Receive shapes must initialize the same correlation set.

In order to run this sample, make sure to enlist and start the Scenario 1 Orchestration. At this point, three separate activate subscriptions can be seen in the Subscription Viewer. The Subscription Viewer is located in the Software Development Kit (SDK) at SDK\Utilities\BTSSubscriptionViewer.exe.

Shown here are these three base subscriptions. Additional subscriptions may be present in the table other then what is in the following list.

Figure 11 Base subscriptions

A deeper look into one of the subscriptions shows the properties used for the base subscription. An earlier diagram shows the properties for the InsuranceInfo message. It shows that DOB and SSN must exist but they do not have any specific values.

The sample files used for running this scenario are located at C:\ConvoyDeepDive\Scenario1\SampleFiles. This contains one of each message type for two separate patients, A and B. To start the orchestration, drop any message into the Scenario1\In folder. In this case, the A_MedicalHistory.xml, B_MedicalHistory.xml, and B_PatientInfo.xml are dropped into the In folder.

This action starts two separate orchestrations. You can see these by opening Health and Activity Tracking (HAT), selecting Operations and selecting Service Instances.

You can see the more interesting part of the process by looking in HAT under Operations but this time selecting Messages. This shows two MedicalHistory messages and one PatientInfo message that are consumed and probably dehydrated. This means that the message routed to an orchestration and it is waiting for the next action to happen. On the far right, the Service Instance ID tells with what orchestration instance the messages are associated. Shown here is the compressed message view of HAT.

Figure 12 Compressed message HAT view

The first mesoccurredeived was the A_MedicalHistory.xml message. This contained both a DOB and SSN as described by the MedicalHistory schema so the base subscription filled. After that, a check occurred for the existence of a convoy set with these properties, with none found. Therefore, a new one created. This new virtual subscription had the following properties of DOB=2-23-1950 and SSN=123456789 and created a new orchestration.

The second message, B_MedicalHistory.xml, did exactly the same thing and created another new virtual subscription with properties of DOB=2-23-1950 and SSN-987654321 and another new orchestration.

The third message, B_PatientInfo.xml, handled somewhat differently. It also matches the base subscription with the existence of DOB and SSN. This time however, the test for the existence of a convoy set returns as true. In this case, this message routes to the same orchestration as the previous message with the same convoy set. This is evident by viewing HAT and seeing the two messages routed to the same service instance.

To finish the existing orchestrations, drop the remaining messages into the In folder. This includes the A_InsuranceInfo.xml, B_InsuranceInfo.xml, and A_PatientInfo.xml messages. The orchestrations complete and output messages appear in the Out folder.

The SampleFiles folder also contains a message called C_PatientInfo_NoSSN.xml. This message fails routing on the base subscription because the SSN does not exist. Test this by dropping this message into the In folder. View the results in HAT and in the event log.

Remember, message correlation occurs independently of any running business processes. To test this, open BizTalk Explorer and stop the Scenario 1 orchestration. Make sure the orchestration remains enlisted. Drop all three messages for Patient A into the In folder. HAT shows the three messages in the Suspended (resumable) status and all three already routed to the same Service Instance. View the service instances in HAT. This shows a Scenario 1 orchestration that is pending and ready to run as soon as you start it.

Now, start the orchestration using the BizTalk Explorer and make sure you select the Resume Existing Orchestration Instance check box. This executes the waiting orchestration and output appears in the Out folder. A quick view in HAT shows the messages no longer show up as suspended and the service instance has completed.

If there is receipt of a message two times before the business process ends, it becomes a zombie. Remember that zombies are messages in the "Completed with discarded messages" service status after the orchestration is completed. You can see this by running the process again but this time submitting one of the messages two times before ending the orchestration. You must investigate zombies in order to guarantee no data is lost. Figure 13 shows how this kind of message would look under Messages in HAT.

Figure 13 Message types

The ZombieWMI console application can help solve zombie related problems. This application detects zombie orchestrations and writes the zombie messages to the C:\ConvoyDeepDive\ZombieMessages\. Both the messages and the message contexts write to this folder with the message ID as the message name. Shown here is the output from the console application.

Figure 14 ZombieWMI.exe

Scenario 2: Retail Company Batch Orders

The Retail Company Batch Order Scenario is an example of a business process that requires sequential convoy processing of incoming messages. The business requirements state that all single orders received before 2:00 PM for a specific day should batch together. This requires the first message received to start a new orchestration instance and initialize a correlation set. At that point, all other orders received of that message type route to the already running orchestration instance. To accomplish this, you position a Listen shape (containing a Receive shape and a Delay shape) inside a Loop shape. After reaching the delay, the loop ends. This allows for the receipt of an unknown amount of orders in the same business process. This kind of process could potentially result in routing messages to this orchestration while it is in the process of ending. Therefore, zombie monitoring for this kind of process is very important.

The repeating receive messaging pattern is shown here. Note that this does not show the receipt of the initial message.

Figure 15 Repeating receive messaging pattern

The above illustration uses XML document manipulation to append additional orders to a base XML document. This approach requires an Atomic Scope shape since XmlNode is not serializable.This enables a straightforward approach to batching in this scenario. It also eliminates message retention and build up inside the MessageBox database. In this case, message receipt happens inside the loop and puts the message into a "Delivered, not consumed status". The message remains in this status until the orchestration tells the MessageBox database otherwise at a persistence point. Using the Atomic Scope shape creates a persistence point and releases the messages as they are consumed. Other types of long running processes inside a loop without a persistence point may cause a large amount of messages to remain inside the MessageBox database in the "Delivered, not consumed state" until the orchestration completes or dehydrates.

Use a correlation type named corrMessageType to identify the properties used for correlation. In this case, use a single BizTalk Server 2004 internal property for correlation. That property is BTS.MessageType. This allows for the same orchestration instance to route and process all orders. This creates a singleton behavior with regard to the MessageType of a message and could potentially create a performance bottleneck. Remember, convoys are business process driven and should only be used when required. A correlation set named corrOrderMessage initializes by the first Receive shape named FirstOrder followed by the AllOtherOrders Receive shape inside the loop.

A look into the Subscription Viewer shows two subscriptions for this message. They are the same, except one is marked as not being able to activate a convoy. This does not show in the Subscription Viewer. As part of the subscription matching process, the presence of an existing orchestration is checked and creation of new orchestration instances occur as needed based on the convoy values in the correlation set. Therefore, both subscriptions always evaluate but only one ever fills.

In order to run this sample, make sure to enlist and start the Scenario 2 Orchestration. The files used for this scenario are located in C:\ConvoyDeepDive\Scenario2\SampleFiles. This contains five different orders. Select any one of the orders and drop it into the In folder. In this case, you select and position Order_No101.xml in the In folder. A single orchestration starts with a correlation set based on this message type. This creates a virtual subscription based on the received message type of the message. In this case, it is a single order. Note that for this sample the 2:00 PM time to close a batch changes to a simple one-minute timer. The batch ends when there is no receipt of new messages for one minute. See the Helper Class about how to change this time-out.

Drop the remaining four orders into the In folder. The same orchestration instance accepts each order and adds it to the batch. A look into HAT shows a single message associated with this orchestration. After reaching the time-out, the result is a single batch file in the Out directory.

If messages arrive to the orchestration after the loop has ended, these messages will cause the orchestration to be "Completed, with discarded messages". To simulate this, add a Delay shape after the loop and send messages into the process. You can see this in the RetailCompanyBatchOrdersZombie.odx provided in the Scenario2 directory. This orchestration does not deploy with the initial set up. This orchestration writes a message to the event log as soon as the loop is finished so make sure your BizTalk Server 2004 host has event log write permissions. The delay holds for one minute causing any submitted messages to route to this running instance and become a zombie.

Scenario 3: Standardize Test Taking and Grading

The Standardized Test Taking and Grading Scenario is an example of a business scenario that requires sequential convoy message processing. This differs from Scenario 2 because, in this case, there is the receipt of four different message types. This differs from Scenario 1 because, in this case, the messages must arrive in a defined order.

In this scenario, the receipt of the Registration, Check In, Check Out, and Test Received messages are in order. Shown here is this kind of pattern.

Figure 16 Messages received in order

Use a Correlation Type named corrStudentType to identify the properties for this convoy. In this case, use a single custom property named StudentID for correlation. This definition is in the StudentTrackingID.xsd schema. The Registration Receive shape initializes a correlation set named corrStudentID and is followed by the other three Receive shapes.

Examining the subscription viewer shows four subscriptions, one for each of the different message types. These are all marked as Activate but the ability to start a new orchestration instance receives a check as part of the subscription matching process.

Figure 17 Subscription viewer

To run this sample, make sure to enlist and start the Sample 3 Orchestration. Locate the sample files at C:\ConvoyDeepDive\Scenario3\SampleFiles. Drop the Registration_0004.xml into the In folder. This creates a new instance of the business process for test taking and grading. This also creates a virtual subscription for the student ID that was in the received message. In this case, the virtual subscription is 0004. Any additional messages that match one of the four subscriptions with an ID of 0004, routes to this already running instance.

To complete this process, drop the SiteCheckIn_0004.xml, SiteCheckOut_0004.xml, and TestReceived_0004.xml into the In folder. Although the business process has the files in a defined order, this is not enforced. If these files drop out of order, the message routes to the correct orchestration instance and it waits until all the remaining messages arrive.

As the orchestration receives messages, they then appear in HAT all with the same service ID. The Messages view of HAT looks similar to this.

Figure 18 Wait for remaining messages

After the receipt of the last message, a message appears in the Out folder.

You can create zombies in this process if there is receipt of same message two times for a specific student ID. This causes the orchestration instance and the additional messages to be suspended. Using the ZombieWMI console application a zombie would look similar to the following figure.

Figure 19 Zombie view

About the Author

Stephen W. Thomas is an independent consultant specializing in Microsoft BizTalk Server Integration Solutions. He has been working with BizTalk Server since early 2001. His blog is located at http://go.microsoft.com/fwlink/?LinkId=46260.

Technical Contributors

Lee Graber, Erik Leaseburg, Yumay Chang