Feature

In Part 1 of this article (XML-J, Vol. 4, issue 6) we looked at creating a solution that used a new product in the Microsoft Office System 2003 called InfoPath. In this installment, I'll show you how to extend the solution created in Part 1 using BizTalk Server 2004.

In Part 1, we created a form that collected new patient information for a health care customer. Once we completed the initial InfoPath solution, the CIO was very impressed with the fact that InfoPath leveraged existing back-end Web services and allowed the company to continue developing using the service-oriented architecture (SOA) that they had invested very heavily in. The CIO's next challenge for my project team was to build an InfoPath solution that extended the patient form and included workflow components. What he wanted was an easy integration into their back-end mainframe system. I can remember his exact words, "Integrate and they will come!" Now we'll do exactly that. I will show you how we extended the solution using BizTalk Server 2004 and how the enhancements in this version make it possible.

What Is BizTalk Server 2004?
BizTalk Server 2004 is the third release of this server product. When we started this project BizTalk Server 2004 was publicly available in Beta 1 (www.microsoft.com/biztalk/beta). This new version is designed to solve three basic common integration scenarios - Enterprise Application Integration (EAI), Business Process Automation (BPA), and Information Worker Integration. The redesigned architecture is built on two main services that enable these: orchestrations that provide the execution framework for business processes, and BizTalk Messaging that enables transformation and routing between business processes.

Orchestrations allow the design, execution, and management of a business process. Workflows are created and saved into executable XML files called an XLANG orchestration. XLANG is a proprietary execution environment of BizTalk Server, but the new version enables the exporting of orchestrations to the Business Process Execution Language for Web Services 1.1 (BPEL4WS) specification. BPEL4WS defines a language for the formal specification of business process and business interaction models. XLANG has been a core component of BizTalk since the first product release but has been substantially enhanced within the new version. XLANG is now an extension of the managed runtime environment of the .NET Framework and this inclusion provides enhanced support for communication, transactions, long-running processes, and state management. These new managed orchestrations appear as a palette in Visual Studio .NET 2003 that allows developers to visually create, edit, and modify workflow processes directly within the development environment. For example, the managed environment enhancements and the new BizTalk Architecture allowed us to develop our initial NewPatientOrchestration without any custom coding. An additional extension to XLANG is a tracking engine. The Business Activity Monitor (BAM) allows business decision makers to monitor business processes and track potential process bottlenecks. Using the dashboard interface of Windows Sharepoint Services the business user is able to monitor, interact with, and even change existing BizTalk processes. The main feature of BAM is the provision of a platform for continual process improvement that is easily configured and managed.

Within BizTalk Server 2004 both messaging and orchestration have been combined into a single subsystem. This combination enables a shared common data store for process, state management, and messaging. During the execution of a process the messaging components handle the transport and mapping while the orchestration executes the defined processes.

The BizTalk Implementation
The CIO tasked the project team with two goals for the NewPatientOrchestration. The first was to publish a Web service that accepted the incoming completed and validated InfoPath forms. The second was to implement a basic transformation that could easily match an existing mainframe upload XML Schema (see 'Defining the Architecture').

The direct integration of BizTalk into the Visual Studio .NET 2003 IDE adds a new set of project types. For the NewPatientOrchestration and Web service we started with an empty BizTalk project. This project type created a blank project with references to the managed assemblies needed to create an orchestration. The inclusion of BizTalk into the managed environment means that all default references exist as a managed assembly. These default references include:

• Microsoft.BizTalk.DefaultPipelines
• Microsoft.BizTalk.GlobalPropertySchemas
• System
• System.Xml

One of these references is to a new feature called pipelines. These define a .NET or COM component that defines and links to the various processing stages of either sending or receiving a message. Each portion of these components specifies a messaging stage. For example, these stages include encoding/decoding, assembly/disassembly, and encryption/decryption. The pipeline designer allows the developer to modify, change, or augment the specific order of these stages.

The Microsoft.BizTalk.DefaultPipelines namespace defines the default pipelines: XMLReceive, PassThruReceive, XMLTransmit, and PassThruTransmit. This default reference processes documents using the PassThruReceive and PassThruTransmit function (see sidebar 'Pipelines').

Defining Messages
Pipelines are used to process messages that are defined as an XML Schema (XSD). These schema definitions define and maintain the specific message formats and structures used during the orchestration. We created two XSDs that matched the specific schema items and formats that were needed for our orchestration. These were generated using the new XSD schema item within the Visual Studio 2003 IDE (see Figure 1). The first schema (see Figure 2) represented the InfoPath-submitted inbound XML document. The second schema represented the transformation and matched the existing XML message format used for the mainframe system (see Figure 3).

Once we completed both the inbound and transformed schemas it was important to check the specific XSD formats. In many ways, reviewing and comparing a specific message instance is a lot easier than reviewing the schema tree and data types. Creating an XSD can be a very complex process that includes describing all the possible formats and variations within a specific document type. Within the Solutions Explorer, right-clicking the schema and selecting "generate instance" creates a reference document for schema definitions. It is important to remember that this is not a foolproof check, but it really helped to quickly review and validate the XML document.

Orchestration Design
Messages are the basic unit of communication within an orchestration. Messages consist of one or more parts with context data that describes their properties and content. BizTalk orchestration uses messages to provide the context for interchange between business process participants. Typically, orchestration is broader in scope than a traditional workflow. Each participant is autonomous, and the responsibility of routing a work item is determined by each cooperating participant. BizTalk Orchestration extends the definition of the traditional interaction diagram to include definition and control for decisions, concurrent actions, transactions, and supporting actions. The result of a completed orchestration is an XLANG executable file that represents the description of the business processes.

Within the Visual Studio 2003 IDE, new orchestrations are added in the same way as all other BizTalk items - through the Solutions Explorer and the New Item menu. This adds a file with an ODX extension that contains the XLANG structures. Within the IDE the orchestration page provides a visual interface that presents the underlying XLANG structure. This interface is broken into three sections that define an orchestration. First is the actual design surface or palette. This area is the visual surface where toolbox items are dropped and configured to define the process flow. Using this surface I dropped the send and receive ports that define the inbound and outbound message handler. The second area of the orchestration designer is the Orchestration Types window, which defines the specific port types, correlation types, and role links available within the orchestration. Using this window I was able to define the specific inbound and outbound operations defined for the orchestration. Finally, there is the Orchestration Variable window, which shows the orchestration properties, parameters, ports, messages, variables, correlation sets, and role links available for this orchestration. Using this window I was able to correlate the specific message to either the inbound or outbound port (see Figure 4).

Mapping schema definitions
Within the orchestration designer, the transform shape enables the flow of data from one message to another. This can be done through a direct assignment or a mapping process. The NewPatientOrchestration required a specific map because of required transformation and data translation to the outbound message type. The transform shape provides access to the BizTalk Mapper, which allows the assignment of specific source and destination attributes and provides both transformation and translation of specific schema elements and attributes.

Maps are initialized and defined by placing the transform shape onto the design palette (see Figure 5) and then defining the schema for the source and destination documents. This configuration is then loaded into the BizTalk Mapper, where the actual element and attribute flow from one message to another is defined. Within a map, functoids are used to manipulate the data flow. Functoids are an important part of any map. They provide the ability to map elements and attribute data into different elements and attributes across different structures. Within BizTalk Server 2004 they have become part of the Visual Studio toolbox palette and appear as part of the map. When working on a map you can drag them directly onto the design palette. For example, within the NewPatient Orchestration we dragged the string concatenation onto the map and dragged the source and destination elements between the two (see Figure 6). Within a map, input links correspond to input parameters and lead to the functoid from the left; an output link corresponds to the output parameters and leaves the functoid from the right.

Deploying the Solution
Once the map and orchestration are completed, the solution is ready for deployment. All projects within BizTalk Server 2004 are deployed into a managed assembly as a DLL. This is done by building the solution and then deploying it using the E-Business Web Services Wizard. This wizard provides the option of deploying either an orchestration or an enterprise schema as a Web service. When deploying an orchestration, the wizard starts with the compiled DLL and generates the necessary namespace, Web service name, communication patterns, and request/response objects to build and deploy an ASP.NET Web service project. The wizard identifies the defined ports, location, and schema within the compiled assembly to generate the necessary WSDL file that provides the Web service definition.

Any orchestration that uses only a single Web port is published as a single ASMX file that defaults to the orchestration name. The orchestration that we created used more than one Web port, and the default naming context is the name of the orchestration with an underscore followed by the Web port name. For example, once the NewPatientOrchestration was deployed, the Web port names NewPatientOrchestration_Outbound.asmx and NewPatientOrchestration_Inbound.asmx were assigned. It is important to keep these in mind within InfoPath as these are the service names that that InfoPath will bind to. Once bound to the specific Web service InfoPath has the ability to directly submit and receive data from these defined BizTalk Services.

Summary
In this article we developed a fully functional BizTalk process that was deployed as a Web service. We have covered many of the features of BizTalk Orchestration and deployment within the managed environment of the .NET Framework. The real benefit of this architecture was the creation of a Web service that offered workflow and integration capabilities that were easily accessible within the InfoPath environment. Throughout these two articles we have only covered the basics of InfoPath and BizTalk Server. There are still many more features that my health care customer found compelling. I challenge you to take the time to explore these and see the power of InfoPath to help reduce the mountains of paper that we have and BizTalk Server 2004 as a way of providing workflow and structure around existing business process.

Side bar

Pipelines
A pipeline is a new feature of BizTalk Server 2004 and defines a .NET or COM component that implements a set of predefined interfaces that interact with the BizTalk engine. The default order of the pipeline process for each of the components defines the default set of interfaces and processing order.

Default component order in the XMLReceive pipeline:

Decrypter

Decoder

Disassembler

Validator

Party Resolution

Default component order in the XMLTransmit pipeline:

Assembler

Encoder

Encrypter

Published Aug. 6, 2003— Reads 17,050
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Figure 1

▪ Figure 2

▪ Figure 3

▪ Figure 4

▪ Figure 5

▪ Figure 6

About Thom Robbins
Thom Robbins is a senior technology specialist with Microsoft. He is a frequent contributor to various magazines, including .NET Developer's Journal and SOA Web Services Journal. Thom is also a frequent speaker at a variety of events that include VS Live and others. When he's not writing code and helping customers, he spends his time with his wife at their home in New Hampshire.