From the Publisher

With this official MCSE Training Kit, IT professionals learn how to install, administer, and troubleshoot BizTalk Server 2000. As they build these real-world systems-support skills, they're also getting in-depth preparation for MCP Exam 70-230—a key elective on the Microsoft Windows® 2000 MCSE track. Topics map directly to the objectives measured by the exam; students learn through an integrated system of lessons, case-study based exercises, and self-assessment. An economical alternative to classroom instruction, this kit enables working professionals to set their own pace and learn by doing!

Official Microsoft study guide for administering BizTalk Server 2000

Provides self-paced, from-the-source information and practice with the skills measured by MCP Exam 70-230—a key elective on the Windows 2000 MCSE track
Key Book Benefits:
* Offers detailed, from-the-source instruction for setting up and supporting BizTalk Server 2000

* Provides in-depth preparation for MCP Exam 70-230, which can be used to fulfill one of two elective requirements on the Windows 2000 MCSE track

* Features a searchable version of the study guide on CD-ROM—plus 120-day evaluation versions of BizTalk Server 2000, Microsoft Visio 2000, and Microsoft SQL Server™ 2000—for training anytime, anywhere!

Product Details

• Table of Contents
• Read a Sample Chapter

Table of Contents

Read a Sample Chapter

Chapter 8.
BizTalk Orchestration

• About This Chapter
• Before You Begin
• Lesson 1: Overview of BizTalk Orchestration Services
• Introducing BizTalk Orchestration
• Workflows
• The BizTalk Orchestration Designer Environment
• The BizTalk Orchestration Process
• Benefits of BizTalk Orchestration
• Lesson Summary
• Lesson 2: Creating XLANG Drawings
• The Design Process
• Creating the Diagrams
• Practice: Creating an XLANG Drawing that Uses the Decision Shape
• Practice: Creating an XLANG Drawing that Uses Transaction Shapes
• Lesson Summary
• Lesson 3: Specifying Data Flows
• Creating and Configuring Ports
• Using Implementation Shapes
• Defining Data Flows
• Completing XLANG Drawings
• Practice: Using Implementation Shapes and Defining Data Flows
• Lesson Summary
• Lesson 4: Compiling, Debugging, and Running XLANG Schedules
• Compiling XLANG Drawings
• Practice: Compiling an XLANG Drawing to Create a Schedule
• Running XLANG Schedules
• Debugging XLANG Schedules with XLANG Event Monitor
• Practice: Using XLANGMon
• Lesson Summary
• Review

Chapter 8   BizTalk Orchestration

About This Chapter

BizTalk Orchestration Designer is a graphical environment that you can use to design business workflows. It uses a graphical language that consists of predefined shapes. The shapes can express important concepts, such as sequence, branching, and concurrency. By using orchestration, you can separate the concepts of a process, an object that represents the process, and an implementation artifact. In other words, orchestration allows you to create a formal description of a business process, which can then be compiled and run.

Lesson 1 examines in some detail the advantages of using orchestration and introduces you to BizTalk Orchestration Designer. Lesson 2 shows you how you can use BizTalk Orchestration Designer to create XLANG schedule diagrams. Finally, Lesson 3 shows you how you can compile the diagrams into XLANG schedules to be used in a production environment.

Before You Begin

• Completed the lessons in the previous chapters or have equivalent understanding
• Have a BizTalk Server system available with Microsoft Visio installed

Lesson 1: Overview of BizTalk Orchestration Services

• Understand the concept of workflow.
• Understand the benefits of using orchestration.

Estimated lesson time: 30 minutes

Introducing BizTalk Orchestration

Workflows

The basic elements of a workflow are the steps of the procedure it designs and the dependencies between them. You can also indicate which entities (also called roles; these are persons or applications) are responsible for which tasks, how long each task is expected to take, and what happens if a deadline is not met. In addition, you can specify routing of items, such as documents. Depending on the specific implementation of the workflow, you can either make the workflow engine responsible for routing or you can have the participants take some or all of the routing responsibility. With BizTalk Orchestration Designer, you use the latter method, and the participants determine how the documents and control are routed.

After you design the business process that shows all the messages that are to be exchanged, you can compile it into an executable flow. In BizTalk Orchestration Designer, such a compiled process is called an XLANG schedule.

The BizTalk Orchestration Designer Environment

The graphical language used by BizTalk Orchestration Designer makes it easy to illustrate and to see how business processes flow. Using the appropriate shapes, you can express the beginning and the ending of a business process, the sequence of processes, branching, and process concurrency. Once you are satisfied with the design, you can bind the business process elements to specific ports to show the flow of documents between the process you just defined for your organization and the outside world. A port specifies a location from which the data can be input into an XLANG schedule or output from it.

BizTalk Server uses XLANG, a special XML-based language, to express, or describe, business processes. The first step in creating a formal business description is to create an XLANG schedule drawing. You create this drawing by using various tools and connecting them using the graphical language. Once the drawing is complete, you indicate how it is to be executed by binding your processes with implementation ports. Finally, you compile your XLANG drawing to create an XLANG schedule, or an XML-based description of the workflow. You then test and debug the schedule to make it ready for production.

Keep in mind that the compiled XLANG schedule is significantly different from any other compiled entity. You can't simply run an XLANG schedule on a server, because typically there is no single server on which you can execute the entire schedule. Rather, you can think of it as a binding contract between your organization and other organizations, almost like a legal document, that describes how the parties interact and what the result of those interactions are.

The BizTalk Orchestration Process

The first step is to define the workflow by describing it in terms of an XLANG drawing. Creating an accurate XLANG drawing is not a trivial task. You must first analyze the interactions between entities, or roles, within your business organization and you must also analyze the interactions between those organizations and applications outside of your organization that interact with it. One of the best ways to describe these interactions is using the interaction diagram, which shows roles and the ways in which the roles interact. You use this diagram as a foundation as you express the business process. The details of this process are described in Lesson 2, later in this chapter.

The next step is to analyze documents and data formats. For more detail, see Chapter 4.

Benefits of BizTalk Orchestration

Provides an Explicit Business Model

Every organization follows a business model. Unfortunately, not every organization has a formal, or even an informal, description of such a model. In fact, for many businesses, their business model lives inside people's heads. This might work well for very small organizations that consist of a handful of employees and in which everyone understands the organization and the business processes completely. But as an organization grows, it is impossible to keep every aspect of a business process in your head! The result might be that different people store in their heads different aspects of the process. This is an invitation for a disaster, particularly if an employee leaves.

Many businesses have tried to work around this problem by creating documentation about their business model. In the ideal world, documentation accurately reflects business processes and is updated every time there is a change. Unfortunately, reality is very different. Many people don't understand the value of keeping the documentation up to date, or become too busy and simply forget, or leave before they can make the necessary changes. There might be countless reasons why documentation doesn't get updated, but the result is always the same—loss of important business intelligence.

BizTalk Orchestration Designer bypasses this problem by rolling the product and the documentation into one. BizTalk Orchestration Designer allows you to easily express how business processes relate to each other within an organization. The advantages of having a formal description of business processes are obvious. Such an explicit business model can be consulted when changes are needed, or you can use it to figure out how the processes are done so that you can program against this model. Then, when you make changes to the way your business works, you don't need to perform the extra step of documenting them. In effect, BizTalk Orchestration Designer produces business documentation that is executable.

Adding Business Partners Made Easy

Many previous solutions that were used to describe business processes offered the possibility of achieving business document flow between trading partners. However, this was usually done in pairs. That is, you could create, describe, and program against a model that described interactions between your organization and one specific business partner. Adding another partner wasn't easy. In fact, you had to create additional pairings for each additional partner. This approach suffered from the combinatorial explosion problem: for three partners the overall solution needs three pairings; for four, six; for five, ten, and so on. With BizTalk Orchestration Designer, you don't have to create any special solution for an additional trading partner, because BizTalk is designed for multipartner interactions.

Unifies the Analysis and the Coding Stages

The traditional attempts at automating business processes consisted of two stages: the design stage and the coding stage. The design stage consisted of analyzing the existing business processes, and the result of this analysis was some sort of a diagram, typically a workflow or interaction diagram describing the processes. During the analysis stage, steps might be taken to streamline and improve business processes, but overall the focus was on describing the existing situation, not on improving it. Analysis was usually performed by business analysts who did not necessarily have any programming background.

