Effectively exchanging messages with applications is an absolute requirement for integration. Given the diversity of communication styles that exist, the BizTalk Server 2004 engine must support a variety of protocols and message formats. As described next, a significant portion of the BizTalk Server 2004 engine is devoted to making this communication work. One important fact to keep in mind, however, is that the engine works only with XML documents internally. Whatever format a message arrives in, it is always converted to an XML document after it is received. Similarly, if the recipient of a document cannot accept that document as XML, the engine converts it into the format expected by the target application.

Because the BizTalk Server 2004 engine must talk to a wide range of other software, it relies on a range of adapters to make this possible. An adapter is an implementation of a communication mechanism, such as a particular protocol. BizTalk Server 2004 provides built-in adapters, and adapters have been created for popular applications such as SAP. A developer can determine which adapters to use in a given situation, or can create custom adapters for specific needs. All adapters are built on a standard base called the Adapter Framework. New with BizTalk Server 2004, this framework provides a common way to create and run adapters. It also enables you to use the same tools to manage both standard and custom adapters. While adapters written for earlier versions of BizTalk Server will not work with BizTalk Server 2004, the Adapter Framework makes it easier to create new adapters for this new release.

BizTalk Server 2004 provides the following adapters:

• SOAP adapter. Enables sending and receiving messages by using SOAP over HTTP. Because SOAP is the core protocol for Web services, this adapter gives BizTalk Server 2004 the ability to interact in a Web services world. As usual with Web services, URLs are used to identify the sending and receiving systems.
  
• BizTalk Message Queuing adapter. Enables sending and receiving messages by using BizTalk Message Queuing (MSMQT). BizTalk Message Queuing is an implementation of the Microsoft Message Queuing (MSMQ) protocol that can receive and send MSMQ messages from and to the MessageBox database. It is not a replacement for MSMQ, but rather an efficient way to use the MSMQ transport with BizTalk Server.
  
• File adapter. Enables reading from and writing to files in the Windows file system. Because the applications involved in a business process can often access the same file system, either locally or across a network, exchanging messages through files can be a convenient option.
  
• HTTP adapter. Enables sending and receiving information by using HTTP. The BizTalk Server 2004 engine exposes one or more URLs to allow other applications to send data to it, and it can use this adapter to send data to other URLs.
  
• SMTP adapter. Enables sending messages by using Simple Mail Transfer Protocol (SMTP). Standard e-mail addresses are used to identify the parties.
  
• SQL adapter. Enables reading and writing information from and to a SQL Server database.
  
• Base EDI adapter. Enables sending and receiving messages by using the American National Standards Institute (ANSI) X-12 and Electronic Data Interchange for Administration, Commerce, and Trade (EDIFACT) standards.
  
• FTP adapter. Enables exchange of files between BizTalk and FTP servers.
  

The messages that an adapter receives usually need to be processed before an orchestration can access them. Similarly, outgoing messages produced by an orchestration often need to be processed before an adapter sends them. How this processing is done is described next.

The applications underlying a business process communicate by exchanging various kinds of documents, such as purchase orders and invoices. For a BizTalk Server 2004 application to execute a business process, it must be able to correctly process the messages that contain these documents. This processing can involve multiple steps, and it is performed by a message pipeline. Incoming messages are processed through a receive pipeline, while outgoing messages go through a send pipeline.

For example, even though more and more applications understand XML documents, many—probably even the majority today—do not. Because the BizTalk Server 2004 engine works only with XML documents internally, it must provide a way to convert other formats to and from XML. Other services may also be required, such as authenticating the sender of a message. To handle these and other tasks in a modular way, a pipeline is constructed from some number of stages, each of which contains one or more .NET or COM components. Each component handles a particular part of the message processing. The BizTalk Server 2004 engine provides several standard components that address the most common cases. If these are not sufficient, developers can also create custom components for both receive and send pipelines.

BizTalk Server 2004 defines some default pipelines, including a simple receive/send pair that you can use for handling messages that are already expressed in XML. A developer can also create custom pipelines by using the Pipeline Designer tool. This tool, which runs inside Visual Studio .NET, provides a graphical interface that enables dragging and dropping components to create receive and send pipelines with the required behavior.

