U3's Couch

Welcome to machine again.

In this section we will discuss some of EAI patterns, and how these could be implemented in BizTalk.

• Aggregator:
  

  Aggregator is the pattern of receiving information from multiple sources and consolidating it into a single message
  

• Splitter:
  

  How can we process a message if it contains multiple elements, each of which may have to be processed in a different way?
  

  Use a Splitter to break out the composite message into a series of individual messages, each containing data related to one item
  

  In BizTalk, there is a concept known as Envelope splitting. This is a useful feature in BizTalk for splitting messages.
  

  The Splitter pattern takes a single message and splits it into multiple messages
  

• Parallel Convoy:
  

  A parallel convoy enables multiple single messages to join together to achieve a required result. The set of related messages can arrive in any order, but BizTalk Server must receive all of them before starting the process.
  

• Sequential Convoy:
  

  The Sequential Convoy pattern enables multiple single items to ‎join together to achieve something that an individual item cannot ‎accomplish by itself. A sequential convoy is a set of related items ‎that have a predefined order. Although the items do not have to ‎be exactly the same, BizTalk Server must receive the items in a ‎sequential order.‎
  

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.

Scenario 2: 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.

Convoy ‎ means multiple single items must be related together in order to achieve something that the individual item cannot accomplish by itself

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

• Sequential convoy - 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.
  
• 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 convoy - Items that are in any order, but must all be present before something occurs, 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. 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.
  

• Message Broker:
  

  Message Broker is the pattern of determining the destination of a message and still maintaining control over the message flow the goal of our generic message broker will be to dispatch any type of message to its destination decided at runtime. So, by avoiding type dependency and early routing binding (basically, hard-coding) we would get single very flexible orchestration which can easily handle requirement changes - one of the top goals of good application design.
  

  
  

  
  

  So, the question is how to implement these patterns in BizTalk?
  

  The answer is very simple, check this link J
  http://www.codeplex.com/PatternWizard
  

  And enjoy BizTalking