The coding stage consisted of analyzing the diagram produced in the analysis phase and creating applications that followed the model. The programmers responsible for the deliverables of this stage did not necessarily have any business background.

The main problem with this approach was that different people were responsible for different stages. Communication wasn't always clear, which resulted in many delays and lost opportunities to improve the design and the coding.

BizTalk Orchestration eliminates the gap between the business analysts and the programmers who were responsible for the two stages. Now, one team, or even one person, can perform the tasks that were once done in distinct stages. The tools that BizTalk Orchestration Designer supplies are integrated, which means that the process no longer has to consist of two stages. The distinction between a business analyst and a business programmer-implementer has also been blurred. The result is an environment that allows for rapid development of business solutions.

At the same time, BizTalk Orchestration separates business logic and implementation. This separation is very obvious even on the work surface, which is divided in two parts: in one you use Flowchart shapes to represent flows, and in the other you use Implementation shapes to represent implementation technologies.

Updates the Business Process

Another big advantage of using BizTalk Orchestration is the flexibility it offers. Business processes, or models, are not constant; they change over time. Some changes are small. For example, you might add a new product to sell that is related to the product your business is already selling, and implementing changes necessary to process the new sales isn't a very complex task. However, some changes are substantial, or even fundamental. For example, acquiring a company and integrating its processes with the processes already in place requires a substantial amount of effort. Many changes fall somewhere in between. But whatever the change, it is far easier to change the business model and implementation if you have orchestrated the original situation. Adding or removing processes is easy with BizTalk Orchestration Designer.

Provides Support for Short-Running and Long-Running Processes

With BizTalk Orchestration Designer you can model all kinds of business processes, from simple to complex, ranging in duration from seconds to weeks or even months. For example, you can orchestrate the process of ordering and delivering online an electronic version of a book, a process that can be performed in a matter of seconds. After all, if the electronic version of the book a customer wants to buy already exists online, it can be uploaded to the customer as soon as a credit check is completed. You can just as easily orchestrate a process ordering, producing, and delivering an airplane, a process that will take months to execute. The credit check for this process will likely take longer, the plane takes weeks to build, and some parts might need to be ordered from the supplier, who might need time to manufacture them. Then the testing again takes time, and the delivery is not as easy as the delivery of goods electronically. But the fact that you can orchestrate both these processes the same way is a big advantage of using BizTalk Orchestration Designer.

Keep in mind that the actual execution of these two types of processes will differ. In the first case, communication takes place synchronously. In a process that spans seconds or minutes from the beginning to completion, this is the appropriate model to follow. In contrast, if a process takes days or weeks, tight coupling and synchronous communication doesn't make sense. After all, for practical reasons, you don't want to keep a connection open for weeks. In addition, long-running processes must be robust; that is, they cannot fail just because a connection becomes temporarily unavailable while the process is not active. For this reason, although a long-running process is orchestrated in the same way as a short-running one, and looks the same to a user, the underlying mechanism differs.

Treats Process and Schema as Commodities

With orchestration, a new and interesting possibility arises. Because the process is now presented in the form of an object, this object can be published. Similarly, document schemas can now be treated as commodities. In other words, a business entity can publish its business model, and trading partners who want to do business can be required to use this model.

Integrates Different Technologies

Orchestration allows you to integrate dissimilar applications into your business process. This is possible because of flexible binding. An XLANG schedule communicates with the outside world using implementation ports. The role of the port is to bind the XLANG schedule to a specific technology. However, the details of the implementation of these ports are not visible from within the XLANG schedule. It is not the schedule but the port that implements a specific technology. If you later want to use a different technology, you don't need to change your XLANG schedule. All you need is a new binding.

Lesson Summary

A workflow is a methodology used to describe the entities, or roles, that participate in a business process and the messages they exchange. Once you design a workflow within BizTalk Orchestration Designer, you can compile it to create an XLANG schedule.

In this lesson you also learned the benefits of using BizTalk Orchestration Designer. With BizTalk Orchestration Designer, you can create an explicit business model that is easy to expand and modify. You can add and remove trading partners and change processes in a way that will be easy to manage, because business analysis and programming implementation are no longer separate phases. In addition, orchestration allows you to create long-running business processes just as easily as you can short-running ones.

Lesson 2: Creating XLANG Drawings

When you are planning for long-running processes, you must take steps to ensure that your process performs smoothly even if some action fails. The failure of an action might require that some other actions be undone. Because the earlier actions might have committed long before the later action fails, you must design a compensation process that will undo the effects of the earlier, committed actions.

• Use BizTalk Orchestration Designer.
• Create an XLANG diagram.

Estimated lesson time: 30 minutes

The Design Process

In Lesson 1, you were introduced to the idea of a workflow. To design a workflow, you need to have a detailed understanding of your business process. You can do this in many different ways, and the approach outlined here is one possibility.

The design process proceeds in steps. First, you need to determine the participants and the data they share. One way to perform this step is to create an interaction diagram. Second, you need to analyze the documents and the data formats. Finally, you need to analyze entities, or roles, and specify how the documents will be passed from one participant to the next. The following sections provide more detail about how to perform these steps.

Step 1: Creating an Interaction Diagram

An interaction diagram shows all entities participating in a business process and the messages that these entities exchange. The entities are sometimes referred to as roles, and can be thought of as agents that send messages. Unfortunately, few tools exist for helping you create interaction diagrams.

The most important feature of an interaction diagram is that it allows you to control the level of detail at which you perform the analysis. Therefore, while you will want to include all the individual roles within your own organization, you can allow the details for the process on the trading partner side to remain quite sketchy. In fact, you might find you don't need to include any specific roles for your trading partner, and have just one role placeholder representing it. This way, you end up with a complete description of a business process on one side and only a general description of what happens at the other side.

If your business organization already uses automated workflows, you might find a diagram of those useful. A sample diagram, shown in Figure 8.1, uses the scenario presented in Chapter 6. In your organization, you might find that the details for the process are a bit sketchy on both sides. If so, you will need to flesh out the roles on the side of your home organization.

Figure 8.1 A sample business interaction diagram showing the exchanged messages but no roles (Image unavailable)

Use the diagram shown in Figure 8.1 as a model, fleshing it out by specifying what role in your organization participates in any given exchange. You will find that, often, it's helpful to include in your diagram how roles within your organization communicate with each other. Because such communication is not important for intra-organization exchanges, you might not find any information about it in the diagram you start with. However, the information is vital for creating workflows, and therefore must be included in the interaction diagrams.

Step 2: Analyzing Documents and Data Formats

Once your interaction diagram is ready, you can use it to analyze documents and data formats that participate in each data exchange. Look at your interaction diagram and identify all the arrows pointing from one participant to another. The arrows represent the flow of data between sources and destinations. For each such pair, determine the document formats. For each document format you need to create a document specification. For more details about creating specifications, see Chapter 4.

It is quite common for document formats to differ markedly: the source sends one document format, and the destination expects a very different format. When this happens, you need to specify how to translate the document from one format to another. In BizTalk Server, you do so by creating a map. For more detail about maps, see Chapter 5.

Step 3: Analyzing the Diagram Role by Role

In the final step, you analyze each role and specify what kind of messages it sends and what messages it expects. Later, when you create your XLANG drawing, you create actions for sending and receiving.

Creating the Diagrams

Using the Graphical Language

BizTalk Orchestration Designer uses two groups of shapes: Flowchart shapes and Implementation shapes. Flowchart shapes represent how data move within the process. Implementation shapes show how the data enters the process and how it leaves. In other words, the Implementation shapes represent the communication of the business process with the outside world.

Designing the Business Logic by Using Flowchart Shapes

Flowchart shapes are used for designing the logic of data and control flow. Using these shapes, you can create a diagram that shows how actions are related to each other, in what order they will be executed, and what the alternative flows are.

Each shape has handles that you can drag to other shapes. By dragging handles to other shapes, you can indicate how the data flows from one shape to another.

Entry and Exit

Two special shapes are predefined to indicate both ends of the execution process. They are Begin, which is already placed in the diagram when you launch BizTalk Orchestration Designer, and End, which you drag to the work surface. There can be only one Begin shape, indicating that you can enter the workflow in only one way. The process starts at the Begin shape, so this shape has no data flow into it, and it has only one exit. However, you can exit the workflow in several ways, and so you can include multiple End shapes. Once data flows into an End shape, the process is completed, and therefore an End shape has no exit.