The following figure illustrates the stages in a receive pipeline, along with the standard components provided for each one.

Figure 4 Receive pipeline

The stages and their associated components are:

• Decode. BizTalk Server 2004 provides one standard component for this stage, the MIME/SMIME decoder. This component can handle messages and any attachments they contain in either MIME or Secure MIME (S/MIME) format. The component converts both kinds of messages into XML, and it can also decrypt S/MIME messages and verify their digital signatures.
  
• Disassemble. BizTalk Server 2004 provides three standard disassembler components. These are:
  
  • Flat file disassembler. Turns flat files into XML documents. Those files can be positional, where each record has the same length and structure, or delimited, with a designated character used to separate records in the file.
    
  • XML disassembler. Parses incoming messages that are already described by using XML.
    
  • BizTalk Framework disassembler. Accepts messages sent by using the reliable messaging mechanism defined by the BizTalk Framework. The BizTalk Framework was implemented in BizTalk Server 2000 and will eventually become less relevant when Web services reliable messaging specifications are widely adopted.
    
• Validate. BizTalk Server 2004 provides an XML validator component for this stage. As its name suggests, this component validates an XML document produced by the Disassemble stage against a specified schema or group of schemas, returning an error if the document does not conform to one of those schemas.
  
• Resolve Party. The only standard component for this stage, party resolution, attempts to determine an identity for the sender of the message. If the message was digitally signed, the signature is used to look up a Windows identity in the BizTalk Server 2004 Configuration database. If the message carries the authenticated security identifier (SID) of a Windows user, this identity is used. If neither mechanism succeeds, the sender of the message is assigned a default anonymous identity.
  

Outgoing messages can also go through multiple stages, as defined by a send pipeline. The following figure shows the stages and standard components for a send pipeline.

Figure 5 Send pipeline

The stages and their associated components are:

• Pre-assemble. No standard components are provided. Instead, custom components can be inserted here as needed.
  
• Assemble. Paralleling the Disassemble stage in a receive pipeline, this stage also has three standard components:
  
  • Flat file assembler. Converts an XML message into a positional or delimited flat file.
    
  • XML assembler. Enables adding an envelope and making other changes to an outgoing XML message.
    
  • BizTalk Framework assembler. Packages messages for reliable transmission by using the BizTalk Framework messaging technology.
    
• Encode. BizTalk Server 2004 defines one standard component for this stage, the MIME/SMIME encoder. This component packages outgoing messages in either MIME or S/MIME format. If S/MIME is used, the message can also be digitally signed and/or encrypted.
  

After a message has passed through an adapter and a receive pipeline, the business process must determine where it should go. A message is most often targeted to an orchestration, but it is also possible for a message to go directly to a send pipeline, using the BizTalk Server 2004 engine purely as a messaging system. In either case, messages are matched with their destinations through subscriptions.

When a receive pipeline processes a message, it creates a message context that contains various properties of the message. An orchestration or a send pipeline can subscribe to messages based on the values of these properties. For example, an orchestration might create a subscription that matches all messages of the type "Invoice", or all messages of the type "Invoice" received from Woodgrove Bank, or all messages of the type "Invoice" received from Woodgrove Bank that are for more than $10,000. However, it is specified, a subscription returns to its subscriber only those messages that match the criteria that the subscription defines. A received message might initiate a business process by instantiating some orchestration or it might activate another step in an already running business process. Similarly, when an orchestration sends a message, that message is matched to a send pipeline based on a subscription that the pipeline has established.

You can implement a business process directly in a language such as C# or Microsoft Visual Basic® .NET. However, creating, maintaining, and managing complex business processes in conventional programming languages can be challenging. Just as important, a process created in this way is likely to act as a set of disparate applications rather than as a coherent business process. Like its predecessors, then, BizTalk Server 2004 does not take this approach. Instead, it enables you to create a business process graphically. Doing this can be faster than building the process directly in a programming language, and it can make the process easier to understand, explain, and change. Business processes built in this fashion can also be monitored more easily, a fact that is exploited by the Business Activity Monitoring (BAM) technology described later in this document.

