Orchestration

A business process is a set of actions that, taken together, meet a specific business need. Business process automation enables the coordination of common business processes, for example approving a purchase order, with people and business applications—such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), or other LOB applications. These processes frequently start as manual tasks that require integration and input from various systems and individuals. The process may take hours, days, weeks, or months to complete.

BizTalk orchestration is a flexible and powerful capability that provides various services and tools to enable you to design, automate, and manage business processes. Similar to traditional procedural programming languages, an orchestration represents the underlying logic for processing messages.

BizTalk orchestration provides a transactional programming model that includes support for exception handling and recovery from failed transactions. You can define two types of transactions when creating an orchestration:

Atomic transaction. Enables a transaction to automatically role back to a previous state in case the transaction does not successfully complete.
Long running transaction. Can span days, weeks, and longer time durations, contain nested transactions, and use custom exception handling to recover from error scenarios.

As a result, orchestrations provide you the flexibility to define the course of action in the event of a business process failure.

Orchestration Designer

Orchestration Designer provides a design surface that enables you to create visual representations of your business processes. The design surface is a working canvas where you drag different shapes from the Toolbox as shown in Figure 8. The shapes correspond to the different actions that you need to perform when processing a message. In most cases, you must configure options for each shape that you use when you build the orchestration.

The design surface is divided into three areas: one Process Area and two Port Surfaces. The Process Area contains shapes that describe the actual process flow of the orchestration. For example, scope shapes helps you define transactions in a business process. A scope contains one or more blocks. It has a body and can optionally have any number of exception-handling blocks as well as a compensation block appended to it.

The Process Area of the design surface is flanked on both sides by Port Surfaces, which contain only Port and Role Link shapes that interact with the send and receive shapes in the Process Area. You can use either side (right or left) of a Port Surface to create a send or receive port. This enables you to create well-documented orchestrations that have fewer crisscrossing connectors, making your orchestrations easier to read.

Figure 8. Orchestration Designer

Steps to Develop an Orchestration

The steps for developing an orchestration are as follows:

Define the schemas to describe the format of the messages to be processed by the orchestration.
Add and configure the shapes to represent the various actions that are required to define the business process.
Define new message instances to be processed within the orchestration.
Define the orchestration ports to receive and send messages
Define and assign orchestration variables to declare and manage the data used in the orchestration.
Bind the send and receive shapes to ports, and specify the physical ports that they will use.
Build, deploy, and test the orchestration.

The BizTalk Orchestration Engine

The BizTalk orchestration run-time engine is a highly optimized service that monitors and executes orchestrations. At run time, the BizTalk Orchestration Engine executes the files that you create using Orchestration Designer.

The BizTalk Orchestration Engine performs the following tasks:

Creating instances of and executing orchestrations
Maintaining the state of a running orchestration instance so that it can be restored to memory when required
Performing optimizations of running orchestrations to maximize scalability, throughput, and efficient use of resources
Providing a reliable shutdown-and-recovery system

The orchestration engine executes orchestrations by creating individual instances of the business process. The run-time engine coordinates these multiple instances to ensure that a response message gets routed to the correct orchestration instance, by using a specialized routing pattern called correlation.

Dehydration and Rehydration

When many business processes run at the same time, memory and performance can be compromised. The BizTalk Orchestration Engine solves this problem by dehydrating and rehydrating orchestration instances. Dehydration is the process of saving the state of an active orchestration instance to the MessageBox database and then removing that instance from memory. This can happen when the orchestration engine determines that an instance has been idle for a period of time. Dehydrating the instance frees up the resources that were being used by the instance.

Dehydration

The orchestration engine calculates thresholds to determine how long an orchestration will wait for various actions to take place, and if those thresholds are exceeded, it dehydrates the instance. This can occur under the following circumstances:

When the orchestration is waiting to receive a message and the wait is longer than a threshold determined by the engine.
When the orchestration is waiting for a subscribed message.
When a delay in the orchestration is longer than a threshold determined by the engine.
Between the retries of an atomic transaction.

The orchestration engine saves the entire state of a running orchestration instance to persistent storage at various points so that the instance can later be completely restored in memory. The dehydration of orchestration instances enables the orchestration engine to have more "in-flight" instances than the physical resources of the computer running BizTalk Server would normally allow. Dehydration is automatically controlled by the orchestration engine; however, you can control the dehydration threshold by changing specific BizTalk Server configuration properties.

Rehydration