When you open BizTalk Orchestration Designer, the Begin shape is already placed for you. You can move it, but you cannot delete it. If you try to do so, a message appears telling you that there must be a Begin shape in a drawing.

The Begin shape exposes two properties that you can set and one read-only property. These properties pertain not to the Begin shape specifically, but to the entire XLANG schedule. Here are the details:

• Transaction Model. This property specifies how the transactions are treated. If you want transactions to be supported within each XLANG schedule instance (that is, when you run this XLANG schedule), set this property to Include Transactions Within The XLANG Schedule. The other value, Treat The XLANG Schedule As A COM+ Component, specifies that the XLANG schedule can be activated from within a transactional COM component.
• Transaction Activation. This property is available only if you set the Transaction Model property to Treat The XLANG Schedule As A COM+ Component. This property can take one of four values: Not Supported, Supported, Required, and Requires New. Transactions are discussed in more detail later in this lesson.
• XLANG Identity. This is a read-only property whose value is a globally unique identifier (GUID) generated automatically when the Begin shape is placed on the work surface of a new drawing. BizTalk Orchestration Designer uses the value of this property to correlate the drawings with XLANG schedules compiled from these drawings. When you create the drawing, the value of this property changes each time you make a change in the drawing—that is, when you add or delete a shape or a link, or when you set a property of any object.

Abort

The Abort shape is used to abort the schedule instance. A typical use of this shape involves combining it with a Decision or a While shape within a transaction. By using a Decision shape, you create a branch in a business process. For example, you can use rules in a Decision shape to decide what process branches are valid. If the data doesn't meet any of the rules, you can attach an Abort shape to the Else clause, thus aborting the processing for invalid data. The Abort shape doesn't expose any properties.

Actions

BizTalk Orchestration Designer uses ovals to represent actions. An action represents a communication process. An action has an entry and an exit, which means that the workflow flows through it. You also indicate how the data flows into or out of the action. To do so, you simply connect the action to an XLANG port.

When you drag an Action shape onto the drawing surface, it will have an uninspiring name, such as Action 1. You can change the name by right-clicking the shape and choosing Properties from the shortcut menu. In the Action Properties dialog box, simply type the name you want. You can rename an Action shape at any time. Name is the only property that the Action shape exposes.

Decisions

You use the Decision shape to indicate a choice in the path that the processing will follow. The Decision shape is located in the Flowchart stencil and looks like a diamond. To use the Decision shape, simply drag it to the drawing surface.

A decision is performed by evaluating a set of rules in sequence. Once a rule evaluates to TRUE, the path associated with that rule is followed. If no rule evaluates to TRUE, the Else path is followed.

Each rule must then be associated with an action. At runtime, the rules are evaluated in the order specified. If a rule evaluates to TRUE, the workflow moves to the associated action. You can set the rules by using Properties of the Decision shape, as shown in Figure 8.2. You can also rearrange the rules to change their order, which affects the order in which the rules will be evaluated. BizTalk Orchestration Designer places no limit on the number of rules you can add.

Figure 8.2 Specifying rules for the Decision shape (Image unavailable)

The Decision shape also exposes the Else clause. The workflow will move to the action associated with this clause if no rule evaluates to TRUE.

Practice: Creating an XLANG Drawing that Uses the Decision Shape

The XLANG schedule receives the Energy Usage Summary document and echoes it onto the screen. Next, you use a Decision shape to examine the message to determine if the user is exceeding the energy usage limit. If so, the schedule displays a warning on the screen. Finally, it copies the document to a file in a specified directory.

In this practice, you create the drawing of the business process only. Later in this chapter you will complete the schedule.

To create an XLANG drawing using the Decision shape

1. From the Start menu, point to Programs, point to Microsoft BizTalk Server 2000, and then click BizTalk Orchestration Designer. The designer opens and the work surface contains the Begin shape.
2. Click the Action shape in the Flowchart stencil on the left, and drag it to the position below the Begin shape. The Action shape you dragged will be labeled Action 1.
3. Right-click the Action 1 shape and choose Properties. In the Name text box, type Receive Energy Usage Summary. Click OK.
4. Click the Begin shape to bring it into focus. Click the control handle at the bottom of the Begin shape and drag it to the connection point at the top of the Action shape to connect the Begin and Action shapes.
5. Drag another Action shape onto the diagram and position it below the Receive Energy Usage Summary Action shape. Right-click the shape and choose Properties. In the Name text box, type Echo.
6. Click the control handle at the bottom of the Receive Energy Usage Summary Action shape and drag to the top of the Echo Action shape.
7. Click the Decision shape in the Flowchart stencil and drag it below the Echo Action shape. Click the control handle at the bottom of the Echo Action shape and drag it to the connection point at the top of the Decision shape to connect the Action and Decision shapes.
8. Right-click the Decision shape and choose Properties.
9. Click Add. The Rule Properties dialog box appears, as shown in Figure 8.3.

Figure 8.3 Creating a rule (Image unavailable)

10. In the Rule Name text box, type Over Limit. In the Rule Description field, type Check if the user's energy consumption is over the limit. Leave the Script Expression field blank; you will fill it in later. Click OK to close the Rule Properties dialog box, and then click OK to close the Decision Properties dialog box.
11. Click an Action shape in the Flowchart stencil and drag it to the right of and below the Decision shape. Right-click the Action shape, and then choose Properties. In the Name text box of the Action Properties dialog box, type Display Warning, and then click OK.
12. Click the control handle to the right of the Over Limit rule in the Decision shape, and then drag it to the connection point at the top of the Display Warning Action shape.
13. Click the Join shape in the Flowchart stencil and drag it to below both the Decision and Display Warning shapes. Right-click the Join shape, and then choose Properties. In the Join Type area, click OR, and then click OK.
14. Click the control handle to the left of the Else clause in the Decision shape and drag it to the connection point at the top of the Join shape.
15. Click the control handle at the bottom of Display Warning Action shape, and drag it to the connection point at the top of the Join shape.
16. Click the Action shape in the Flowchart stencil and drag below the Join shape. Right-click the shape and choose Properties. Type Write Summary To File, and then click OK.
17. Click the control handle at the bottom of the Join shape and drag it to the entry point of the Write To File Action shape.
18. Click the End shape in the Flowchart stencil and drag below the Write Summary To File shape. Click the control handle at the bottom of the Write To File Action shape and drag it to the connection point at the top of the End shape. Your drawing should now look similar to that shown in Figure 8.4.

Figure 8.4 Using the Decision shape (Image unavailable)

19. From the File menu, choose Save As. Save your drawing to your hard drive in the file FabrikamProcess.skv.

Loops

You have already seen one way to implement decisions in the Orchestration Designer, by using the Decision shape. This type of decision is typically made only once in the process. However, some actions need to be performed multiple times, and it is convenient to represent such a flow by using a loop.

BizTalk Orchestration Designer offers only one way of representing loops: using the While shape. You can include one rule in the While shape, which is evaluated each time the loop is performed. If the condition of the loop evaluates to TRUE, the loop is performed again. Otherwise, the flow moves to the action connected to the Continue clause of the While shape. You can configure the While shape to preserve the state of the loop, that is, to preserve the message that was used in each iteration. Otherwise, the message will be lost after one iteration.

Loops are often used in tandem with transactions, in which case special considerations apply, as you will see later in this lesson.

Concurrency

Two shapes control concurrency. These are the Fork shape and the Join shape. The Fork shape has one entry point and up to 64 exit points, which allows you to specify up to 64 concurrent flows leaving it.

When you use the Fork shape, you create separate flows that are completely independent of each other. This means that any actions that occur on the separate paths are completely independent of one another. It is impossible for the flows to communicate with each other, and therefore sending messages from one flow to another is illegal and the flow would not compile.

Once you split the flows by using the Fork shape, you must either terminate them independently or synchronize them. To terminate a flow, you simply use the End or the Abort shape. To synchronize the flows, you must use the Join shape. The Join shape is the Fork shape's complement, and it has up to 64 entry points and one exit point.

