Developers of workflow-based applications with the Business Process Modeler (BPM) component of BEA WebLogic Integration Version 7 use a powerful, feature-rich, graphical editor, called Studio, to design workflow templates and to monitor the progress and state of runtime instances of templates.

As Figure 1 shows, Studio is an online tool: it calls the WebLogic Integration server application to retrieve information about workflows or to commit changes. This information is ultimately stored in a database; internally, much of what the WLI application does is converse with the database.

But what if the server goes down? Studio is rendered inoperative. Developers and other users can no longer monitor workflows; no such tools are provided with WebLogic Integration. The obvious solution is to look directly in the database for relevant workflow information. But the Integration database is unintelligible to most users: even if you understand the table structure, you still have to contend with the fact that most of the critical information in the tables is hidden in binary fields, which only WebLogic Integration knows how to interpret. You cannot glean much from exploring the database in your favorite SQL editor.

The solution is a new tool, called BPM Offline Viewer, which queries the database directly and unearths the critical information, thanks to its inside knowledge of the layout of WebLogic Integration data (see Figure 2).

Why Is an Offline Viewer Important?
When BPM is used in an enterprise project, it is often one of the most important pieces of the architecture. Workflow, the key entity of BPM, is often referred to as a "choreographer" of human and external system actors, coordinating their activities in a formal business process, and making something coherent from it all. There are plenty of stakeholders who care about, and want to be able to track, workflows in flight. If the server is down, the stakeholders still need to query workflows. The data is important because:
1.  The information is valuable in its own right from a business point of view, and should be visible whether or not the server is up.
2.  If the server has crashed, the information might provide clues to why, like a "black box" for a doomed aircraft.
3.  If the server is unstable and cannot be restarted, knowing the state of the workflows enables the business to continue the processes by alternate means, such as manually.

About BPM Data
Of the many tables that constitute the BEA WebLogic Integration data model, three hold all of the information pertinent to workflow templates and instances (see Figure 3).

The design of a workflow (i.e., the logical sequence of steps developed in BPM Studio) is held in the tables TEMPLATEDEFINITION and TEMPLATE. A template, identified by a unique name and ID (NAME and TEMPLATEID fields, respectively), can have zero or more template definitions. Normally a template has one definition, but having multiple definitions is useful for versioning. For example, a template might have two definitions, only one of which is active. If there are any instances of the inactive definition, they will run to completion under that version, but new instances will run against the active definition. The actual "source code" of the workflow is held in the DATA field of the template definition table, though it is entangled with other control data. The DATA field is a binary type (a LONG RAW type in Oracle) containing serialized Java objects, one of which is an XML document representing the source code.

Runtime instances of a workflow are captured in the INSTANCE table. Most of the important state information (such as the values of workflow variables and the state of workflow tasks) is contained in the DATA field, which again is a binary stream of serialized Java objects.

Knowing how to read and interpret the contents of these binary data fields requires knowing how they were assembled in the first place - in other words knowing how, in the bowels of WebLogic Integration data is persisted to the database. Without divulging any product secrets, Listing 1 shows how, generically, to read one of these fields.

The data, stored in memory as a byte array, is fed into a standard Java ObjectInputStream (Listing 1, line 9). Objects - representing template definition source code, instance variables, runtime task state and other information - are then read from the stream one by one (lines 12-15). Of course, the objects are of no use unless you know what they are and what they are for. You must know:

1. How many objects are in the stream
2. The order of objects in the stream
3. What each object is

Code like this is at the heart of the BPM offline viewer tool.

Tools
The offline viewer consists of three tools:

Report Generator: A command-line tool that generates an HTML report for one of the viewers above. The inputs are the file names of an XSL and XML document. The output is an HTML document, which can be shown in a browser.

Template Viewer Tool
The template viewer tool prints out information about a workflow template and each of its definitions. In BPM Studio, the equivalent information is presented on a design canvas, as shown in Figure 4.

 

The XML generated by the tool is lengthy and tedious, but when fed through the report generator it is useful and informative (see Figure 5).

 

The template viewer tool is called with the following command line:

java com.bea.tools.OfflineTemplateDetail $DBDRIVER $DBURL $DBUID $DBPWD -t $TID $FILE

The parameters are:

Template Definition XML, which is the source code of the definition in XML form

Instance Viewer Tool
The instance viewer tool prints out information about an instance of a workflow template, notably the values of its variables and the status of its tasks. Figure 6 shows BPM Studio's online view of a workflow instance:

 

The tool generates XML that is, as in the case of the template viewer, overwhelmingly detailed. But the report generator saves the day with the HTML view shown in Figure 7.

 

The instance viewer tool is called with the following command line:

java com.bea.tools.OfflineWorkflowDetail $DBDRIVER $DBURL $DBUID $DBPWD $WFID $FILE

The parameters are the following: