Many BizTalk architects elect not to implement BAM because they believe that BAM doesn’t fit some specific architectural model. This idea is a misconception; BAM may be implemented in any number of scenarios, including many that don’t even use BizTalk Server’s core engine. This chapter covers BAM in various business and architectural models.

Most people think of BizTalk as an integration server. While BizTalk provides second-to-none integration capabilities, a BizTalk server may also serve as the foundation for a number of different connected systems architectures. This chapter includes a discussion of BAM in multiple business and architectural models, focusing on how BAM may be used to enhance and instrument the model. After reading this chapter, you should know the advantages of BAM in the enterprise and where BAM fits in the business or architectural model you currently support.

When BizTalk Server 2000 was released, it was marketed as a “.NET Enterprise server that unites, in a single product, enterprise application integration (EAI) and business-to- business (B2B) integration.” It included such features as administration, document tracking, orchestration, messaging, and XML tools. While BizTalk’s core functionality has remained more or less consistent since that time, it’s grown to encompass additional technologies that support a wide range of capabilities.

You may be evaluating BizTalk, currently have BizTalk in place to solve a business need, have implemented multiple BizTalk servers, or simply be examining a means to get more from your existing BizTalk implementation. Fortunately, BizTalk Server is not a tool geared toward solving a single problem. BAM can be used with a wide variety of applications and architectures, including business to business (B2B), service- oriented architecture (SOA), enterprise service bus (ESB), business process management (BPM), composite applications, and others.

BAM in a B2B Business Model

BAM is widely used in business-to-business, business-to-consumer (B2C), and consumer-to-consumer (C2C) applications. In these solutions, BizTalk serves as a brokering mechanism between two parties.

One example of a B2B scenario is in the healthcare industry. A healthcare provider may send patient claims submitted when an individual visits a doctor to a folder exposed by an insurance company that is accessed by BizTalk’s File adapter. The file is retrieved, decrypted, validated, transformed, and acted upon; for instance, the message is sent to a third-party billing company to determine the amount, after meeting a deductible, for which the patient is responsible (see Figure 4-1).

Figure 4-1. Sample B2B scenario

In this scenario, BAM provides touchpoints into the overall claims processing process. A BAM activity called Monthly Claims Processed may be defined, with data items including

• Processing Begins
• Processing Error Occurs
• Processing Completes
• Claim Value
• Patient ID
• Provider

The activity could be used to create a view that includes

• Number of Claims
• Total Claim Amount
• Most Claims per Patient
• Fewest Claims per Patient
• Largest Claim Amount
• Smallest Claim Amount

As the claims are processed, BAM may provide real-time notification that claims processing has completed, or that a claim amount over a specific threshold has been filed, and perform some action in real time. Business decisions may be made as claims are processed, providing a true benefit to the business as the claims processor doesn’t have to wait two to three months before analyzing tens of millions of records and acting on the results.

BAM in a B2C Business Model

The B2C model is much like the B2B one, except that a consumer instead of a business is the originator or recipient of a message. An example of a B2C scenario is the retail industry. A personal care product company may create a Silverlight-based web application to use as a product storefront. Internet users add items to their basket and submit an order. The Silverlight-based application calls into a Windows Communication Foundation (WCF) endpoint exposed by BizTalk server, which activates a BizTalk orchestration and passes an XML copy of the order to BizTalk.

BizTalk then disassembles the XML message into messages representing each line item and publishes separate messages to the BizTalk message box. An orchestration subscribes to those published messages and generates messages to send to an order fulfillment system, a logistics and packaging application, and a CRM system to send an e-mail to the consumer (see Figure 4-2).

Figure 4-2. Sample B2C scenario

BAM provides real value in a B2C model because of its real-time nature. A BAM activity called Product Activity could be created, including milestones such as

• Date Order Placed
• Estimated Shipping Date

Data items could also be defined, such as

• Quantity Ordered
• Product
• Price

A real-time view could provide aggregate data such as

• Total Quantity (Measure)
• Total Price (Measure)
• Product (Data Dimension)
• Order Date (Time Dimension)

