image

In this chapter, we’ll focus on the data BAM will collect and how it will be displayed. The end result is referred to as a BAM observation model, the conceptual definition of the activities you wish to observe using BAM.

Before diving into the observation model, we’ll present a method to keep your BAM artifacts organized. Without a predefined BAM project type within Visual Studio, it can become tedious to track and manage your many BAM files. In this section, you’ll learn how to use source code control with BAM. The next section describes activities, the basic building blocks of any BAM solution. Activities specify the data that will be captured from the business process; they simply specify field names and types. The following section introduces a sample application that will be used in Chapters 5, 6, and 7, and includes an exercise to build the sample activity. After that, we’ll describe the Orchestration Designer for Business Analysts (ODBA), an alternative tool for building activities. We’ll then cover views, which are used to specify how data is displayed. Views allow data to be aggregated and analyzed based on the BI concept of measures and dimensions. The final section describes the BAM Management (BM) tool that is used to deploy activities and views into production.

Setting Up a BAM Solution

One of the reasons developers often struggle with BAM solutions is that BAM solutions aren’t contained within a single logical container. While Visual Studio does have a BizTalk solution project type, it doesn’t have a BAM counterpart. Over time, having to search for BAM artifacts without a structured means of storage adds a great deal of time to the development and deployment of a BAM solution—time that could better be spent refining the business process. While your solution may be observing the data flowing throughout your business, sometimes there’s no one observing the way you organize your code.

The following exercise creates a simple project container to hold your BAM artifacts. This is a project that doesn’t compile, but it will provide you the ability to get at your BAM artifacts from within a centralized location using a tool that should be familiar to you, Visual Studio 2008. You don’t have to set up this project to make BAM work, but if you do, it will make working with source code control much easier, allowing you to keep all artifacts associated with your project in your source code control system.

EXERCISE 5-1. SETTING UP A BAM SOLUTION

ImagesNote BizTalk and BAM solutions are not unlike other Visual Studio projects in that there is a need to keep project names short (less than 32 characters). Issues arise when project names, especially nested ones, expand beyond 32 characters. When choosing a naming convention, it’s best to be as descriptive as possible, but also to bear this limit in mind. Remember, it’s okay to abbreviate—just make sure you and your colleagues will know what the abbreviation stands for. Just like the saying goes, it’s not as important to be right as it is to be consistent.

Capturing Data Using Activities

Activities are the heart of a BAM application. An activity is the set of fields that will be captured from a business process. Four types can be captured in an activity:

  • Business Data – Text: This is stored as a SQL Server nvarchar, so it can store any Uni-code character. When you create a text field, you must specify the maximum length of the text. The default is 50 characters.
  • Business Data – Integer: This is stored as a SQL Server int.
  • Business Data – Decimal: This is stored as a SQL Server float.
  • Business Milestone: A business milestone is a date and time, usually captured from the date and time that a message was processed. It is stored as a SQL Server datetime.

As you create an activity, don’t worry too much about how the data will be displayed to the user. Focus on the data items that need to be captured from your business process.

Two tools can be used to create an activity: Excel (via the BAM Add-In for Excel) and the Orchestration Designer for Business Analysts. Most of the time, Excel is preferred, because Excel can create the full range of activities and views, whereas ODBA can create only activities and simplistic default views. Activities and views could also be defined by editing the XML file by hand, but this is not recommended because it is inefficient and error prone.

At times a BAM implementation will hit a roadblock during analysis, due to a number of reasons:

  • There are differences in perception as to how the business process actually operates.
  • There are differences in terminology used throughout a process or between different participants in a business process.
  • There are differences in how a milestone or a point of importance is defined, and even disagreement about whether it is relevant.
  • There are differences in understanding as to the data available during a business process, where and when it is stored, how BizTalk is involved, and which aspects of that data are of importance.
  • There are just “differences.”

Before embarking on defining an observation model, we find that it’s important to address these differences. It’s crucial to the success of the project to ensure that

  • Business processes are documented and well understood by both your team and the process participants.
  • A data dictionary, glossary, or master data management tool exists that contains a clear definition of the data items to be captured.
  • A roles definition document exists that contains a clear definition of the roles each participant plays.
  • A business case and a functional case have been made for the activities and views that are to be defined, including relevance, timelines, audience, scope, and likelihood to change.
  • An application architect, team lead, or information architect has collaborated with the business team to provide transparency into data currently available, as well as the data that could become available in working with partners or other data sources.
  • Expectations are set properly, especially in fostering a collaborative environment. Each team member brings unique skills to the project, and the resultant output and effectiveness of the BAM solution is largely a reflection of that.

The Sample Scenario

In this section, we’ll present the case study used in the exercises throughout Part 2. You may wish to note this page to refer back to it throughout Part 2.

The Arnold, Wilbur, and Olivia Corporation (AWO) is an international leader in specialty building material construction. AWO is known for innovation in building materials, especially in the area of environmentally sensitive building materials. One of AWO’s business units manufactures custom building materials formed from recycled agricultural materials. Straw bale construction is eco-friendly because it is low cost, provides excellent thermal insulation, and is constructed from recycled rice straw that would otherwise be a waste product.

The majority of AWO’s sales orders are generated by independent sales agents, who use a Windows application that estimates the cost of custom shapes and sizes of bales. Once the order is complete, the application sends it to a secure FTP site maintained by AWO. AWO also receives a few orders from a web site that allows contractors to order standard bale sizes.

A BizTalk application manages the sales order process. Receive locations monitor the FTP site and the MSMQ queue that transmits web orders. Each order starts an orchestration (see Figure 5-4) that includes the following steps:

  1. Send the order to the Engineering department.
  2. Receive a response from Engineering. Engineering will accept or reject the order depending on whether or not it meets state building codes.
  3. Send the order to the Purchasing department for straw and fastener acquisition.
  4. Receive a response from Purchasing that includes a promised date for the materials.
  5. Send the order to the Accounting department.
  6. Receive a response from Accounting that includes an order number.

Each agent has an agent number and sends a unique order number with each order. The combination of the agent number and the order number is able to uniquely identify any order. Engineering, Purchasing, and Accounting can return the agent number and order number with their responses, and the two numbers will be used to correlate their responses back into the correct orchestration.

In addition to the order number, Engineering’s response includes an engineering control number that is used by Engineering’s software systems to track the approval process. Engineering control numbers are unique.

If Engineering approves the order, it sends a message to the Manufacturing department using a separate BizTalk application that is based on BizTalk Messaging, with a send port subscribed directly to the receive port. This message doesn’t include the order number, but it does include the engineering control number.

images

Figure 5-4. The AWO sales order orchestration

For each order, we will gather several pieces of data:

  • Agent number
  • Order number
  • Engineering control number
  • Engineering response, either accept or reject
  • Volume of materials in the order
  • Total number of bales
  • Price of the order
  • Customer name
  • Customer postal code
  • Customer state or province
  • Customer country
  • Total number of machine tool operations
  • Date that materials were promised by Purchasing
  • Date and time the order was received
  • Date and time a response was received from Engineering
  • Date and time a response was received from Purchasing
  • Date and time a response was received from Accounting
  • Date and time order was sent to Manufacturing

One of the business benefits of BAM is that it allows data from different business systems to be cross-referenced. The engineering project control system uses engineering control numbers to track orders, whereas the sales system uses the agent’s order number. The BAM activity provides a cross-reference between the two.

Continuations

In this scenario, we need to capture data from both the sales order orchestration and the manufacturing instructions that pass through the messaging solution. The customer data comes from the sales order. The number of machine tool operations comes from the manufacturing instructions. To view these in a single activity, we will connect the two sets of data using a technique called continuations.

A continuation is a field that can be used to identify a business process. In the sample, if the Engineering department approves the order, it generates an engineering control number that is passed to the orchestration. The engineering control number is also available in the manufacturing instructions. This means that the manufacturing instructions and the order process can be connected into a single activity using the engineering control number. BizTalk developers refer to the engineering control number as the continuation between the activities.

It’s not necessary to specify details of how continuation works in the activity definition, as long as all data items needed for continuation are present. In a BizTalk application, continuation details are set using the Tracking Profile Editor (TPE).

ImagesNote Chapter 6 covers the TPE in detail and includes an exercise that implements a continuation.

EXERCISE 5-2. DEFINING AN ACTIVITY USING EXCEL

Orchestration Designer for Business Analysts

Orchestration Designer for Business Analysts is an add-in for Microsoft Visio that allows nontechnical users to define a business process. ODBA also allows a BAM activity to be created. It’s less useful than the BAM Add-In for Excel, because its options for creating views are much less flexible. When an activity is created, a simple default view is built, but no other views can be created.

If you don’t have ODBA installed, you will need to install it to do this exercise. Officially, ODBA works only with Visio 2003, and you can’t use Visio 2007. However, there is an unsupported hack that will install ODBA on a machine running Visio 2007. The hack has worked for us in the past, but as with all hacks, there are no guarantees. You may find that the representation of the business data of interest on the drawing surface is ugly, but you should be able to right-click the business data and edit it correctly.

ImagesNote ODBA is unsupported on Visio 2007. Back up your machine before attempting to install ODBA on Visio 2007, and be aware that Microsoft Support won’t help you if this hack damages your system.

When ODBA is installed, it is looking for a specific registry entry. On a 32-bit machine, the registry entry is HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice11.0Visio. On a 64-bit machine, the registry entry is HKEY_LOCAL_MACHINESOFTWAREWow6432Node MicrosoftOffice11.0Visio. If you want to do the hack, the procedure is as follows:

  1. Start RegEdit.exe.
  2. On a 32-bit machine, find the registry entry HKEY_LOCAL_MACHINESOFTWAREMicrosoftOffice12.0Visio.
  3. On a 64-bit machine, find the registry entry HKEY_LOCAL_MACHINESOFTWARE Wow6432NodeMicrosoftOffice12.0Visio.
  4. Right-click the registry entry you found, and export it to a file.
  5. Use Visual Studio to edit the file and replace all instances of 12.0Visio with 11.0Visio.
  6. In RegEdit, import the modified file.

If you have both Visio 2003 and Visio 2007 installed, you should configure ODBA to use Visio 2003. Again there’s a hack for this, but this one is documented and supported by Microsoft. If you have both Visio 2003 and Visio 2007 installed on your system, you can ensure that ODBA runs in Visio 2003 using the following procedure:

  1. Display the Start menu, and browse to BizTalk Server 2006.
  2. Right-click Orchestration Designer for Business Analysts and select Properties.
  3. Ensure that the target of the shortcut and the Start In folder both refer to the c:Program FilesMicrosoft OfficeVisio 111033 folder.

EXERCISE 5-3. DEFINING A BUSINESS PROCESS USING ODBA

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.86.154