You can synchronize flows in a Join only if they were split from the same Fork. If you subsequently used another Fork to split flows, you must use another Join to synchronize those. In other words, your drawing must maintain one-to-one correspondence between Forks and Joins. The only exception from this rule is if you terminate both flows. You can split and re-split flows, but if you do so, you must join them in the reverse order, creating nesting forks. This is true even if you split the flows and then terminate one—you still must synchronize the other! This situation is shown in Figure 8.5.

Figure 8.6 shows the illegal use a Join. This drawing is incorrect on two counts. First, the OR Join is joining the flows that were split by using two different Forks. Second, two paths leading to the OR Join consist of more than one action.

Figure 8.5 Using one-to-one correspondence between Forks and Joins  (Image unavailable)

Figure 8.6 An illegal XLANG drawing (Image unavailable)

You can join the split flows in one of two ways. One way is to specify that all the flows must complete before the processing continues. The other requires only that one flow completes before the processing continues. To specify the behavior of the Join shape, you must specify its properties. To do so, simply right-click the Join shape and choose Properties, as shown in Figure 8.7. Two values for the Join Type property, described below, are available, but you can choose only one of them.

• AND. When you specify this property and then compile and run the XLANG schedule, the schedule waits until each flow you forked has completed. Once all the flows reach the Join shape with the AND property set, the processing continues with the next action after the Join. This property is set by default.
• OR. When you specify this property and then compile and run the XLANG schedule, the schedule waits until one of the flows you forked has completed. Once one flow reaches the Join shape with the OR property set, the processing continues with the next action after the Join. Note that all the forked flows continue until completion. In other words, processing that follows other paths also continues until the join is reached or processing is terminated.

When you join flows by using the OR property, each flow that enters such a Join can consist of only one action, as shown in Figure 8.8.

Figure 8.7 The Join properties (Image unavailable)

Figure 8.8 Joining flows by using an OR Join allows each flow to have only one action (Image unavailable)

You can nest Fork and Join pairs. BizTalk Orchestration Designer enforces no limit on the nesting levels, as long as the nesting is constructed correctly—that is, if you don't try to join flows that were split from different Forks. One such XLANG drawing with a nested Fork-Join pair is shown in Figure 8.9.

Figure 8.9 A Fork-Join pair nested within another Fork-Join pair (Image unavailable)

A different way to use the Join shape is to use it without the corresponding Fork shape, as was done in the practice earlier in this lesson. You can use the Join shape to synchronize the branches of the schedule after a Decision shape. You of course need to use the OR Join property, otherwise the flow would never progress past this shape.

Transactions

Transactions are groups of actions that are performed as one action. All the actions in a transaction collectively form a logical unit of execution, and therefore exhibit an atomic property. This means that either all actions in the transaction are executed or none is. If an action within a transaction is aborted, the other actions that have already been performed are rolled back, so that the effect is the same as if no action has been taken.

The Transaction shape is actually a container shape for the actions that together form the transaction. Thus, you can nest a transaction within another transaction. The nesting depth depends on the type of the transaction.

You can choose from among three types of transactions: timed, short-lived and long-running. To specify the transaction type, use the Type property of the transaction. Transactions are color-coded so you can identify at a glance each transaction in your drawing. And so, timed transactions are blue, short-lived transactions are gray, and long-running transactions are beige.

Sometimes it might make sense to retry a transaction that fails. To do so, you specify two properties, Retry Count and Backoff Time. Together, these properties control the retry behavior of a transaction. The value of the Retry Count simply specifies how many times the aborted transaction will be restarted and retried. The Backoff Time specifies how to compute the time interval for waiting each time before the transaction is restarted and retried. Note that this doesn't mean that the waiting interval will be the same each time. In fact, the waiting interval between each transaction gets increasingly longer. The length of the interval is computed by raising the Backoff Time to the power of Retry Count. And so, if the value of the Backoff Time property is 3 seconds and the value of the Retry Count property is 4, the resulting waiting intervals will be 3, 9, 27, and 81 seconds.

If at any time the wait interval is longer than 180 seconds, the transaction is dehydrated. Dehydration involves storing the information about the state of a transaction and the XLANG schedule instance in the Persistence database. This is one way to conserve resources, since a dehydrated XLANG schedule instance frees all resources. When the interval elapses and the Retry Count indicates that the transaction needs to be restarted, the XLANG schedule instance is rehydrated—that is, the state information is retrieved from the Persistence database and the schedule is re-activated.

Dehydration is used not only with the long wait intervals, but also for long-running transactions. This is one way for BizTalk Server to conserve resources, since dehydrated transactions and XLANG schedule instances consume none.

To decide which type of transaction is appropriate in your specific situation, analyze how long you expect a transaction to run and how important it is for the transaction to exhibit properties of atomicity, consistency, isolation, and durability (ACID properties).

Short-Lived Transactions

This is the only transaction type that exhibits all four ACID properties. Therefore, you use this type for those transactions for which the ACID properties are needed. Also, transactions of this type easily allow for rollback, which is not necessarily possible with the remaining two types of transaction. These transactions can be nested within other transactions; however, only the innermost transaction can be short-lived.

For short-lived transactions, you can specify the isolation level. You can choose from among four levels, which are presented here in order from the most to the least restrictive:

