SOA with .NET and Windows Azure : Orchestration Patterns with BizTalk Server - Process Centralization

The BizTalk Server product is bundled with a visual orchestration designer tool that can be used to model business process logic as executable orchestrations. The tool includes several shapes (Figure 1) that represent business process steps. From within each shape, .NET assemblies can be invoked. The internal orchestration logic can be exported to (or imported from) WS-BPEL-compliant markup code.

WF can be used to enable workflow logic that incorporates human involvement. Orchestration capabilities in BizTalk Server, however, are focused only on system-to-system communication via automated business processes. The ability to integrate people into the business process is not supported natively by BizTalk Server.

One way to still incorporate human interaction into BizTalk-controlled business process logic is by using InfoPath and SharePoint technologies. InfoPath forms are XML documents that have two additional XML processing instructions:

• an indication that it is an InfoPath form

• the name of the InfoPath template to use for rendering the XML document

SharePoint form libraries can store InfoPath forms. By using the SharePoint adapter, BizTalk can write messages out to a SharePoint site as InfoPath forms that human users can then interact with. The forms can be constructed so that they have a submit process that re-enters an appropriately designed running business process, or perhaps triggers a new business process.

Typically, this submit process will entail writing the document back to a SharePoint library with a given state (for example, a state column at the SharePoint level with a value of “approved”) and then having a BizTalk poll (a SharePoint view) set to filter by that state.

By adopting this approach we can actually decouple the act of human intervention from the processing logic within the BizTalk orchestration. This makes human intervention an asynchronous operation that can occur even if the BizTalk environment is not available or is set to only retrieve intervened messages on a scheduled basis.

WS-BPEL Support

Since the 2004 version, BizTalk Server has supported WS-BPEL 1.1 via the import and export of WS-BPEL process definitions. However, there are some limitations, as explained in the following two sections.

Exporting BizTalk Orchestrations to WS-BPEL

Configuring an orchestration for export is a matter of setting the Exportable property to “True,” setting the orchestration’s Module property to “Exportable,” and by further specifying some XML namespaces (Figure 2).

With these configurations in place, BizTalk will emit compiler errors as shown in Figure 3 to enforce WS-BPEL compliance when the orchestration project is built.

Figure 3. The BizTalk compiler reports non-WS-BPEL-compliant constructs as errors.

While configuring WS-BPEL compliance is relatively straightforward, developing actual WS-BPEL orchestrations can be challenging because some of the core functions and primary tools in BizTalk simply do not support the WS-BPEL language.

For example, you must code message assignments and data transformations by hand with XPath expressions instead of creating data transformation rules with the graphical data mapping tool. A single transformation, such as the map in Figure 4, will require an XPath-based assignment in an Expression shape.

Figure 4. The BizTalk data mapper provides a graphical environment to develop message transformations from the source schema on the left into the target schema on the right.

The assignment from the OrderId element on the left to the PO element on the right would read as follows:

Example 1.

xpath( StampOneNewOrderMessage.ManufacturingOrderRequest,
/*[local-name()='ManufacturingOrderRequest' and namespace-
uri()='http://StampOne.Fulfillment.ServiceContracts/2006/10']/*
[local-name()='Order' and namespace-uri()='http://StampOne.
Fulfillment.ServiceContracts/2006/10']/*[local-name()='PO' and
namespace-uri()='http://StampOne.Fulfillment.DataTypes/2006/10']" ) =
xpath( JobMessage, /*[local-name()='Product' and namespace-
uri()='http://SuperiorStamping.Fulfillment/ServiceTypes/2006/10']/*
[local-name()='OrderId' and namespace-uri()='http://
SuperiorStamping.Fulfillment/ServiceTypes/2006/10']/text() );

Note that the XPath expression in Example 1 only represents one of the mappings in the map from Figure 3. Moreover, it is just a direct assignment without any transformation or combination of values. You can improve the readability of the assignments by promoting message elements to properties, but even that can get out of hand when dealing with schemas that have several data items. It can get more complex when using looping. For example, because the XPath language has no way to express loops or iterations, you need to code them as part of your process flow. This reduces readability and maintainability of the orchestration.

A better, more maintainable approach is to provide a simple transformation service or intermediary processing layer that performs Data Model Transformation . The former approach will build an agnostic utility service that can front-end BizTalk transformations to take advantage of its powerful data mapping capabilities. Or, it can be based on XSLT if the service needs to produce output that’s not always XML-based. Figure 5 and Figure 6 show the difference in the architecture with and without a transformation service.

The approach of placing all non-WS-BPEL-compliant features behind Web service interfaces supports service orientation principles and allows for truly portable processes while still taking advantage of the BizTalk toolset. Still, there are significant tradeoffs to consider when evaluating WS-BPEL compliance:

• execution times are longer if the orchestration has to call external services, such as a transformation service, instead of performing the operations in-process

• BPEL compliance adds complexity to orchestrations, thereby increasing development, test, and maintenance efforts

• externalized, autonomous services may provide a greater level of agility because they can be altered without requiring changes to the orchestration

• each autonomous service increases complexity of the architecture (Each service introduces another point of failure, requires monitoring, maintenance, and possibly dedicated servers.)

• each service call adds load to the network infrastructure

Importing WS-BPEL Processes into BizTalk

Importing is slightly easier because you are not required to make architectural decisions when you import a BPEL compliant orchestration.

To import a WS-BPEL process definition, you need to convert the WS-BPEL code by creating a new BizTalk project of type BizTalk Server BPEL Import Project in the New Project dialog (Figure 7).

Figure 7. BizTalk defines a special project type to import orchestrations in WS-BPEL format.

BizTalk will walk you through a wizard that allows you to identify the process to import the WSDL definition for the process itself and the WSDL and XML Schema definitions for the orchestrated processes.