Rehydration is the reverse of dehydration. It is the process of de-serializing the last running state of an orchestration from the database or restoring the saved state of an orchestration instance from disk back to memory. The orchestration engine is triggered to rehydrate an orchestration instance when it either receives a message or when a time-out expires. It then loads the saved orchestration instance into memory, restores its state, and runs it from the point where it left off.

An orchestration can be configured to run on more than one server. After an orchestration instance has been dehydrated, it can be rehydrated on any of these servers. If one server goes down, the engine continues to run the orchestration on a different server, continuing from its previous state. The engine also takes advantage of this feature to implement load balancing across servers.

Calling External Assemblies

Through the course of a business process, there are times when the execution requires the functionality of another .NET application or a functionality that is better developed in a different common runtime language, such as C#. BizTalk orchestrations can pass parameters to external applications through method calls, and subsequently integrate the functionality of external applications into the BizTalk process.

Service Integration Scenarios

WCF and Web services are used to expose the functionality of a system or application to other applications and are, by far, the most implemented mechanism for service enablement. BizTalk Server 2009 fully supports existing WCF and Web service standards. This support enables developers to both consume external services as part of a business process and publish a business process as service that can be consumed by external applications.

If you require a specific business process to be accessible via the Internet to customers, trading partners, or other applications, you can publish an orchestration as a WCF service. You do this by running the BizTalk WCF Services Publishing Wizard. The wizard creates a WCF-based ASP.NET application that runs within Internet Information Services (IIS).

Some examples of publishing an orchestration as a service include:

Airlines publish fare information online as a service. A travel Web site can call multiple airlines' services to determine the current price for tickets from multiple airlines.
A shipping company exposes its business processes as online services. Online retailers can call the shipper’s services to calculate shipping costs and display tracking information about the shipment to their customers.

Some common integration scenarios for integrating services into a business processes include:

Determining shipping costs from external shippers for a product
Calculating tax for an item depending on the country from which the item is being purchased
Obtaining a credit report or credit score from a third-party company when processing a loan
Accepting or denying a credit card for an online purchase

BizTalk Server 2009 enables you to call services from within an orchestration and through messaging send ports. In addition, you can generate industry-standard Web services and custom WCF services by publishing existing orchestrations or schemas, simplifying typically complex integration scenarios.

BizTalk Service Integration Capabilities

In addition to the WCF adapters, BizTalk Server 2009 also provides the following support for integrating with WCF services:

Consuming WCF services. . You can use the BizTalk WCF Service Consuming Wizard to generate BizTalk artifacts, such as BizTalk orchestrations and types, which consume a WCF service based on the metadata document of the WCF service.
Publishing orchestrations as WCF services. Using the WCF Publishing Wizard you can publish BizTalk orchestrations as WCF services. Publishing an orchestration as a WCF service exposes the functionality of the business process to external services such as trading partners or customers. Using metadata from orchestration port types and schema types, the wizard automatically creates a WCF-based ASP.NET application which acts as a WCF service façade for the BizTalk orchestration.
Publishing a schema as a WCF service. Publishing an orchestration as a WCF service binds the message received through the service to the published orchestration. However, publishing a schema as a WCF service provides a simple mechanism to submit messages to the MessageBox database. Once in the MessageBox, the message can be routed to any number of subscribers for processing.
Publishing receive location metadata as WSDL.

BizTalk Server 2009 continues to support integration with ASMX Web services in the following ways:

Consuming WCF services. . Similar to consuming a WCF service, BizTalk orchestrations can call external ASMX services.
Publishing orchestrations as WCF services. Similar to publishing an orchestration as a WCF service, you can expose your business processes as ASMX services.
Publishing a schema as a WCF service. Similar to publishing a schema as a WCF service, schemas can be published as ASMX services, to expose the message to external services.

BizTalk Orchestration in SOA Designs

A key principle of SOA is workflow or business process automation, which happens to be a major strength of BizTalk Server 2009. Service aggregation is one of the most common SOA patterns that people use BizTalk Server to implement. Take a travel Web site for example; a travel Web site does not have a single database containing all the ticketing information for all the airlines in the world. Instead each participating airline exposes its fare information by using a Web service. The travel site executes the user's query against each airline's service and returns an aggregated set of results.

For more information on BizTalk Orchestration please refer to the BizTalk Interactive Capabilities Reader or the BizTalk Product Documentation on MSDN.

Try BizTalk Server 2009

Get the 120 day trial