• Serializable. If you specify this isolation level for your transaction, the system guarantees that if you run this transaction concurrently with some other transaction, the result will be the same as if you ran both consecutively in some order. (Keep in mind that this doesn't mean that the result will be the same in each order.) This is the most restrictive setting, and therefore it is the safest setting for your transaction. Unfortunately, you pay a price in terms of performance when you specify this setting.
• Repeatable Read. This isolation level guarantees that if a transaction attempts to read the same data more than once, and if the transaction doesn't change the data, the value that the transaction reads will be the same with each read. This means that other transactions won't be able to change the value that the original transaction reads, but they might be able to access the value for reading.
• Read Committed. In this isolation level the transaction is allowed to read only committed data. In other words, if another transaction is updating the data and hasn't committed or aborted yet, the transaction with this setting won't be able to access the data.
• Read Uncommitted. In this isolation level the transactions are allowed to read uncommitted data that was possibly changed by another transaction. If you use this setting, you are improving the performance of your system. Keep in mind though that this is the least restrictive setting, in which some safeguards present in other settings do not apply. Use it with caution.

Using an appropriate isolation level is a good way to ensure the reliability and scalability of your business solution. However, for long-running processes, it is not possible to specify the isolation level, because doing so requires that access to the database be suspended for other transactions while this one is running.

For short-lived transactions, you can also specify the Timeout property. This property defines the time, in seconds, during which the transaction must complete. If the transaction doesn't complete within the specified time interval, it is aborted.

Long-Running Transactions

These transactions can last over extended periods of time, possibly months or even years. Keep in mind that for these transactions the ACID properties don't hold.

If an action in a long-running transaction fails, the transaction might need to be aborted. However, because a long-running transaction doesn't exhibit ACID properties, and because some actions might have already committed, possibly a long time ago, you need to provide a business process that undoes the committed actions of such a transaction. This additional business process is called a compensation. You specify the compensation on a separate Compensation For Transaction page in BizTalk Orchestration Designer.

Long-running transactions can be nested, but only two levels deep.

Timed Transactions

These are very similar to long-running transactions, except that you specify the time limit in advance. In other words, you specify the time interval that the transaction waits for a message from a trading partner or an application. If a message does not arrive within the interval specified, the transaction fails. To specify the time limit, you simply set the Timeout property of the transaction.

When a timeout occurs, the transaction aborts. However, the actions preceding the transaction aren't necessarily rolled back. You will need to specify explictly the actions that occur when a transaction fails. This issue is considered next.

When a Transaction Aborts

If you want to roll back a failed transaction, you must specify on the Compensation page what business process will undo the actions of the failed transaction. Similarly, if you want to handle the transaction failure within the process, use the On Failure page to specify the business process that will occur after the transaction fails.

Practice: Creating an XLANG Drawing that Uses Transaction Shapes

Exercise 1: Creating the Shapes of the Buy Air Ticket Business Process

First, you draw the part of the schedule that describes the Buy Air Ticket process.

To create the shapes of the Buy Air Ticket business process

1. In BizTalk Orchestration Designer, from the File menu, click New. The new drawing appears.
2. Click an Action shape in the Flowchart stencil and drag it to below the Begin shape. Right-click the Action shape and choose Properties. Type Find Seat in the Name text box, and then click OK. Don't connect shapes yet; you will do this later.
3. Drag a Decision shape from the Flowchart stencil to the position below the Find Seat Action shape. Right-click the Decision shape, and then choose Properties. Click Add. In the Rule Properties screen, type Seat Available, and then click OK twice.
4. Click the control handle at the bottom of the Find Seat Action shape, and then drag it to the entry point at the top of the Decision shape.
5. Click the Action shape in the Flowchart stencil and drag it to the right of and below the Decision shape. Right-click the Action shape, and then choose Properties. In the Name text box, type Book Seat, and then click OK.
6. Click the control handle to the right of the Seat Available rule, and drag it to the entry point at the top of the Book Seat Action shape.
7. Click the Abort shape on the Flowchart stencil and drag it to the left of and below the Decision shape. Click the control handle to the left of the Else clause of the Decision shape, and drag it to the Abort shape.

Exercise 2: Creating the Shapes of the Book Hotel Business Process

In this exercise, you draw the part of the schedule for the Book Hotel business process.

To create the shapes of the Book Hotel business process

1. Click the Action shape in the Flowchart stencil and drag it to the position below the Book Seat Action shape. Right-click the shape you just dragged, and then choose Properties. In the Name text box, type Find Hotel, and then click OK.
2. Drag a Decision shape from the Flowchart stencil and position it below the Find Hotel Action shape. Right-click the Decision shape and choose Properties. Click Add. In the Add Rule dialog box, verify that Create A New Rule is selected and click OK. In the Rule Properties dialog box, type Room Available, and then click OK twice. Connect Find Hotel with the Room Available decision shape.
3. Drag an Action shape to the position below and to the right of the Decision shape you just added. Name the action Book Room.
4. Click the control handle to the right of the Room Available rule, and drag it to the entry point at the top of the Book Room Action shape.
5. Click the Abort shape on the Flowchart stencil and drag it to the right and below the Decision shape. Click the control handle to the left of the Else clause of the Decision shape, and drag it to the Abort shape.
6. Click the Action shape in the Flowchart stencil and drag it to below the Book Room Action shape. Name this shape Process Payment. Do not connect it to anything yet; you will do that later.

Exercise 3: Creating the Outer Transaction

In this exercise, you create the outer transaction and set its properties.

To create the outer transaction

1. Click the TransAction shape in the Flowchart stencil and drag it to the work surface. Resize the shape so that it encompasses all the shapes in the work surface except for the Begin shape.
2. Right-click the Transaction shape and choose Properties. The Transaction Properties window appears.
3. In the Name text box, type Arrange Trip. In the Type area, click Long-Running. Click OK.
4. Click the control handle of the Begin shape and drag it to the entry point at the top of the Arrange Trip transaction.
5. Click the End shape in the Flowchart stencil and drag it below the transaction. Click the control handle at the bottom of the TransAction shape and drag it to the entry point of the End shape.

Exercise 4: Creating the Nested Transactions

In this exercise, you create the inner transactions and set their properties.

To create the nested transactions

1. Click the Transaction shape in the Flowchart stencil and drag it to the work surface. Position the shape inside and toward the upper edge of the Arrange Trip Transaction shape. Resize the Transaction shape so that it covers the Find Seat and Book Seat Action shapes, the Decision shape between these Action shapes, and the Abort shape attached to the Decision shape.
2. Right-click the Transaction shape you just resized and select Properties. The Transaction Properties dialog box appears.
3. In the Name text box, type Book Air Ticket. In the Type area, click Timed Transaction. In the Transaction Options area, set Timeout to 60, Retry Count to 3, and Backoff Time to 20. In the On Failure area, click Add Code, and then check the Enabled check box. Click OK. Notice that a new tab was created at the bottom of the work surface, labeled On Failure of Book Air Ticket. On this page, you will shortly specify the business process that will be executed if the transaction fails.
4. Now you add the other nested transaction. Click the Transaction shape in the Flowchart stencil and drag it to the inside of the Book Trip transaction just below the Buy Air Ticket transaction. Resize the transaction so that it covers the Find Hotel and Book Room Action shapes, the Decision shape between these two Action shapes, and the Abort shape connected to the Decision shape.
5. Right-click the Transaction shape you just resized and select Properties. In the Name text box, type Book Hotel. In the Type area, click Timed Transaction. Set Timeout to 60, Retry Count to 3, and Backoff Time to 20. In the On Failure area, click Add Code, and then check the Enabled check box. In the Compensation area, click Add Code, and then check the Enabled check box. Click OK.

Exercise 5: Connecting the Transactions

In this exercise, you connect the nested and the outer transactions.

To connect the transactions

1. Click the point you just connected to and drag it to the entry point of the Book Air Ticket transaction.
2. Click the control handle at the bottom of the Book Seat action and drag it to the exit point at the bottom of the Book Air Ticket transaction.
3. Click the point you just connected to and drag it to the entry point of the Book Hotel transaction.
4. Click the point you just connected to and drag it to the entry point of the Find Hotel action.
5. Click the control handle at the bottom of the Book Room action and drag it to the exit point of the Book Hotel transaction.
6. Click the point you just connected and drag it to the entry point of the Process Payment action.
7. Click the control handle at the bottom of the Process Payment action and drag it to the exit point of the Book Trip transaction.

Your drawing should now look similar to that shown in Figure 8.10.

Figure 8.10 The process for arranging a trip (Image unavailable)

Exercise 6: Creating Business Processes for Handling Transaction Failures

The drawing you created so far describes the flow that occurs when each transaction is successful. However, this might not always be the case. In this exercise, you will create a drawing that describes the business processing that needs to take place if a transaction fails.

To create business processes for handling transactions failures

1. Click the On Failure Of Book Air Ticket tab. On this page you will create a new XLANG drawing, which represents the actions to be taken after the Book Ticket transaction fails. Again, it makes no sense to book a hotel if you can't get there, so the outer transaction will have to be aborted. Click the Abort shape in the Flowchart stencil and drag it to below the Begin shape. Click the control handle at the bottom of the Begin shape and drag it to the entry point of the Abort shape. This ensures that if the Book Ticket transaction is aborted, the outer transaction also aborts.
2. Navigate to the On Failure Of Book Hotel business process page. Click the Abort shape in the Flowchart stencil and drag it to just below the Begin shape. Click the control handle at the bottom of the Begin shape and drag it to the entry point of the Abort shape. This ensures that if the Book Hotel transaction is aborted, the outer transaction also aborts.
3. Navigate to the Compensation For Book Hotel page. In this page, you design the business process that undoes the effect of the Book Seat transaction. Click the Action shape in the Flowchart stencil and drag it to below the Begin shape.
4. Right-click the Action shape, and then choose Properties. In the Name text box, type Release Seat, and then click OK. Click the control handle at the bottom of the Begin shape, and then drag it to the entry point at the top of the Release Seat shape.
5. Drag the End shape to below the Action shape. Click the control handle at the bottom of the Release Seat Action shape, and drag it to the entry point at the top of the End shape.
6. Save your drawing to your hard drive in the file Trip.skv.

Lesson Summary

The first step is to create an interaction diagram, which shows the roles participating in a workflow and the messages that the roles exchange. The next step is to analyze the documents and data formats to be exchanged. Once you know the details about the roles and the documents, you analyze, role by role, the actions each will perform and include the actions in the diagram. Next, you ensure that the roles can communicate with each other even when they reside on different computers. Finally, you compile, deploy, and execute your XLANG schedule.

Orchestration Designer uses a graphical language to express the ideas of sequencing, branching, and concurrency for the workflow. The language consists of shapes. In this lesson, you learned what shapes are available in the designer and how to use them. To design the workflow, you use the Flowchart shapes. You use the Implementation shapes to indicate how your XLANG schedule will interact with the outside world.

Orchestration designer uses nine Flowchart shapes: Begin, End, Abort, Decision, While, Fork, Join, and Transaction. For each shape, you can set properties that control how the shape processes the workflow that passes through it. The Begin shape is the exception because its properties affect the entire diagram.

Lesson 3: Specifying Data Flows

• Design the data flow for your XLANG diagram.

Estimated lesson time: 30 minutes

Creating and Configuring Ports

To obtain documents and to output them, XLANG schedules use ports. Therefore, to use an XLANG schedule, you must create and configure ports for input and output.

Creating and configuring ports for use with XLANG schedules is a two-step process. In the first step, you bind the port to a specific implementation technology. Four technologies are supported; hence you can use one of the four Implementation shapes, since each shape implements one technology. In the second step, you connect an action in the drawing with the port and define the schema for the documents that will be exchanged with the outside through the port. The schema specifies the records and fields of the documents you can use with the port you are creating.

Each step is performed by a different wizard. Therefore, two wizards are needed to configure a port.

Binding

When you drag an Implementation shape onto the work surface, the appropriate binding wizard starts. The role of the wizard is to bind the XLANG schedule to the implementation technology. To better understand how Orchestration Designer views ports, think of a port as a receptacle in which you can put messages, or from which you can pull them. The binding process specifies the properties of the receptacle.

Defining the Schema

The schema specifies the structure of an XML file, including the records and fields that the file contains. The schema you define for a port uses a document specification that must already exist. You can create your own document specifications or you can use predefined ones. For more information about document specifications, see Chapter 4.

When you define a schema for a port, the schema is available in the Data page of BizTalk Orchestration Designer. You can then use the schemas to define the movement of data from one action to the next.

Port Properties

When you create a port, you must specify several properties for it. Not all ports expose all properties. You configure a port using wizards, and so the appropriate wizard will guide you. Here are some of the properties you can configure:

• Name. Each port must have a unique name.
• Direction. The port can be configured either for sending or for receiving.
• Synchronicity. A port can be used for asynchronous or synchronous communication. However, you don't set this property; it is determined by the Implementation shape you use. This property is discussed in more detail later in this lesson.
• Static or dynamic communication. If you configure the port to be static, the component that implements the port will be instantiated by the XLANG Scheduler Engine. In contrast, for dynamic ports, the component will be instantiated by another application. For some components, you can also specify no instantiation. Such a port can be used only for receiving data, never for sending it.
• Security. This property allows you to specify if the identity of the sender should be confirmed. You can choose from three options: Not Required, Optional, or Required.
• Transaction Support. You can specify if the port supports transactions. The valid settings are Disabled, Not Supported, Supported, Required, and Requires New.

Using Implementation Shapes

BizTalk Server Orchestration Designer offers four Implementation shapes: COM Component, Script Component, Message Queuing, and BizTalk Messaging. Each shape is examined in the following sections, including a discussion of which shapes are used for synchronous and asynchronous communication.

COM Component

By placing this shape in your diagram you indicate that the port will be implemented using a method call of a component or application that already exists on your system. When you drag this shape onto your work surface, the COM Component Binding Wizard is launched. The port implemented by using this component is always synchronous.

Script Component

This shape indicates that the scripting component will be used to implement the port. Dragging this shape onto your work surface launches the Script Component Binding Wizard. The port implemented by using the scripting technology is synchronous.

Message Queuing

This shape is used for implementing a port using Message Queuing Services. Dragging it to the work surface launches the Message Queuing Binding Wizard. You can implement asynchronous communication using queues Thus the port will be asynchronous.

BizTalk Messaging

You can use this shape for implementing a port that uses BizTalk Messaging Services. Dragging this shape to the work surface launches BizTalk Messaging Binding Wizard. This is the second shape that implements asynchronous communication.

Synchronous and Asynchronous Communication

Two shapes, COM Component, and Script Component, implement synchronous communication. You need to use one of these for short-lived transactions. The remaining two shapes, Message Queueing and BizTalk Messaging, are used for asynchronous communication.

Synchronous and asynchronous communication differ significantly from each other, and if a messaging port is designed to support one mode you can't use it for the other. To understand why this is so, consider the events that occur in each type of communication.

When the XLANG schedule needs to send a message in the asynchronous mode, it puts the message into a BizTalk Messaging channel or a queue that you specified. There is no need to wait for any sort of response, so the schedule simply continues, as shown in Figure 8.11. In this figure, the processing is shown as a solid line, extending along the time axis shown at the bottom.

Figure 8.11 The asynchronous send (Image unavailable)

Similarly, when an asynchronous message is sent to an XLANG schedule, no waiting occurs on the part of the sending application. Of course, the XLANG schedule might need to wait if the message it expects has not been sent yet. Once the message arrives, the XLANG schedule moves to the next action. The asynchronous communication is shown in Figure 8.12.

Figure 8.12 The asynchronous receive (Image unavailable)

The processing is a bit more complex for synchronous communication, which might require a considerable amount of waiting. When an XLANG schedule is sending a synchronous message, it can't simply continue processing; it has to wait for a response, and can continue only after it receives it, as shown in Figure 8.13.

Figure 8.13 The synchronous send (Image unavailable)

Similarly, when the XLANG schedule expects a message, it must wait for the application to send a method request, intercept it, and then wait for the method response. When the response arrives, the schedule intercepts it, and only then can it continue. Synchronous communication is shown in Figure 8.14.

Figure 8.14 The synchronous receive (Image unavailable)

Clearly if you are implementing long-running processes, you can't afford to have your XLANG schedule actively wait for messages. For this reason, you don't use synchronous communication with such processes. Short-running processes can easily accommodate this communication model, and with those processes you use the COM Component and Script Component messaging ports.

Defining Data Flows

When you first create a new drawing, two messages are placed on the Data tab: Constants and Port References. Both are initially empty. As the name implies, the Constants message contains the constants you use in your drawing. You can add, update, and delete constants by right-clicking the Constants message, choosing Properties, and then clicking the appropriate button (Add, Edit, Delete). You specify the name, type, and value of a constant. At runtime, the Constants message is initialized for each XLANG schedule instance.

When you create a port, the entry for that port appears in the Port References message on the Data page. When you specify a schema for use in that port, the message for that schema also appears in the Data page. If you want to use a specific field of the document and pass it to some action, you configure the message so that the field shows in the message on the Data page. You then simply drag the field to the appropriate field in the message of the action where the field is needed. You can specify that the same message be sent to multiple actions. Be careful when you move the contents of a field in one message into a field of another message—type checking is not enforced.

Completing XLANG Drawings

Once your XLANG drawing is completed, you can compile it to create an XLANG schedule. The schedule can then be run. This is described in Lesson 4.

Practice: Using Implementation Shapes and Defining Data Flows

Before you perform this practice, you need to perform some preparatory steps. First, create a directory <drive>:\BTSTK\User, if you haven't already created it for a practice in an earlier chapter. Next, copy the files Echo.wsc and Copy.wsc from the \Samples\Chapter08 folder on the Supplemental Course Materials CD for this training kit onto your hard drive. The first file simply displays on the screen the message that the XLANG schedule instance is received. The second takes the message that was submitted and copies it to a file in the User directory.

Finally, if you did not perform the practices in Chapter 4, copy the file EnergyUsageSummarySpec.xml from the \Samples\Chapter05\Specs folder on the Supplemental Course Materials CD to a folder on your hard drive.

Exercise 1: Registering Components

Before you can use the script components, you must register them.

To register components

1. Navigate to the location where you stored the two .wsc files.
2. Right-click the Echo.wsc file, and then choose Register.
3. Repeat step 2 with the other .wsc file.

Exercise 2: Creating a Queue

Next, you create a queue that will be used with the messaging port you will create in Exercise 3.

To create a queue

1. From the Start menu, point to Programs, point to Administrative Tools, and then click Computer Management.
2. Expand Services and Applications, and then expand Message Queuing.
3. Click Private Queues. From the Action menu, point to New, and then choose Private Queue.
4. In the Queue Name dialog box, type ReceiveEUSummary, and then click the Transactional check box. Click OK. The queue .\private$\ReceiveEUSummary is created.
5. Close the Computer Management console.

Exercise 3: Creating a Port Using Message Queuing

You now create a port that uses the queue you just created.

To create a port using Message Queuing

1. In BizTalk Orchestration Designer, open the FabrikamProcess.skv drawing you saved in the practice you performed in Lesson 2. Alternatively, you can copy the file included on the companion CD to your hard drive and open it.
2. Click the Message Queuing shape in the Implementation stencil and draw it to the work surface so that it is level with the Receive Energy Usage Summary Action shape but still remains to the right of the separator bar. The Message Queuing Binding Wizard opens.
3. On the Welcome screen, click Create A New Port.
4. In the Create A New Port text box, type ReceiveEUSummary. Click Next.
5. In the Static Or Dynamic Queue Information screen, accept the default Static Queue, and then click Next.
6. In the Queue Information screen, click Use A Known Queue For All Instances. In the text box below, type .\private$\ReceiveEUSummary. Click Next.
7. In the Advanced Port Properties window, accept the default settings, and then click Finish.
8. The port appears, bridging the separator bar. You configure it next.

Exercise 4: Creating the Communication Flows for the Message Queuing Port

In this exercise, you run the XML Communication Wizard to create the communication flow.

To create the communication flows for the Message Queuing port

1. Click the control handle on the right of the Receive Energy Usage Summary Action shape and drag it to the left handle of theReceiveEUSummary port. The XML Communication Wizard starts.
2. In the Welcome screen, Click Receive. Leave the value of 0 intact, because we won't need to dehydrate this schedule. Click Next.
3. In the Message Information screen, click Create A New Message. In the Message Name text box, type EnergyUsageSummarySpec. Click Next.
4. In the XML Translation Information screen, click Receive XML Messages From The Queue. Click Next.
5. In the Message Type Information screen, type EnergyUsageSummarySpec in the Message Type text box. Click Next.
6. In the Message Specification Information screen, click Browse. Navigate to the location on your hard drive where you stored the EnergyUsageSummarySpec.xml specification, and then click Open.
7. In the Message Fields area, click Add.
8. In the Field Selection screen, expand the specification until you see UsageTotal field. Select it and click OK.
9. Click Finish.

Exercise 5: Creating a Port Using a Script Component

In this exercise, you will create a port that uses a scripting component you registered earlier.

To create a port using a script component

1. Click the Script Component shape in the Implementation stencil and drag it to the work surface so that it is level with the Echo Action shape but still remains to the right of the separator bar. The Script Component Binding Wizard opens.
2. In the Create A New Port text box, type EchoComponent. Click Next.
3. In the Static Or Dynamic Communication window, click Static. Click Next.
4. In the Specify The Script File window, click Browse. Navigate to the location to which you copied the file Echo.wsc, and then click Open. Click Next.
5. In the Component Instantiation Information window, click Use The Prog ID "BTSTK.Echo." Click Next.
6. In the Advanced Port Properties screen, accept the defaults, and then click Finish.
7. The port box appears, bridging the separator bar.

Exercise 6: Creating the Communication Flows For the Script Component Port

In this exercise, you run the Method Communication Wizard for the script component port you created in the previous exercise.

To create the communication flows for the script component port

1. Click the control handle on the right of the Echo Action shape and drag it to the left of the EchoComponent. The Method Communication Wizard starts.
2. On the Welcome screen, click Initiate A Synchronous Method Call. Click Next.
3. On the Message Information screen, accept the default Create A New Message option. Click Next.
4. On the Message Specification Information screen, select Echo from the Methods drop-down list. Click Finish.

Exercise 7: Creating Another Script Component and Port

In this exercise, you create a similar port to the one you just finished configuring, but using the Copy.wsc script.

To create another script component and port

1. Click the Script Component shape and drag it to the right of the Warning Action shape. The Script Component Binding Wizard opens.
2. In the Create A New Port text box, type CopyComponent. Click Next.
3. On the Static Or Dynamic Communication screen, click Static. Click Next.
4. On the Specify The Script File screen, click Browse. In the Select Script File dialog box, navigate to the location where you saved the .wsc files. Click Copy.wsc, and then click Open. Click Next.
5. On the Component Instantiation Information screen, click Use The Prog ID "BTSTK.Copy." Click Next.
6. On the Method Information screen, click Check All. Click Next.
7. On the Advanced Port Properties screen, accept the defaults, and then click Finish.
8. Click the control handle on the right of the Display Warning Action shape and drag it to the left of the CopyComponent. The Method Of Communication Wizard starts.
9. On the Welcome screen, click Initiate A Synchronous Method Call. Again, the script will not be dehydrated, so leave the default value for the wait time as is. Click Next.
10. On the Message Information screen, accept the default Create A New Message option. Click Next.
11. On the Message Specification Information screen, select Warning from the Methods drop-down list. Click Finish.
12. Click the control handle on the right of the Write Summary To File Action shape and drag it to the left of the CopyComponent. The Method Of Communication Wizard starts.
13. On the Welcome screen, click Initiate A Synchronous Method Call.

Click Next.

14. On the Message Information screen, click Create A New Message.

Click Next.

15. On the Message Specification Information screen, select WriteToFile from the Methods drop-down list. Click Finish.

Exercise 8: Specifying the Rule's Condition

In this exercise, you configure the Decision shape by specifying the rules.

To specify the rule's condition

1. In BizTalk Orchestration Designer, click the Data tab.
2. Verify that UsageTotal appears as a field of EnergyUsageSummarySpec message. You will use this field in the rule.
3. Right-click Constants and choose Properties. The Constants Message Properties window appears. Click Add.
4. In the Name text box, type Limit. In the Data Type drop-down list, select int. In the Value text box, type 5000. Click OK. The constant you defined appears in the Constants Message Properties window, as shown in Figure 8.15. Click OK.

Figure 8.15 Defining the constants for an XLANG schedule  (Image unavailable)

5. Click the Business Processes tab.
6. Right-click the Decision shape, and then choose Properties.
7. In the Decision Properties dialog box, click Over Limit, and then click Edit.
8. In the Rule Properties window, type the following in the Script Expression field: EnergyUsageSummarySpec.UsageTotal >. In the Expression Assistant area, verify that Constants appears in the Message drop-down list. Choose Limit from the Field drop-down list, and then click Insert. Click OK twice. Your diagram should look similar to that shown in Figure 8.16.

Figure 8.16 The XLANG diagram of Fabrikam Electric bill processing (Image unavailable)

Exercise 9: Defining the Data Flows

So far, you have created the diagram describing how the data flows through the business process. Now, you will specify which data is used.

To define the data flows

1. Click the Data tab.
2. Click the Document field of the EnergyUsageSummarySpec message. Click the control handle on the right of the EnergyUsageSummarySpec and drag it to the handle of the Document field in the Echo_in message.
3. Repeat step 2 with WriteToFile_in. Your Data page should look similar to that shown in Figure 8.17.

Figure 8.17 The data page showing the data flow (Image unavailable)

Lesson Summary

To implement ports, BizTalk Orchestration Designer offers four Implementation shapes: COM Component, Script Component, Message Queuing, and BizTalk Messaging. Each shape is used for implementing a port that uses the corresponding technology.

The drawings specify the order in which the actions will be performed, but they don't specify what messages are passed from one action to another. Therefore, you must specify the data movement on the Data page of the drawing.

Lesson 4: Compiling, Debugging, and Running XLANG Schedules

• Compile and run XLANG schedules.
• Monitor XLANG schedules.
• Debug XLANG schedules.

Estimated lesson time: 30 minutes

Compiling XLANG Drawings

1. From the File menu, choose Make XLANG <drawing name>.skx.
2. In the Save XLANG Schedule To dialog box, navigate to the location where you want your XLANG schedule to reside. You can also specify the name in the File Name list, or you can accept the default, which is the same as the name of your drawing.
3. Click Save.

That is all there is to it. The compiled XLANG schedule is an XML file. You can open it with any editor to examine its contents. You might be tempted to make changes to it because it might seem easier than recompiling. However, it is not recommended that you make any changes to your schedule directly in the .skx file. It is by far safer to make changes to your XLANG drawing and then recompile it.

Not all schedules compile perfectly. If you find that compiling your drawing generates a compile error, you must correct that error before you can proceed. Typically, the error will be displayed in a message box, and the border of the offending shape will be highlighted in light green.

Practice: Compiling an XLANG Drawing to Create a Schedule

To compile an XLANG drawing into an XLANG schedule

1. In BizTalk Orchestration Designer, with FabrikamProcess.skv drawing open, click File and select Make XLANG FabrikamProcess.skx
2. In the Save XLANG Schedule To dialog box, accept the default, and then click Save. The compiled XLANG schedule is saved in the same directory in which you saved the drawing.

Running XLANG Schedules

XLANG Scheduler Engine

When you install BizTalk Server, you also install XLANG Scheduler, the COM+ application that is a host to the running instances of XLANG schedules. It is also the host to the default XLANG Scheduler Engine. The engine in turn runs the XLANG schedule instances and controls all the actions that can be performed on them. This includes activation and execution of schedules, and if the schedules are long-running, it also controls dehydration and rehydration of the schedules as needed.

Each XLANG schedule can be accessed using a moniker. You can also use the moniker to create a new instance of the schedule, or to access a specific port in the new schedule instance. The moniker might include the full path to the compiled XLANG schedule. The XLANG Scheduler Engine creates monikers for each XLANG schedule instance it starts.

You can access these monikers within the schedule by connecting the appropriate message in the Port References shape with an appropriate field in a message that is to be sent. The field will then contain the moniker, and you can send the message to retrieve the moniker.

The XLANG Scheduler Engine accesses the XLANG schedule by using the schedule's moniker. The Scheduler Engine uses the schedule to determine and execute the next action to be performed. The actions are the same ones you define in your drawing, and they are performed in the sequence that the XLANG schedule defined. The engine also attempts to determine if the schedule needs to wait for the incoming message. If the wait is longer than 3 minutes, the schedule is dehydrated so that it doesn't waste resources. The schedule remains dehydrated until either the message arrives or the schedule is terminated by the administrator. The engine rehydrates the schedule when the message arrives, and the execution continues with the action receiving the message, after which the next action in the schedule is performed. The schedule then continues normally until it ends, is terminated, or needs to be dehydrated again. Because the information about the dehydrated schedules is stored in the Persistence database, this database must exist and be properly configured if you want to use this feature.

Integrating with BizTalk Messaging Services

You can integrate XLANG schedules with Messaging Services by using a specific transport for passing messages. You can use either a Hypertext Transfer Protocol (HTTP) transport or a non-HTTP transport. Either way, the most common scenario for this kind of integration is for the schedule instance to begin the interaction by sending out a message and then to wait for a response. The message can be sent either to another organization or to an application within your organization.

Debugging XLANG Schedules with XLANG Event Monitor

The XLANG Event Monitor, shown in Figure 8.18, monitors all the running XLANG schedule instances in real time. This way, you can see exactly how the instance is performing, and you can monitor all events occurring within that instance.

Figure 8.18 The XLANG Event Monitor (Image unavailable)

The States of Schedule Instances

By using XLANGMon, you can determine the state of each XLANG schedule instance. You can also change the state. A schedule can be in one of five states:

• Running. These instances are represented by green dots next to their names. Such schedules are in progress.
• Completed. These instances are represented by black dots. These are schedules that completed without any errors.
• Instances that encountered an error. These instances are represented by red dots.
• Dehydrated. These instances are represented by snowflakes. They are inactive, and the information about them is stored in the Persistence database.
• Suspended. These instances are represented by two blue vertical lines. Such instances have been suspended by a user action in the XLANGMon. Note that this state is different from the dehydrated state in that no data about the instance is stored in the Persistence database.

All schedules except for the completed ones reside in the Running folder. The completed schedules reside in the Completed folder. To view the contents of each folder, simply expand it.

In addition to the state of each schedule, you can see its name and GUID. The scheduler uses GUIDs to uniquely identify schedule instances. This way, multiple instances of the same schedule can run simultaneously.

You can change the state of a schedule instance by using the Instance menu. For example, you can suspend a running instance or resume a suspended one. You can also terminate instances this way.

Viewing Events

You can view all the events of a particular schedule instance that have completed running by double-clicking the instance in the Running or Completed folder, which opens the event window. The display consists of two parts. In the top portion of the window, you can see the sequence of events as they occurred, starting with the first event of the instance and ending at the most recent one. To view more details about a particular event, click it. The lower portion of the screen displays the details about the event, as shown in Figure 8.19.

Figure 8.19 Viewing schedule events (Image unavailable)

The events are described from the perspective of the schedule. And so, a sink corresponds to receiving data and a source corresponds to sending the data to the orchestration port.

For large and complex schedules, it might not be practical to view all the events just to find those that you are interested in. You can use filtering to quickly identify the events you want to know about. To specify which events you want to view, use the Events Filter option from the View menu. Follow these steps to specify the events you want to view:

1. Choose Events Filter from the View menu.
2. In the Events View Filtering dialog box similar to the one shown in Figure 8.20, click the events you want to view. If you want to view all events, click Check All. You can also specify to view all event data or all internal actions. If you are interested in specific events rather than in event types, expand the event type and check the event you want to view.

Figure 8.20 The Events View Filtering dialog box (Image unavailable)

Saving Events

XLANGMon is always in one of the two states: Recording or Not Recording. In the Recording state, you can save recorded events for viewing later. This is useful, for example, if you want to compare the events from different sources for schedules that run at different times. Follow these steps to save recorded events:

1. From the Recording menu, choose Stop Recording.
2. From the File menu, choose Save As.
3. In the Save Recording dialog box, specify where you want to save the recording, and identify the file name. The recording files have the extension .skt.
4. To start recording again, choose New Recording from the Recording menu.

Before you can view the events stored in a recording file, you must change the state of XLANGMon to Not Recording and then open the recording file.

Specifying Event Sources

When an XLANG schedule instance is invoked, its event sources are specified. However, in some cases, for example if you want to test that the schedule can be invoked by different components, you might want to change this. Follow these steps to change the event source for a particular instance:

1. Click the instance for which you want to change the event source.
2. From the Recording menu, choose Stop Recording.
3. From the Recording menu, choose Event Sources.
4. The Select Event Sources dialog box similar to that shown in Figure 8.21 appears. Make your selections by checking the appropriate check boxes.
5. From the Recording menu, choose New Recording.

Figure 8.21 The Select Event Sources dialog box (Image unavailable)

Practice: Using XLANGMon

To use XLANGMon

1. Copy the file RunXLANGSchedules.exe from the \Samples\Chapter08 folder on the Supplemental Course Materials CD to a folder on your hard drive. Copy two data files, EUSummaryOK.xml and EUSummaryOverLimit.xml, to the location where you saved the FabrikamProcess.skx file.
2. Run RunXLANGSchedules.exe.
3. Click the Browse button next to the Schedule File text box, and then navigate to FabrikamProcess.skx. Click the schedule file, and then click OK.
4. Click the Browse button next to the Data File text box, and then navigate to EUSummaryOK.xml. Click the data file, and then click OK.
5. Click Run XLANG Schedule Instance. Watch the file being echoed on the screen.
6. In Windows Explorer, navigate to <drive>:\Program Files\Microsoft BizTalk Server\SDK\XLANG Tools, where <drive> is the letter of the drive on which you installed BizTalk Server.
7. Double-click XLANGMon.exe. The XLANG Event Monitor window appears, as shown in Figure 8.22. At this point, the monitor should display one completed schedule instance.

Figure 8.22 The XLANG Event Monitor (Recording) window (Image unavailable)

8. Double-click the schedule instance to display its events.
9. From the Recording menu, choose Stop Recording.
10. From the File menu, choose Save As. In the Save Recording dialog box, save the recording in the file EUSummaryOK.skt.
11. From the Recording menu, choose New Recording. Notice that the window now no longer displays any information about the any schedule instances.
12. Repeat steps 4 through 8 with the file EUSummaryOverLimit.xml. You should now have two instances in the Completed folder.
13. Double-click each schedule instance to display its events.
14. Place the two Events windows side by side and compare the events of both schedules.

Lesson Summary

XLANGMon is a tool that allows you to monitor and debug XLANG schedules. It is a graphical interface that displays information about the state of each schedule instance. This tool also allows you to view events that occurred within that schedule instance.

Review

1. What are the advantages of business process orchestration?
2. What is an XLANG schedule?
3. Which Implementation shapes can you use for synchronous communication? For asynchronous communication? Why can't you use any component for any type of communication?
4. What are the steps in orchestrating a workflow?
5. What limitations does BizTalk Orchestration Designer impose on concurrent flows?
6. How can you represent decisions in an XLANG drawing? How do they differ?
7. What is dehydration?
8. A business process contains two transactions nested one inside the other. What happens if the inner transaction fails? Choose all possible answers.
1. The outer transaction is aborted.
2. The actions in the outer transaction are rolled back.
3. The outer transaction continues processing at the action immediately following the inner transaction.
4. The actions of the inner transaction are rolled back.
9. What is XLANGMon and how can you use it?