As orders are processed by BizTalk, BAM may notify the marketing department that a popular product has been identified and is outselling other products, signal suppliers to expedite shipping of raw materials, and perhaps even increase the price of the product. In real time, the business may realize a greater profit margin or modify its supply chain to adjust to changing market conditions, as opposed to a traditional BI solution that requires more time for data to be gathered and analyzed.

BAM in a C2C Business Model

The C2C model is a business model in which consumers are both the originators and consumers of messages, but many times, an intermediary relays or processes the messages to add value, such as in brokering or interchange scenarios.

An example of a C2C scenario is an online auction site that allows consumers to list items they wish to sell through an ASP.NET web application utilizing AJAX. The consumer posts the item, and the web application submits to BizTalk, via a web service, details on the item. Biz-Talk then executes an orchestration to initiate an auction area, to check the seller’s history, and to promote the auction via e-mail to users who may be interested in the item. As other consumers bid on the item through the web application, the application sends those bids to BizTalk, which routes messages to the seller and performs performance monitoring on the application using BAM (see Figure 4-3).

Figure 4-3. Sample C2C scenario

BAM is once again a valuable tool in a C2C model because of its real-time nature. BAM activities may be defined and implemented to identify performance degradation on the web site, signaling BizTalk to send a message to virtualization software to allocate more processing power for the application. A BAM activity could be defined to identify a flood of bids from the same IP, potentially indicating either a script that is automated to bid for the user or even a denial of service attack from a user trying to exclude other users from bidding on the item by flooding the server with ping requests or garbage REST-based posts.

In the B2B, B2C, and C2C scenarios, BizTalk is key to the architecture of the scenario, providing endpoint surfacing, transformation, business process execution, and routing, and BAM provides crucial real-time business intelligence (BI).

BAM and SOA

Chapter 1 introduced the concept of service-oriented architecture. Microsoft’s main offering for developing services is WCF. WCF provides a “best of breed” solution for service development, combining the advantages of previous Microsoft connected systems technologies including .NET Remoting, COM+, MSMQ, ASP.NET Web Services, and the Web Services Enhancements (WSE). WCF services surface functionality via endpoints described using Web Services Description Language (WSDL) based upon a client-server model (see Figure 4-4).

Figure 4-4. BizTalk and BAM in an SOA

BAM’s WCF interceptor is used to directly provide monitoring capabilities to WCF services and entire business processes that traverse WCF service boundaries. BAM’s ability to intercept requests made to WCF services and to monitor Windows Workflow Foundation (WF) work-flows is one of the most powerful service-oriented capabilities of BAM.

BAM activities may be defined for individual WCF services to monitor and instrument their execution throughout the process life cycle. As an example, a telecommunications company that owns fiber optic and telephone networks could implement an SOA using WCF services to expose its product information, billing interfaces, and customer information. The telecom company allows its partners to bundle its products with their own service offerings on the telecom company’s network and submit order request messages through the WCF endpoints.

A BAM activity could be created with a milestone of product availability date and data items such as product monthly service fee, customer geographic location, and product minutes included. As WCF service calls occur, BAM monitors the services. Using continuations, service flow can be monitored across service execution boundaries to create one BAM activity entity. If the telecom company had metric thresholds in place to realize that the one product plan was outselling all other plans for customers in a specific region, the telecom company could then shift its telecom networking resources, including network availability and support staff, to better service those customers on that plan, ensuring fewer busy signals.

BAM and ESB

ESB is an architectural model of application-to-application (A2A) connectivity that provides rich flexibility and loose coupling. An ESB uses a transport layer such as BizTalk’s message box or message-oriented middleware to provide services with a set of event-driven technologies, and supports distributed processing for greater scalability. SOA and ESB are based on the same principles and technologies: XML, SOAP, abstraction of endpoints, and so forth. ESBs, however, provide additional capabilities not inherent to SOA such as service orchestration, process choreography, routing, and richer management (see Figure 4-5).

ESB terminology refers to on-ramps, off-ramps, and itineraries. An on-ramp is a service that allows a message to be submitted to the ESB, an off-ramp allows a message that has travelled across the ESB to be transmitted to an external system, and an itinerary is the data in the message header that specifies how the message should be routed by the ESB.

In fact, Microsoft provides a download that gives guidance on how to build an ESB on the BizTalk Server infrastructure; version 2.0 of the ESB Guidance shipped with BizTalk Server 2009. The APIs, framework, and tools lessen the total time to market to deploy an ESB on the Microsoft stack of technologies.

