By Thom Robbins | Article Rating: |
|
August 6, 2003 11:58 AM EDT | Reads: |
20,304 |

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
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:
Default component order in the XMLTransmit pipeline:
Published August 6, 2003 Reads 20,304
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By 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.
Apr. 21, 2018 05:45 AM EDT Reads: 1,739 |
By Elizabeth White ![]() Apr. 21, 2018 05:00 AM EDT Reads: 6,152 |
By Yeshim Deniz ![]() Apr. 21, 2018 03:30 AM EDT Reads: 1,899 |
By Elizabeth White ![]() Apr. 21, 2018 01:30 AM EDT Reads: 6,490 |
By Liz McMillan Apr. 21, 2018 12:00 AM EDT Reads: 2,518 |
By Liz McMillan ![]() Apr. 20, 2018 11:30 PM EDT Reads: 13,157 |
By Yeshim Deniz Apr. 20, 2018 11:15 PM EDT Reads: 2,343 |
By Elizabeth White ![]() Apr. 20, 2018 11:00 PM EDT Reads: 3,536 |
By Liz McMillan ![]() Apr. 20, 2018 10:30 PM EDT Reads: 22,435 |
By Elizabeth White ![]() Apr. 20, 2018 10:15 PM EDT Reads: 6,215 |
By Elizabeth White ![]() Apr. 20, 2018 09:15 PM EDT Reads: 3,588 |
By Elizabeth White ![]() Apr. 20, 2018 08:45 PM EDT Reads: 1,059 |
By Yeshim Deniz Apr. 20, 2018 08:00 PM EDT Reads: 697 |
By Yeshim Deniz ![]() Apr. 20, 2018 07:30 PM EDT Reads: 1,928 |
By Yeshim Deniz Apr. 20, 2018 07:00 PM EDT Reads: 2,821 |
By Liz McMillan ![]() Apr. 20, 2018 05:15 PM EDT Reads: 13,468 |
By Elizabeth White ![]() Apr. 20, 2018 03:15 PM EDT Reads: 12,976 |
By Liz McMillan ![]() Apr. 20, 2018 02:45 PM EDT Reads: 16,976 |
By Pat Romanski ![]() Apr. 20, 2018 02:30 PM EDT Reads: 6,629 |
By Pat Romanski Apr. 20, 2018 02:00 PM EDT Reads: 1,228 |