XLANG Schedule Development
Chapter 11 and Chapter 13 delve into the runtime for XLANG schedules and into advanced use cases. This section augments the rest of the chapter and describes only the basic concepts and techniques to develop and run XLANG schedules.
The general sequence of developing an XLANG schedule is to design it using the XLANG designer, compile it, and finally run the schedule and optionally monitor it. The compiled form of the schedule uses an XML syntax for the file format. The compiled schedule is run by the XLANG Scheduler Engine.
The XLANG Scheduler Engine runs in a COM+ application, which is set up at BizTalk install time. You may create additional COM+ applications to host XLANG schedule instances, although the engine still runs in the original application. These additional applications provide process isolation for the running schedules.
The development and runtime activities for using BizTalk Orchestration are covered next.
Development
During development, you will probably try out many configurations of your business process. You might have to try out different components and organization for queues and messaging channels, along with many rules appropriate for use in your business process. At some point, when you have designed at least the core parts of your schedule, you need to compile it. The process of compilation also performs a consistency and validity check on the schedule drawing. The orchestration drawing file has the extension .skv; the compiled file has the extension .skx. You compile the drawing by using the menu option File, Make <DrawingName.skx>. Figure 10.25 shows the menu bar with the Tools menu expanded, which is described next. The File menu is visible but is not shown expanded.
Figure 10.25. BizTalk Orchestration Designer menu bar and Tools menu.
When going through design gyrations, it is not unusual to have ports or messages that you thought you needed but don't anymore. The Tools menu can be used to remove unused (and probably unwanted) ports, messages, and rules from your drawing. This is done by using the menu options Delete Unused Ports and Messages and Delete Unused Rules. While designing the schedule, you may also update your components, adding new methods or arguments. The Tools menu item in the designer allows you to look for updated method signatures for the components used in your drawing. This is done by using the menu item Refresh Method Signatures.
The last menu item under the Tools menu is useful. The XLANG Scheduler Engine caches the schedules when it is running. If you were to modify a schedule and then rerun it, the engine would run the cached version of the schedule unless you restart the engine. Hence, if you modify a schedule, you should use this menu item to Shut Down All Running XLANG Schedule Instances.
Each schedule has a distinct identity. You can see this identity in the properties for the Begin shape in the form of a GUID. Every time you make modifications to your schedule, this GUID identity changes. You can use this identity to correlate your drawing (the .skv file) with the compiled schedule (the .skx file), which is an XML text file.
Figure 10.26 shows the viewing options in the designer.
Figure 10.26. BizTalk Orchestration Designer viewing options.
By making appropriate selections on the menu, you can filter or augment the items you see in the designer. The first three menu options let you control which tabs are shown. You can switch between the Business Process or the Data tab by choosing the menu option or by clicking on the tab. You can optionally view both tabs at the same time—in this case, two windows are created and tiled horizontally to show each tab in its own window. The next set of menu options is used to filter the shapes shown on the drawing. You can optionally hide the ports or implementation shapes to reduce screen clutter depending on the task at hand. The stencils, too, can be hidden or shown. The stencil panes are normally docked; these can be optionally floated to free up more screen real estate for viewing. There is only one toolbar, and it cannot be changed.
The XLANG drawing can be zoomed using the toolbar buttons or zoom options, or you can use the menu options. The Pan and Zoom menu option opens a floating window containing a full page view in miniature with a marked rectangle depicting the area actually shown in the main window. You can drag the marked rectangle in the small floating window to pan and zoom in the main window. This is useful for navigating within a complex schedule where it might be necessary to zoom into specific areas of the schedule to work on it.
The remaining menu options allow you to display or hide the grid on the page and to show the page breaks if the schedule were to be printed.
Running XLANG Schedules: Using Monikers
This section describes how you run XLANG schedules. When BizTalk Orchestration is installed, it also installs the sked moniker class. This, in COM parlance, is a server that implements the IMoniker interface and provides the intelligence to bind names to object instances (see the side bar on this topic). The moniker class determines the structure of the name and how it is used to bind to an object instance. The sked moniker class provides this naming and binding service for the range of objects created by the XLANG Scheduler Engine. The moniker name has the following syntax:
Sked://[HostName][!GroupManager][/FilePath[/PortName]]
The optional components are enclosed in the [] brackets. The nested brackets indicate that the inner bracket is applicable only if the token in the outer bracket is specified. Table 10.5 describes the significance of each token.
| Token | Description |
|---|---|
| HostName | You can specify the computer on which the object is to be created or is already running. If this token is missing, then the local computer is assumed by default. |
| GroupManager | This is the name of the COM+ application to use to host the object. If this token is missing, then the default application of XLANG Scheduler is assumed. |
| If this and all subsequent tokens are missing, then a global object capable of enumerating currently defined group managers (COM+ applications) is instantiated. | |
| Note the ! used to separate this token and host name. | |
| FilePath | This is the path of the .skx file, which is the compiled XLANG schedule. |
| If this token is missing, then a group manager object is created that represents that COM+ host application. | |
| PortName | This is the name of the port bound to a COM component (not related to a messaging port) in the schedule. |
| If this token is missing, then the schedule object is instantiated. | |
| If this token is present, then a COM proxy to the port is instantiated. |
You can use the sked moniker class to instantiate a schedule. The following code fragment uses such a moniker to instantiate a schedule. This example starts the ExampleSchedule.skx schedule on the local system using the default group manager:
Dim oInst as COMRUNTIME.IWFWorkflowInstance
Set oInst = GetObject("sked:///C:TempExampleSchedule.skx")
The COMRUNTIME is a reference to the XLANG Scheduler Runtime Type Library. Of course, if you were to use VB Script, you wouldn't specify a type for oInst above.
Schedules may also be started by BizTalk Messaging on receipt of a message. To do this, a BizTalk messaging port must be appropriately configured to deliver the message to a new schedule instance. The messaging port references the schedule's port that will receive the message. See the section “BizTalk Messaging Binding Wizard” for information on setting up the port to receive messages. Also see Chapter 6 and Chapter 12, “Advanced BizTalk Messaging.”
Another option to start schedules is to use the XLANG monitor described in the section “Monitoring” later in the chapter.
Stopping XLANG Schedules
This section looks briefly at using the COM+ facilities and the XLANG Event Monitor to manage schedules. XLANG schedules are run by the engine, which runs in a COM+ application. It is possible for you to use the COM+ management console to shut down the application and hence any schedules running in that application; however, it is not advisable to do so for many reasons.
To properly shut down running XLANG schedules, either use the assigned button to perform this task (the button is on the XLANG tab of the properties of the COM+ application hosting XLANG schedules; for details, see Chapter 11), or use the Tools menu in the XLANG Orchestration Designer (see the section “Development” earlier in the chapter).
Shutting down running schedules does not terminate them; instead, the schedules get dehydrated to the persistence database. You can rehydrate them by using the button provided on the XLANG property page of the COM+ application. Running schedules can be terminated using the XLANG Event Monitor.
If you shut down the COM+ application running XLANG schedules or kill the process some other way, it leaves components that are not in the COM+ application still running, and the schedule state will not be properly captured for restart.
Monitoring
To monitor the operation of the XLANG schedules, you can use the Microsoft Management Console (MMC), the BizTalk Tracking Database, or the XLANG Event Monitor.
The XLANG Scheduler Engine posts events to the Application Error Log. You can view this log in the system's event viewer through the MMC.
A tool, called the XLANG Event Monitor, is provided with the product. This tool is described further in Chapter 11. This tool hooks into the events raised by the XLANG Scheduler Engine and into the persistence database for the schedules. You can use this tool to see which schedules are running and their current progress. The XLANG Event Monitor can also be used for starting new XLANG schedule instances by using the Run menu and typing in the schedule's moniker.
Besides the event log, one useful technique is to write a small COM component that can display a message box or write to the debugger using the Win32 call OutputDebugString. You can use the system debug monitor, DbMon, that comes with the Platform SDK to view the output from your test component.
You can also have your components generate log files or monitor the effects of running your schedules by looking for files being created or written or looking for messages archived in the tracking database.