The Processes Page

This page contains an Instances widget that allows to navigate the upper part of the monitor model shown in Figure 1. The first view shows the Process Definition level and may look like Figure 4.

Figure 4: First view of the Processes page (basic dashboard configuration)

There will be one row for each process definition that has been deployed and sends events. If events have arrived from several process versions, then the last version detected will be shown in the second column and earlier versions can be seen by following the Process Version link. The Step Definition, Variable Definition, and Process Execution links navigate downward from the root of the tree structure in Figure 1. The counts before each link indicate how many children will be found. For example, there are 27 different steps defined in the ProcessCustomerOrder process, and 11 different variables; 5 executions of this process have started and all 5 have finished. Detailed information about the 27 step definitions, the 11 variable definitions and the 5 process executions can be found by following the drill-down links. For example, clicking on the first Step Definition link may take you to a view like Figure 5.

Figure 5: Drilling down to the Step Definition level (basic dashboard configuration)

One thing you see in Figure 5 is that the ProcessCustomerOrder process has run five times, but apparently not each of its steps has. Some steps, like InitializeResponseCounter, have run less than five times, because not all process runs follow the same path and steps are sometimes skipped. Other steps, like AskTheQuestion, have run more than five times because they are part of a loop. If you navigate to the Process Execution and then to the Process Execution Step level, you can see each step execution within a process run. Figure 6 for example shows an execution where AskTheQuestion ran three times in a row.

Figure 6: Drilling down to the Process Execution Step level (basic dashboard configuration)

Figure 6 also brings out a slight formatting problem: unlike in preceding screen shots, rows are now several characters high. The reason is that blanks in the date/time fields cause them to wrap around and occupy several lines. To allow for a terser display, those blanks have been replaced by underscores in the advanced dashboard configuration (and for the same reason the Version No Blanks metric is shown instead of the Version metric in Figure 4). For comparison, the advanced dashboard equivalent of Figure 6 is shown in Figure 7. You should feel free to configure these views to your liking, replacing the locally formatted date/time metrics by their "xs format" versions, adding / dropping / rearranging columns, etc.

Figure 7: Advanced dashboard view of Figure 6

The examples above should give you a flavor of the kind of information that is available on the Processes page of the preconfigured dashboards. To cover everything would take over a dozen additional screen shots—besides the descriptions of metrics which has not even been started. Therefore, in order to document every monitoring context view that has been configured for the sample dashboards, the exposition will now switch from sample screen shots to using much more succinct, tabular views.

In the following tables, each monitoring context visible on the Processes page is described with all of its metrics. The Monitoring Context column shows the name of the monitoring context definition, which typically desginates the type of the monitored entity (Process Definition, Process Execution, etc.). Note that in dashboard views the monitoring context name is somwhat hidden: you can find it by hovering over the (i) symbol in the upper left hand corner, as shown in Figure 8.

Figure 8: Hovering over the (i) symbol to see the name of a monitoring context definition

The Metric column contains the names of all metrics defined for a monitoring context (some of those "metrics" are actually counters or timers, but those implementation details are not of interest here). Short, generic names, like Name, Kind, State, etc. should be read in conjunction with the name of the monitoring context. In Figure 6 and Figure 7 for example, the Name, Kind, and State metrics hold the name, kind, and current state of a process execution step (as those figures show Process Execution Step MCs). As mentioned previously, metrics marked by (B) in the tables that follow are only shown on the basic dashboard, metrics marked by (A) are only shown on the advanced dashboard, and metrics without any marker are shown on both. The Description column contains a short description of the metric, which often suffices to explain its meaning. The Comment column provides additional explanations or cross-references. The presentation follows the order of Figure 3.

As already mentioned, a Process Definition monitoring context is instantiated for each process definition that sends audit events. If the same process definition is deployed at different servers, the different deployed copies will be distinguished by the Deployed At metric. If events arrive from several versions of a given process deployed at a given server, then the last version will be shown in the Version No Blanks metric while earlier versions and their life spans can be seen by following the Process Version drill-down. Note that the monitor model also defines a Version metric, which contains the unaltered, original version timestamp. Feel free to reconfigure the dashboard and show that instead of Version No Blanks.

The waiting (working) duration of a process execution is the sum of the waiting (working) durations of all human tasks within that execution, and any sub-processes it invoked, recursively. Note that in processes where human tasks run in parallel, their aggregate waiting (working) durations can exceed the total duration of the process execution.

The meaning of the remaining metrics should be clear from their descriptions.

The content of the Process Version monitoring context is largely self-explanatory: it represents a deployed version of a process definition. It records the earliest and latest audit event received for that process version, which are the best estimates available for its life span.

A Process Migration monitoring context represents two versions of a process definition between which instance migrations have occurred (that is, in-flight process executions have been migrated from the first version to the second). Process executions can be migrated from one version to the next at different points in time. These individual migrations are captured by a Process Execution Migration monitoring context, discussed below. A Process Migration monitoring context by contrast presents an aggregate view of these migrations: it shows a pair of process versions between which migrations have happened, when the first migration started, when the first migration ended, when the last migration started, and when the last migration ended.

A Variable Definition monitoring context represents a variable defined in a deployed process. It would be the logical place to hold aggregates (min/max/average values) of variable values. However, only numeric variables lend themselves to such aggregations, and from a technical standpoint this is inhibited by the "broken link" (red dashed line) in Figure 1: variable values are not monitored in child contexts of the one representing the variable definition, but such parent-child relationships are needed for metric-level aggregation. As a result, these monitoring contexts only hold a variable's name and no further information. (Type information could also be held here, but is not reported in the audit events sent by WebSphere Process Server.)

A Step Definition monitoring context represents a step (activity, task, scope, loop, etc.) defined in a process. Of course only steps that have run at least once and sent audit events are detected. A Step Definition monitoring context also holds statistical information about the step executions, like the minimum / maximum / average execution time etc.

A Step Execution monitoring context represents an execution of a process step (activity, task, scope, loop, etc.). Step executions can go through various states during their lifetime (ready, claimed, suspended, running, finished, ...) and perhaps the most important aspect tracked by this context is a step execution's state history (which is actually held in its State History child contexts, but those are mere auxiliary constructs for the lack of complex type / sequence support).

A [Step Execution] State History monitoring context records a timestamped state change of a running process step. The timestamp shows when this state was entered.

A [Step Execution] Potential Owners History monitoring context is instantiated as work items are created, deleted, refreshed, or transferred for a human task execution. Each instance records a new list of potential owners for the task execution.

A [Step Execution] Work Item Update History monitoring context, similarly to the [Step Execution] Potential Owners History monitoring context, is instantiated as work items are created, deleted, refreshed, transferred, or escalated for a human task execution. Each instance records a change that was made to the task's list of work items.

A [Step Execution] Escalation History monitoring context records an escalation of a human task execution.

A Process Execution monitoring context represents an execution of a process. It is instantiated as soon as the first event about a process execution is detected, and tracks the execution's state and progress until it is finished. A few more remarks may be in order:

• The Events metric and the Process Execution Event drill-down link are for process events (one-way messages) received by the monitored process execution. They are not to be confused with audit events, which the process execution sends to monitor. The latter are counted as well, but by the Audit Events metric.
• The Invocation Depth metric measures the depth of the call stack of a process execution. In determining the invocation depth, only process executions being monitored are considered (higher level executables that are not tracked by the Global Process Monitor are out of scope). A process execution for which no parent execution is known (unknown caller) is assigned invocation depth 0; its sub-processes are assigned invocation depth 1; their sub-processes are assigned invocation depth 2; and so on.
• The Initiator Identifier is the identifier of the top-level process execution (execution with invocation depth 0) that directly or indirectly invoked this execution. For top-level executions it is the identifier of that execution proper.
• The Caller Identifier is the identifier of the activity execution that called the current process execution (the identifier of the invokation step within the calling process).
• The Invocation Depth and Initiator Identifier can only be determined if at least one event is enabled for each BPEL invoke activity that performed a sub-process call.

A [Process Execution] State History monitoring context records a timestamped state change of a running process execution. The timestamp shows when this state was entered. The metrics are the same as for a [Step Execution] State History monitoring context.

A Process Execution Event monitoring context is created when a process event (one-way message) is received by an event handler of the process execution represented by its parent monitoring context. The monitoring context represents the arrival of the process event at the process execution, and its processing by either a scope-level event handler or a process-level event handler. Depending on the type of the event handler, only a subset of the metrics is populated as indicated in the Comment column.

A Process Execution Migration monitoring context is created when a running process execution is migrated from one process definition version to the next. The name of the process definition remains unchanged (Process Definition Name) but its version changes (Process Definition Version Migrated From → Process Definition Version Migrated To) as does its identifier (Process Definition Identifier Migrated From → Process Definition Identifier Migrated To).

A Process Execution Variable monitoring context is instantiated for each process variable (instance) that has been detected. It holds its current value and the time this value was set. A list of historical values is held in a child sequence of [Process Execution Variable] Value History monitoring contexts.

A [Process Execution Variable] Value History monitoring context holds a timestamped value (snapshot) of a process variable. It is instantiated each time a monitored process variable is changed, and initialized with the new value and the time when it was set.

A Process Execution Step monitoring context represents a step of a process execution (running activity, task, scope, loop, etc.). It monitors the same thing as a Step Execution monitoring context, and has a very similar set of metrics. The main difference between these two context types is their grouping:

• A Step Execution monitoring context is a child of the context representing its step definition. Drilling down from a Step Definition monitoring context to its Step Execution children will show all executions of this step at a glance, and allow to spot executions that ran for a very long time, have been escalated, ended in error, etc.
• A Process Execution Step monitoring context is a child of the context representing the process execution that this step was part of. Drilling down from a Process Execution monitoring context to its Process Execution Step children will show all steps that were part of this process run, give a rough idea of the process logic, allow to spot where most of the time was spent, etc.

For a description of the remaining four monitoring context definitions in Figure 3 please refer to the equivalent monitoring contexts already described above:

• A [Process Execution Step] State History monitoring context has the same metrics as a [Step Execution] State History monitoring context and the same descriptions apply.
• A [Process Execution Step] Potential Owners History monitoring context has the same metrics as a [Step Execution] Potential Owners History monitoring context and the same descriptions apply.
• A [Process Execution Step] Work Item Update History monitoring context has the same metrics as a [Step Execution] Work Item Update History monitoring context and the same descriptions apply.
• A [Process Execution Step] Escalation History monitoring context has the same metrics as a [Step Execution] Escalation History monitoring context and the same descriptions apply.

Finally, please note that all of the timestamped sequences captured in these auxiliary monitoring contexts are also available as string metrics. The dashboard can be configured to use these metrics instead of the drill-down links. How this might look is shown in Figure 9, which displays the same information as Figure 7 except that the State History information has been "pulled up" from a list of child monitoring contexts to a string metric and is shown at the same level as the remaining properties of the process execution steps. Obviously, Figure 7 makes more efficient us of the screen real estate than Figure 9, but Figure 9 gives a better first-glance view of each step's lifecycle.

Figure 9: The same information as in Figure 7 with the State History drill-down replaced by a string metric