- Shopping Bag ( 0 items )
Ships from: Farmerville, LA
Usually ships in 1-2 business days
Ships from: acton, MA
Usually ships in 1-2 business days
|About This Book|
|Ch. 1||Introducing Microsoft BizTalk Server 2000||1|
|Ch. 2||Deployment Considerations||37|
|Ch. 3||Installing Microsoft BizTalk Server 2000||65|
|Ch. 4||Creating and Managing Document Specifications||99|
|Ch. 5||Creating Maps Using BizTalk Mapper||145|
|Ch. 6||Configuring and Managing the Exchange of Business Documents Using BizTalk Messaging Services||199|
|Ch. 7||Submitting and Routing Documents||261|
|Ch. 8||BizTalk Orchestration||311|
|Ch. 9||Document Tracking||367|
|Ch. 10||Creating BizTalk Server Custom Components||407|
|Ch. 11||Managing BizTalk Server 2000||461|
|Ch. 12||Monitoring and Optimizing the Performance of BizTalk Server 2000||491|
|Ch. 13||Improving Security, Availability, and Fault Tolerance||523|
|Ch. 14||Troubleshooting BizTalk Server||559|
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.
Estimated lesson time: 30 minutes
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 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 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.
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.
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.
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.
Estimated lesson time: 30 minutes
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.
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:
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.
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.
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.
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
Figure 8.3 Creating a rule (Image unavailable)
Figure 8.4 Using the Decision shape (Image unavailable)
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.
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.
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 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).
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:
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.
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.
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.
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
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
Exercise 3: Creating the Outer Transaction
In this exercise, you create the outer transaction and set its properties.
To create the outer transaction
Exercise 4: Creating the Nested Transactions
In this exercise, you create the inner transactions and set their properties.
To create the nested transactions
Exercise 5: Connecting the Transactions
In this exercise, you connect the nested and the outer transactions.
To connect the transactions
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
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.
Estimated lesson time: 30 minutes
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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
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
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
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
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
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
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
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
Figure 8.15 Defining the constants for an XLANG schedule (Image unavailable)
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
Figure 8.17 The data page showing the data flow (Image unavailable)
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.
Estimated lesson time: 30 minutes
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.
To compile an XLANG drawing into an XLANG schedule
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.
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:
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.
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:
Figure 8.20 The Events View Filtering dialog box (Image unavailable)
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:
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:
Figure 8.21 The Select Event Sources dialog box (Image unavailable)
To use XLANGMon
Figure 8.22 The XLANG Event Monitor (Recording) window (Image unavailable)
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.