Successfully creating an automated business process usually requires collaboration between technology-oriented developers and less-technical business people. Accordingly, BizTalk Server 2004 provides appropriate tools for each. The developer tools run inside Visual Studio .NET, an environment in which software professionals feel at home. Most business people do not find Visual Studio especially inviting, however, so BizTalk Server 2004 also provides a subset of the developer tool functionality in the Orchestration Designer for Business Analysts (ODBA), an add-in for Microsoft Visio. Information created in the ODBA tool can be imported into the Visual Studio-based tools and vice-versa, which helps developers and business analysts work together when creating a business process. After it exists, this process, known as an orchestration, is automatically transformed into standard assemblies that run on the .NET Framework.

A developer relies on three primary tools for creating an orchestration: BizTalk Editor for creating XML schemas, BizTalk Mapper for defining translations between those schemas, and Orchestration Designer for specifying the flow of business processes. Unlike earlier versions of the product, all of the developer tools in BizTalk Server 2004 are hosted inside Visual Studio .NET, providing a consistent environment. This section describes what each of these tools does and how they work together.

Orchestration works with XML documents, each of which conforms to some XML schema. Accordingly, there must be a way to define these schemas. To do this, the BizTalk Server 2004 engine provides BizTalk Editor. This tool enables you to use the XML Schema definition language (XSD) to create schemas, which are essentially definitions of the types and structure of the information in a document. While BizTalk Editor is not new with this release, this complete reliance on standard XSD is. Because the final Worldwide Web Consortium (W3C) standard for XSD was not complete when they were developed, previous versions of BizTalk Server used XML Data Reduced (XDR), a Microsoft-specific language for defining schemas. Now that XSD has been finalized, BizTalk Server 2004 relies on this standard approach for describing the structure of XML documents.

Creating raw XSD schemas without some tool support is not simple. To make this necessary step more approachable, BizTalk Editor enables its user—probably a developer—to build a schema by defining its elements in a graphical hierarchy. Existing schemas can also be imported from either files or accessible Web services. However they are acquired, schemas are used as the basis for BizTalk maps, which are described next.

An orchestration implementing a business process typically receives some documents and sends others. It is common for part of the information in the received documents to be transferred to the sent documents, perhaps transformed in some way. For example, an order fulfillment process might receive an order for some number of items, and then send back an acknowledgment indicating that the order was sent. It is possible that information from the order, such as the name and address of the purchaser, might be copied from fields in the received order into fields in the order acknowledgment. You can use BizTalk Mapper to define a transformation—a map—from one document to the other.

To the developer creating it, each map is expressed as a graphical correlation between two XML schemas that defines a relationship between elements in those schemas. The W3C has defined the Extensible Stylesheet Language Transformation (XSLT) as a standard way to express these kinds of transformations between XML schemas; therefore, as in previous versions of BizTalk Server, maps in BizTalk Server 2004 are implemented as XSLT transformations.

The transformation defined in a map can be simple, such as copying a name and address from one document to another. Direct data copies like this are expressed by using a link, which is shown in BizTalk Mapper as a line connecting the appropriate elements in the source schema with their counterparts in the destination schema. More complex transformations are also possible by using functoids. A functoid is a chunk of executable code that can define arbitrarily complex mappings between XML schemas, and BizTalk Mapper represents it as a box on the line connecting the elements being transformed. Because some of those transformations are fairly common, BizTalk Server 2004 includes a number of built-in functoids. These built-in functoids are grouped into categories that include the following:

• Mathematical functoids. Perform operations such as adding, multiplying, and dividing the values of fields in the source document and storing the result in a field in the target document.
  
• Conversion functoids. Convert a numeric value to its ASCII equivalent and vice-versa.
  
• Logical functoids. Used to determine whether an element or attribute should be created in the target document based on a logical comparison between specified values in the source document. Those values can be compared for equality, greater than/less than, and in other ways.
  
• Cumulative functoids. Compute averages, sums, or other values from various fields in the source document, and then store the result in a single field in the target document.
  
• Database functoids. Access information stored in a database.
  

You can create custom functoids directly in XSLT or by using .NET languages like C# and Visual Basic .NET. (Earlier versions of BizTalk Server used Visual Basic Scripting Edition (VBScript) or Microsoft JScript® to create custom functoids, and you may need to modify maps that use these to work with BizTalk Server 2004.) Functoids can also be combined in sequences, cascading the output of one into the input of another.

Having a way to define the XML schema of a document is essential, as is a mechanism for mapping information across documents with different schemas. BizTalk Editor and BizTalk Mapper address these two functions. Yet defining schemas and maps is not enough. You must also specify the business process that will use the schemas and invoke the maps. How this is done is described next.

A business process is a set of actions that together meet some useful business need. With the BizTalk Server 2004 engine, you can use Orchestration Designer to define these actions graphically. This tool enables you to create an orchestration by connecting a series of shapes in a logical way, rather than expressing the steps in a programming language. Some of the most commonly used shapes are:

Receive. Enables the orchestration to receive messages. A Receive shape can have a filter that defines exactly what kinds of messages should be received, and it can be configured to start a new instance of an orchestration when a new message arrives.

Send. Enables the orchestration to send messages.

Port. Defines how messages are transmitted. Each instance of a Port shape is connected to either a Send or Receive shape. Each port also has a type, which defines things such as what kinds of messages this port can receive; a direction, such as send or receive; and a binding, which determines how a message is sent or received by, for example, specifying a particular URL and other information.

Decide. Represents an if-then-else statement that allows an orchestration to perform different tasks based on Boolean conditions. You can use the Expression Editor, part of Orchestration Designer, to specify this conditional statement.

Loop. Enables performing an action repeatedly while some condition is true.

Construct Message. Enables building a message.

Transform. Enables transferring information from one document to another, transforming it on the way by invoking maps defined with BizTalk Mapper.

Parallel Actions. Enables specifying that multiple operations should be performed in parallel rather than in sequence. The shape that follows this one will not be executed until all of the parallel actions have completed.

Scope. Enables grouping operations into transactions and defining exception handlers for error handling. Both traditional atomic transactions and long-running transactions are supported. Unlike atomic transactions, long-running transactions rely on compensating logic rather than rollback to handle unexpected events.

Message Assignment. Enables assigning values to orchestration variables. These variables can be used to store state information used by the orchestration, such as a message being created or a character string.

After you have defined a business process in this way, the group of shapes and relations between them is converted into the Microsoft intermediate language (MSIL) that is used by the .NET Framework common language runtime (CLR). Ultimately, the group of shapes that you define in BizTalk Server 2004 becomes just a standard .NET assembly. And of course, you can still add explicit code to an orchestration when necessary by calling a COM or .NET object from inside a shape.

The rise of Web services is having an impact on how business processes are defined. For example, think about the case where two organizations interact by using Web services. To interoperate effectively, it might be necessary for each side of the interaction to know something about the business process the other is using. If both organizations use BizTalk Server 2004, this is not a big problem; tools such as the Trading Partner Management technology described later in this document can be used to distribute this knowledge. But what if the organizations use different software? What if one organization uses BizTalk Server 2004 and the other uses software from another vendor? For cases like this, it is useful to have a way to describe the business process interactions in a cross-vendor way.

To support this type of interaction, Microsoft, IBM, and others have created Business Process Execution Language (BPEL). A business process defined by using Orchestration Designer can be exported to BPEL, and BizTalk Server 2004 can also import processes defined in BPEL. While the language is useful for describing and sharing the external-facing parts of a business process between trading partners, it is important to realize that BPEL is not focused on cross-platform execution of business processes. It is also important to understand that BPEL is built entirely on Web services, while BizTalk Server 2004 and other products that support this language provide a broader set of services. For example, BizTalk Server 2004 provides support for mapping between different XML schemas, calling methods in local objects, executing transactions, and other features that are not available in BPEL.