Let’s consider an example in the field of medical research. A clinical study coordinator interfaces with enterprise servers such as active directory for authentication, a web server to host study documentation, a mobile server for remote access to data, and others. The corporate network also includes databases to host participant data information, e-mail and portal servers to provide collaboration and content management, and BizTalk servers to provide for line-of-business integration. There are also pre-existing legacy servers, Java and other messaging systems on the network and on the extranet to which the coordinator has access.

Figure 4-5. BizTalk and BAM in an ESB

At the beginning of a study, the coordinator uses a web application hosted on the web server. After entering some basic study information, the web application creates a message that is submitted to a WCF service. The WCF service is an on-ramp to the ESB; on-ramps translate the message into a standard message schema that all systems interfacing with the ESB support. Within the message content header is a predefined path by which the message is expected to follow, referred to as an itinerary. The message is routed to a number of systems that interface with the bus, including a directory server to allocate study administrators, the e-mail system to send study information to participants, database servers to record that the study was initiated, and legacy payroll systems to open escrow accounts for study participants to receive payments for their participation. In each interface, the message from the bus is transferred to the host system off-ramp for processing; reply messages are returned on the bus. Each time new clinical data is acquired, it is submitted to an on-ramp, and the itinerary routes it to the correct systems.

As clinical data flows through the ESB, BAM can capture that data and summarize it in real time. As an example, BAM could capture data on changes in patient cholesterol level and blood pressure, and provide summary data to the physicians managing the study. This allows safety and efficacy of the medication under study to be reviewed in real time during the trial. BAM activities and views could be created to monitor all calls made to WCF services from both the ESB and each of the systems that interface with the bus.

BAM and BPM

The concept of BPM was introduced in Chapter 1. Business process management systems (BPMS) seek to automate a business process. An example business process would be a purchasing workflow, where the creation of a purchase order causes an approval request to be sent to each approver in turn in the management chain.

BizTalk Server provides an integration-centric approach to BPM, focused on workflow between different systems. Microsoft Office SharePoint Server (MOSS) workflows and black-pearl from K2 are examples of human-centric BPMS, focused on workflow between people. BizTalk Server 2004 shipped with a feature called Human Workflow Services (HWS), which attempted to provide human-centric BPMS capabilities. HWS was never widely adopted and was quickly abandoned by Microsoft; we strongly recommend that you don’t adopt HWS on any of your projects. BizTalk Server’s business rules engine (BRE), however, has been widely adopted, providing a flexible means to define domain-specific logic outside of application code.

In the future, we expect that a WF host technology, codename Dublin, will become a central part of Microsoft’s BPM strategy. Microsoft’s business process modeling tools have been weak until recently; we expect tools like the M language and the Quadrant modeling tool will be used to significantly strengthen Microsoft’s modeling products.

As an example of a business process implementation, let’s consider a purchasing work-flow used at a large defense contractor. The company works on a variety of government contracts, and each government contract has specific rules for authorizing purchases. On some contracts, employees of the company can approve any necessary purchase. On another contract, the rule might be that any purchase greater than $10,000 needs to be approved by the government. On a third contract, the rule might be that total purchases from a single vendor greater than $1,000,000 in a single calendar year require government approval. The defense contractor has an ERP system, but the purchasing capability in the ERP system is incapable of implementing the complex rules for approving purchases. The company would, however, like to use the ERP system’s screens for creating and tracking purchase requests.

One way to meet this need would be to use BizTalk to capture new purchase requests created by the ERP system, and hand them off to a workflow in either MOSS or K2 (see Figure 4-6). The workflow tool would implement the purchase approval workflows and hand the approved or rejected order request back to BizTalk, which would update the ERP system. When goods are received, the workflow system would be used to track the goods and update the ERP system with the arrival date.

In this environment, BAM would be used to monitor the purchasing process. Each order in the ERP system could include a date when order approval is needed and also a date when the goods themselves are needed. When a purchase request is transmitted to the workflow system by BizTalk, BAM would capture data about the request. In addition, it would capture data when the approved request is returned and when the goods are received.

BAM data would be used by the business in two ways: to monitor the purchase process and to generate alerts when deadlines are missed.

Monitoring the purchase process would require an aggregated view to provide summary information on how the process is performing. The view would probably contain measures like average time to approve a purchase order and average time for goods to be delivered after an order is approved. The data could be broken down by department, item categories, or supplier so that the efficiency of different departments or suppliers could be compared.

Figure 4-6. BizTalk in BPM

Because each purchase request contains deadlines, BAM can be used to monitor whether the process is completed within the deadlines. BAM can raise alerts when specific conditions arise in the data, either at an aggregate level or for individual items. BAM could raise an alert when a purchase request is not approved before the approval deadline, or when goods are not received before the delivery deadline. Alerts can also be raised, however, for issues that affect all items. As an example, an alert can be raised when the average time to approve a purchase request is more than seven days or when multiple orders from a vendor miss their delivery deadline.

BAM and Composite Applications

Composite applications are the very definition of “Do More with Less.” Composite applications compose multiple existing services into a new application. In the Web 2.0 world, composite applications are often referred as mashups. In the enterprise space, composite applications rely heavily on exposing line-of-business systems such as ERP or manufacturing control systems via APIs, services, or adapters. These endpoints are referred to as the service façade and provide access to existing functionality. Services become the building blocks for various applications; their function remains the same, but their usage differs depending upon the caller.

Great care must be taken when designing composite applications, as legacy system APIs may have undesirable side effects when the black box hides too much, when a transactional model has not been fully developed, or state and caching of data have not been properly implemented and considered.

Because of its origins as an integration server, BizTalk provides strong support for the composition of multiple distinct units of functionality into a single logical unit. Orchestrations may be used to compose calls to line-of-business systems, services, or even simply execute in-line C#. The orchestration may be exposed via a WCF service or initiated using any of BizTalk’s receive adapters (see Figure 4-7). BizTalk also has a Line of Business adapter pack, which provides prebuilt adapters for integrating to various line-of-business systems through WCF, and a toolkit for building custom adapters.

Figure 4-7. BizTalk as a composite application host

Because composite applications are composed from multiple service endpoints, either WCF or web services, BAM may be used to instrument and monitor them. As an example, consider an e-learning company that develops several services to expose the functionality of its core domain-specific objects: student, parent, teacher, content, scheduling, billing, and so forth. Each service provides a WSDL contract describing the messages it can accept. Some of the services, such as the billing service, interface with BizTalk by calling another WCF service that BizTalk exposes to execute an orchestration. The benefit of this architecture is that multiple applications can take advantage of each service.

One application allows for counselors to examine a student’s curriculum and suggest a plan tailored to meet the needs of the student, while fitting within an acceptable tuition cost. Another application, implemented as a Windows service, queries the student service to determine a student’s preferences for learning sessions, and then uses the scheduling service to allocate a time period to hold the instructional session. Once the session is complete, the application contacts the billing service, instantiates a BizTalk orchestration, and generates an invoice.

BAM activities and views could be created to identify the most popular scheduling times, to remediate billing problems due to students not showing up, to adjust lesson plans to better contour them to the needs of the student and the ability of the parent to pay, and so on. Composite applications seek to present multiple application interfaces; BAM unifies those interfaces into one holistic view. As messages flow through the services, BAM provides a single source that crosses boundaries and breaks open silos of information.

Summary

Regardless of the architectural model, both BizTalk and BAM may be utilized in that model to provide instrumentation of business processes, as well as alter the behavior and ultimate outcome of those processes in real time.

BAM and BI solutions utilize many of the same foundational concepts, including metrics for decision making that are based on date, time, or data values. BAM and BI differ in how the metrics are implemented, however. The most important difference is BAM’s focus on real-time information, where some BI implementations are focused on historical information. Where both BAM and BI expose similar front-end technologies to the user, the middle tier and data stores for both differ widely.

This concludes Part 1, which introduced the basic concepts of BAM, including installation, configuration, and a simple walkthrough of your first BAM project, and provided context of where BAM fits into your business.

Part 2, beginning with the next chapter, builds upon the introduction, providing instructions on using the BAM toolset with BizTalk Server. Chapter 5 describes the tools that business analysts use on a BAM project to specify the data that will be captured and how it will be displayed.