Implementing Business Processes

This section shifts the focus from the business process itself to the technologies at your disposal to specify the implementation for the business process. The business process can be defined on all pages of the XLANG drawing, except the Data page. Stated another way, a business process can be described on pages labeled Business Process, On Failure of <Transaction>, and Compensation for <Transaction>.

In each of the pages containing a business process, the focus is on the right half of the page. A business process page is divided into two parts with a vertical pillar separating the two halves; this pillar is called the separator bar.

The process flow on the left of the separator bar (covered in Chapter 9) communicates with the implementation object on the right using messages. We briefly reviewed messages and the Data page in Chapter 9. A binding between an implementation shape on the right and an Action shape on the left is made via Port shapes located in the middle separator bar.

Let's look at a specific example so that you can see concretely all the things we will discuss at length. The chosen example is the XLANG schedule drawing from the tutorial sample Buyer1.skv installed by default at Program FilesMicrosoft BizTalk ServerTutorialScheduleSolutionBuyer1.skv. It is shown in Figure 10.1. The actual path to the sample depends on your installation. You may also open the drawing yourself, follow along the discussion, and explore different parts of the drawing.

A port is created when you drag an implementation shape from the stencil on to the drawing surface. A wizard specific to the implementation guides you through the configuration steps (these wizards are described in the section “Wizards for Port Implementations” later in the chapter). You can restart this wizard by double-clicking on the implementation object. Messages are created when you connect an Action shape with a port. Either an XML or a method communication wizard is started to guide you through the configuration steps (these wizards are described in the section “Defining Data Flow Through Messages” later in the chapter). You can restart the wizard by double-clicking on the connection between the action and the port.

When a schedule is compiled and run, a sequence of actions as described by the business process is performed. With each action, a message is either sent or received through a port. The XLANG schedule drawing pictorially shows the actions, messages, and ports and their interrelationships. This background should assist you to explore the sample shown in Figure 10.1.

In Figure 10.1, the rectangular boxes sitting on the separator bar are ports. The ports are named ReceivePORequest and ApprovalComponent. The messages that flow through these ports are shown as rectangular boxes enclosed by the Port shape and are named as displayed in the box representing the Port shape. The port on the top has a single message associated with it, called POReq. The port on the bottom has three message pairs associated with it. The boxes representing message pairs are always grouped within the port shape. The names for the message pair contain tags _in and _out to differentiate the incoming and the outgoing messages. For example, the messages in the first message pair inside the ApprovalComponent port are called SendDenial_in and SendDenial_out, respectively. These messages are shown on the Data page (see Figure 10.2) where you specify the data flow.

The arrows connecting the message with the Action shape depict the direction of flow for the message. If you see the drawing in color, the red arrow is always going out from an Action shape, and the blue arrow is always going into an Action shape. The arrows indicate whether a message is flowing out of a schedule instance or into a schedule instance.

The shapes to the right of the separator bar represent the implementation bound to a port. Figure 10.1 shows two implementation shapes. The top shape is for an MSMQ queue named .private$ReceivePOReq. The lower shape is for a COM component built using the Windows Script Component technology. The shape contains three lines of annotation, the first one says that the component is implemented in the file PORequestApproval.wsc. The second line shows that the PORequestApproval interface is being used. The last line shows that it implements the ProgID of BTSTutorial.PORequestApproval. This interface used in the implementation exposes three functions shown to the left of the implementation shape. The functions exposed are named WriteToFile, SendDenial, and SendApproval.

The BizTalk Orchestration Designer creates a message definition when you connect an Action shape with a port. If the connected port represents a messaging-based implementation, like the MSMQ-based ReceivePORequest port on the top, then a single message is created, like the POReq message on top. In addition, the connection between the Action shape and port is a single arrow. On the other hand, if the connected port represents a COM component, like the script-based port ApprovalComponent at the bottom, then a message pair is created, like SendDenial_in and SendDenial_out. You will notice that the names for the messages in the message pair are derived from the function name associated with the message pair. The messages in the message pair are used for passing the function's arguments and its results. In this case, two arrows connect the Action and the port, one for each message in the message pair.

Message pair names may have an additional numeric suffix. This suffix is generated when two or more Action shapes call the same function on a component. The numeric suffix is used to disambiguate the messages and the calling context when calling the same named method at different points in an XLANG schedule. Note that such Action shapes that use the named method may lie on any process page (that is, any page other than the Data page) in the schedule.

A message pair is always used when communicating with a COM component. On the other hand, a single message is used when communicating with a port connected to an MSMQ queue or a BizTalk channel. The message pair represents the call and the return of a synchronous method call. The single message represents the asynchronous delivery or receipt of a message. The direction of the top arrow is significant where a pair of arrows connect an Action to a port. The top arrow indicates the origination of the method call. In the figure, all calls are shown to originate from the XLANG schedule instance. Later, in the section “Message Flow Behavior,” you see calls originating from outside the schedule. In these situations, the top arrow goes from right to left and is colored blue when a call is initiated from outside a schedule.

When the schedule shown in Figure 10.1 runs, actions are executed starting from the Begin shape. As each action is executed, the associated messages are either received or sent. For example, the Receive PO Request action waits for the POReq message from the port ReceivePORequest. Some actions may not be executed—for example, only one of the actions Send Denial or Send Approval will execute. When an action is not performed, the associated message exchange does not occur.

Looking to the right of the separator bar and to the implementation shapes, there are two kinds of implementations. One kind uses the programmatic calls to COM-based components to exchange messages, and the other kind uses queue-based mechanisms implemented by messaging-based ports to exchange messages with XLANG schedules. The schedule described in Figure 10.1 shows one of each kind. A COM-based component may be a registered DLL or a script. A queuing-based component may be an MSMQ queue or a channel from BizTalk Messaging Services. Note that the messages here are the packets of data being exchanged as actions are executed within the XLANG schedule; these messages are not flowing through BizTalk messaging services.

A component is used in a schedule by calling a method that the component implements. From the discussion of Figure 10.1, you know that each component call involves a set of paired messages exchanged synchronously. One message represents incoming data (arguments) in the call; the other represents outgoing data (results) from the call return. You can implement a component using any language capable of authoring COM components; this includes Visual Basic, C++, or Windows Script Component technology (as shown in Figure 10.1).

A queue-based mechanism is used in a schedule by posting a message to it or by retrieving a message from it. This message exchange occurs asynchronously—the sender and the receiver of a message do not block one another when they exchange a message or a response. To implement such a port, you either use queues from MSMQ or use channels from BizTalk Messaging Services. A BizTalk channel, which is described in Chapter 6, is just like a queue when it comes to sending messages—although the actual feature set is extensive. Messages are received from BizTalk Messaging Services by an XLANG schedule via a port bound to a channel.

In the BizTalk Orchestration Designer, there are four shapes in the implementation stencil; each shape corresponds to a supported technology. Usually, this stencil pane docks to the right, but it may be docked to any edge or floated. These shapes are shown and briefly described in Table 10.1.

Table 10.1. Port Implementation Technologies

Shape	Description
	COM Component
	Script Component
	Message Queuing
	BizTalk Messaging

Now we'll round out the discussion of the tutorial example introduced in Figure 10.1. Figure 10.2 shows the Data page corresponding to the Business Process page shown in Figure 10.1. You might want to review the business process and ports described earlier.

Figure 10.2 shows the messages automatically created when an Action shape was connected to a port on the Business Process page. The interconnections between the message shapes are not automatically created. Each rectangle represents a message or a message pair. You should be able to correlate each rectangle, other than the ones labeled Port References and Constants, with a message on the Business Process page. If you can see the color, the name of the message shows up inside a blue-gray heading in each rectangle. The table below the heading contains specific fields of the message. The shaded, yellow-orange fields are the system fields, and these are listed first. Note that the __Sender__ field is always present in any incoming message. For message pairs, which represent COM method calls, the call return part of the message always contains the __Status__ field, which contains the HRESULT for the call. The other fields inside the rectangle are specific to the message. Messages and fields are described further in the section “Defining Data Flow Through Messages.”

The arrows connecting the message shapes show the possible movement of data among the messages. The data movement in Figure 10.2 is simple; the incoming document in the Document field of the POReq message can potentially be copied to any of the other messages associated with a method call. The actual movement of data is governed by the business process flow. The data movement does not occur until the action associated with the message flow is executed in the flow. Hence, depending on how the business process actually unfolds, either the SendDenial_in message field is populated with the document string or the SendApproval_in message field is populated, but not both.

There are no Constants in this drawing shown in Figure 10.2. The Port References are one each for the two ports implemented on the Business Process page.

The descriptions so far of the Business Process and the Data pages of the tutorial example should provide a good outline of all the basic pieces of a schedule as shown in the BizTalk Orchestration Designer.

We now return to review each of the port implementation technologies. In addition, later, we look at how the technologies are used to bind an implementation to a port and discuss further details about message handling.