Web services enable applications to exchange XML documents through SOAP, and they have had a big impact on integration platforms. Unlike previous versions of the product, BizTalk Server 2004 has built-in support for Web services. To access an external Web service, the creator of an orchestration can use the Add Web Reference option in Visual Studio .NET along with the SOAP adapter to directly invoke operations, just as with any other .NET assembly. Similarly, BizTalk Server 2004 provides the Web Services Publishing Wizard that can generate an ASP.NET Web service project exposing one or more of operations of an orchestration as SOAP-callable Web services. These two options enable you to both access existing Web services from within a business process and expose the functionality of an orchestration as a Web service to other business processes.

Like the other developer tools provided by BizTalk Server 2004, Orchestration Designer runs inside Visual Studio .NET. In some cases, however, a business analyst rather than a developer may wish to graphically define business processes. Because business analysts may not be comfortable using Visual Studio .NET, BizTalk Server 2004 also includes the Orchestration Designer for the Business Analyst (ODBA) tool, an add-in for Microsoft Visio that enables you to define a business process and then import that process into Orchestration Designer.

Orchestrations are the fundamental mechanism for creating business processes in BizTalk Server 2004. Some aspects of an orchestration tend to change more often than others, however. In particular, the decisions embedded in a business process—the business rules—are commonly its most volatile aspect. The spending limit for a manager was $100,000 last week, but a promotion bumps this up to $500,000, or the maximum allowed order for a slow-paying customer decreases from 100 units to only 10. Why not provide an explicit way to specify and update these rules? This is exactly what the Business Rule Engine does, as described next.

Orchestration Designer, together with BizTalk Editor and BizTalk Mapper, is an effective way to define a business process and the rules it uses. It is sometimes useful, though, to have an easier way to define and change business rules. To allow this, BizTalk Server 2004 provides the Business Rule Engine to enable more business-oriented users to directly create and modify sets of business rules. These rules are created by using a tool called the Business Rule Composer, and then executed directly by the engine. This technology is new in BizTalk Server 2004, and it is one of the most interesting features in the product.

To see why this approach is useful, think about what is required to change a business rule that is implemented within an orchestration. A developer must first open the orchestration in Visual Studio .NET, modify the appropriate shapes (and perhaps the .NET or COM objects they invoke), and then build and deploy the modified assembly. If instead this business rule is implemented by using the Business Rule Engine, it can be modified without recompiling or restarting anything. All that is needed is to use the Business Rule Composer to change the desired rule, and then redeploy the new set of rules. The change takes effect immediately. And while orchestrations are typically created and maintained by developers, business rules are readable enough to be modified by business analysts without the need to involve more technical people.

When you create a set of business rules, you typically begin by using the Business Rule Composer to define a vocabulary for use in specifying those rules. Each term in the vocabulary provides a user-friendly name for some information. For example, a vocabulary might define terms such as Number Shipped or Maximum Quantity of Items or Approval Limit. Each of these terms can be set to a constant or be mapped to a particular element or attribute in some XML schema (and thus in an incoming message), or to the result of an SQL query against some database, or even to a value in a .NET object.

After you have defined a vocabulary, you can use the Business Rule Composer to create business policies that use the vocabulary. Each policy can contain one or more business rules. A rule uses the terms defined in some vocabulary together with logical operators such as Greater Than, Less Than, or Is Equal To to define how a business process operates. A business rule can define how values contained in a received XML document should affect the values created in an XML document that is sent, or how those received values should affect what value is written in a database, or other things.

Imagine, for example, a simple vocabulary that defines the term Maximum Allowed Order Quantity, whose value is set to 100, and the term Quantity Requested, whose value is derived from a specified element in received XML documents that correspond to the schema used for placing orders. A business analyst might create a rule stating that if the Quantity Requested in an incoming order is greater than the Maximum Allowed Order Quantity, the order should be rejected, perhaps resulting in an appropriate XML document being sent back to the originator of this order.

To execute a business policy, an orchestration can contain a Call Rules shape that creates an instance of the Business Rule Engine, identifies which policy to execute, and then passes in the information this rule needs, such as a received XML document. The Business Rule Engine can also be invoked programmatically through a .NET-based object model, which allows it to be called from applications that do not use the BizTalk Server 2004 engine. This means that Windows Forms applications, software exposing Web services, and anything else built on the .NET Framework can use the Business Rule Engine whenever it helps to solve the problem at hand.

Both vocabularies and business rules can be much more complicated—and much more powerful—than the simple examples described here. But the core idea of defining a vocabulary and then defining sets of rules that use that vocabulary is the heart of the Business Rule Engine. The goal is to provide a straightforward way for BizTalk Server 2004 users of all kinds to create and work with the rules that define business processes.

Orchestration abstracts the flow of a business process, expressing it graphically rather than in code. Similarly, the Business Rule Engine enables you to express the rules of a business process in a higher-level way. Together, these two technologies provide an effective approach to creating business logic.

If the application using it is not too large, the entire BizTalk Server 2004 engine can be installed on a single computer. In many situations, however, this is not the right solution. The number of messages the engine must handle might be too great for one computer, or redundancy might be required to make the system more reliable. To meet requirements like these, the BizTalk Server 2004 engine can be deployed in a number of ways.

A fundamental concept for deploying the engine is the idea of a host. A host can contain various things, including orchestrations, adapters, and pipelines. Hosts are just logical constructs; to use them, a BizTalk Server 2004 administrator must cause actual host instances to be created. Each host instance is a Windows process, and as the following figure shows, it can contain various elements.

Figure 6 Host computers

In this figure:

• Computer A runs two host instances. One contains a receive adapter and receive pipeline, while the other contains the orchestrations P and Q.
  
• Computer B runs just one host instance, also containing the orchestrations P and Q.
  
• Computer C, like computer A, runs two host instances, but neither of them contains an orchestration. Instead, each of these instances contains a send pipeline and send adapter.
  
• Computer D houses the MessageBox database that is used by all of the host instances in this configuration.
  

This example illustrates several ways in which hosts might be used. For example, because both computers A and B run host instances that contain the orchestrations P and Q, BizTalk Server 2004 can automatically assign requests to these orchestrations based on the availability and current load on each computer. This allows a business process to scale up as needed for high-volume applications. Notice also that computer C contains two different ways to handle outgoing messages. One way might rely on a standard BizTalk Server 2004 adapter, such as the HTTP adapter, while the other might use a custom adapter to communicate with a particular application. Grouping all output processing on a single computer like this can make good sense in some situations. And because each host instance is isolated from every other host instance—they are different processes—it is safer to run code that is not completely trusted, such as a new custom adapter, in a separate instance. It is also worth pointing out that even though this example contains only a single instance of the MessageBox database, you can also replicate or cluster the databases to avoid creating a single point of failure.

The BizTalk Server 2004 engine provides a range of services, and several different tools are used to manage this environment. The primary tool is the BizTalk Administration console, a Microsoft Management Console (MMC) snap-in. This tool enables you to create hosts, assign hosts to computers, start and stop orchestrations, and perform many other administration tasks. You can even dynamically add computers and specify what hosts should be assigned to them while an application is running—there is no need to shut the application down to make these changes. You can also access the functions of the Administration console programmatically through Windows Management Instrumentation (WMI), which enables you to create scripts that automate management functions.

Other management tools are also available for more specific purposes. For example, you can use the BizTalk Deployment Wizard to deploy assemblies to computers, and you can use the Subscription Viewer to examine subscriptions in the BizTalk Server 2004 engine. All of these tools, along with the BizTalk Administration console, rely on a common Configuration database to store the information that they work with.

One more important tool for working with BizTalk Server 2004 applications is BizTalk Explorer. It is new with BizTalk Server 2004, and to understand what it does, think about how a developer builds an application. Initially, a developer creating an application works mainly in logical terms, without defining details. For example, a developer might specify that the BizTalk Server 2004 engine will communicate with a particular application through the HTTP adapter without defining the URL that will be used, or specify that the send pipeline should add a digital signature to outgoing messages without defining the key that will be used to create this signature.

Yet to make the application work, these details must be specified, which is where BizTalk Explorer comes in. Relying on the same Configuration database that is used by the other BizTalk Server 2004 management tools, this tool enables mapping between the logical view of an orchestration and the concrete physical view required to actually use that orchestration. BizTalk Explorer can also be helpful in working with partners, because it enables you to create a single application configuration, and then deploy this configuration differently for each partner. And because it exposes its services through a .NET-based object model as well as a graphical interface, you can create scripts for configuring applications programmatically.

BizTalk Server 2004 applications do many things: send and receive messages, process messages within orchestrations, communicate with various applications using different protocols, and more. It is essential to keep track of what is going on, especially when failures occur. Doing this requires a way to look into running applications and to monitor what is happening with the system, which exactly describes the services provided by the Health and Activity Tracking (HAT) component of BizTalk Server 2004.

The HAT tool provides graphical access to detailed information, including when an orchestration starts and ends, when each shape within it is executed, when each of its messages is sent and received, what is in those messages, and much more. You can even set breakpoints, enabling you to stop the orchestration and examine it at predetermined places. You can also use the HAT tool to examine archived data, looking for patterns and trends in the execution of a business process. This information is useful for debugging, answering business questions (such as verifying that a message really was sent to a customer), and keeping ongoing statistics that can be used to improve performance.

An information worker might want to do many things with a running business process. A sales manager might want to look at sales trends or examine other aspects of a business process in real time. A business analyst might need to create a relationship with a new trading partner, defining the role of the partner, the business agreement between the two firms, and other aspects of this new association. A purchasing manager might need tools that can wrap together and distribute what is needed to let a partner quickly implement and begin participating in a business process. In BizTalk Server 2004, all of these capabilities are provided by Business Activity Services. By making it easier to track what is happening with business processes, these services enable less-technical people, whether they are in big organizations or smaller companies, to monitor their environments effectively.

As shown in the following figure, a common user interface to all of these services is provided through Microsoft Windows SharePoint™ Services, Internet Explorer, Microsoft Excel, and Microsoft Office InfoPath™.

Figure 9 Business Activity Services

Because Business Activity Services are meant to be used by business people, and not by developers, it makes sense to expose them through these familiar tools. Behind this common interface are four different software components, all of which can communicate with Internet Explorer, Windows SharePoint Services, Excel, and InfoPath through SOAP. This section describes each of these components.

Connecting trading partners is a common use of BizTalk Server today. Establishing these connections requires agreeing on several things, including the communication protocol that will be used, the formats of messages that will be exchanged, and the business process that drives the interaction. Managing these trading partner relationships can be complex, especially when many organizations are involved or when the players change frequently.

To enable information workers to perform these common tasks, the BizTalk Server 2004 Business Activity Services include a Trading Partner Management (TPM) component. This component relies on a TPM database, shown in the preceding figure that stores information about trading relationships. Using the common Business Activity Services interface, information workers can create and modify agreements with trading partners who use BizTalk Server 2004. Each agreement describes the relationship between two parties, and contains information including:

• A profile for each of the partners. Each profile contains business information about the organization, such as a contact person and address, along with technical information such as what protocol (and thus which BizTalk Server 2004 adapter) should be used to communicate with that partner.
  
• The business process itself, implemented as one or more orchestrations, along with the role that each of the partners plays. One organization might act as the seller, for example, while the other acts as the buyer.
  
• An addendum with parameters for the business process that control the behavior of the orchestration implementing it. The next section describes how these parameters are used.
  

Profiles, agreements, and addendums are all stored in the TPM database. An information worker can use the TPM component (and for addendums the Business Process Configuration component, described next), to configure all of them directly. This enables business people to establish and modify new partner relationships without relying on developers.

It is too much to expect an information worker to create the orchestration that implements a business process. It is not unreasonable, though, to expect an information worker to be able to set parameters of that orchestration. One example of where this would be useful is when the same orchestration is used with multiple partners, but each partner requires slightly different behavior. Suppose, for example, that the maximum dollar value of a purchase order is different for different trading partners, or perhaps the maximum quantity that can be requested varies depending on the credit rating for the customer. Making these small configuration changes should not require a developer to modify the orchestration. The Business Process Configuration service in BizTalk Server 2004 enables information workers to make the modifications

To enable information workers to configure an orchestration, the developer creating it can define parameters for that orchestration. An information worker can then set these parameters as needed, perhaps assigning different values for different business partners or different parts of the organization. An information worker sets the parameters for a partner through the TPM service, described in the previous section, by specifying their values in the addendum to the partners agreement. If an agreement references multiple orchestrations, multiple addendums can be created, one for each orchestration.

In BizTalk Server 2004, the Business Process Configuration service is tied to TPM, because parameters can be set only through addendums. In future releases, however, the intent is to make this service more generally available, which is why it is called out separately in this version of the product.

When several organizations are participating in a business process built around BizTalk Server 2004, getting them all correctly configured can be time-consuming. For example, a common B2B topology is a hub-and-spoke, where one organization, often a big company, establishes connections with many different suppliers. The business process is typically defined by the hub organization, and then passed on to the spokes to implement their parts. Something similar can also happen inside a single organization, where one group wishes to involve others in a common internal process. In cases like these, it is useful to have a simple way to configure the systems involved, a process that is sometimes called provisioning.

The fourth component in the BizTalk Server 2004 Business Activity Services, Business Process Provisioning, addresses this challenge. Using this component, an information worker can package the information needed by other participants in a business process into a SEED package. The SEED package can then be deployed to other BizTalk Server 2004 systems to quickly provide them with what they need to play their parts.

A SEED package created by a hub system can contain a broad range of things, including .NET assemblies for the orchestrations that implement a business process, BAM views and BAM activities, a profile for the system generating the package, and much more. After a spoke system receives a SEED package, its administrator can deploy it, and then return a SEED package of its own that contains its profile and the other information required to successfully interact with the hub. Yet while administrators are required to deploy SEED packages, the Business Process Provisioning component of Business Activity Services lets information workers create these packages, allowing one more task to be performed by business people rather than by technicians.

Information workers need to look at business processes in different ways. For example, a purchasing manager might need to see how many purchase orders are approved and denied each day, or a sales manager might want an hourly update on what products are being ordered. Meeting these diverse needs requires a general framework for tracking what is going on with a particular business process. This is exactly what the Business Activity Monitoring (BAM) Framework provides.

To use BAM, an information worker accesses the standard Windows SharePoint Services-based interface with Internet Explorer. The information worker can select a particular business process, and then choose a specific BAM view into the process. Each view can give a different perspective on this business process. For example, a BAM view might provide graphical depictions of per-product sales trends, current inventory levels, or other key performance indicators. The information in these views might be updated every day, every hour, or more frequently.

Each BAM view relies on one or more BAM activities. A BAM activity represents a specific business process, such as handling purchase orders or shipping a product, and each one has a defined set of milestones and business data. For example, a purchase order activity might have milestones such as Approved, Denied, and Delivered along with business data like Customer Name and Product.

Both BAM activities and BAM views are created by an information worker, and not by a developer. The BAM Activity Wizard enables defining activities, while the BAM View Wizard enables defining views based on those activities. BAM views are implemented in Excel, so the BAM View Wizard really just helps an information worker to build a standard Excel pivot table using the information in one or more BAM activities. A BAM view can be quite complex, and its creator can also control which users are allowed to see the data it exposes. For example, a purchasing manager might be able to access certain things in a view into the purchase order process that are hidden from purchasing clerks. Information workers can also modify BAM views after they have been created.

While information workers can create BAM views and BAM activities on their own, these views and activities depend on information provided by the orchestrations they monitor. Accordingly, developers still have a role to play. Using a tool called the Tracking Profile Editor, a developer must configure an orchestration so that it provides the information required for a particular BAM activity, and thus for the BAM views that depend on this activity. This tool enables a developer to graphically associate the appropriate events and message fields in an orchestration with corresponding milestones and business data in a BAM activity. The BizTalk Server 2004 engine then sends these events and message field values to the Tracking database, as shown in the earlier figure, where they can be accessed by the Business Activity Monitoring component. As the figure shows, Excel can directly access the BAM component through SOAP to get up-to-the-minute information for BAM views.