Screen Layout

-

-

Notes

-

Tom: Please add your name and comment below like this

-

Old Related Wiki Text

-

Managers can gain usefull insights in analisys and statistical data about process executions.  See also the old jira issue about BAM

Most common statistics are

• How much time is spend on average in each node of the process (to find bottlenecks)

• Average time per task per actor

• What is the average throughput

• What is the average concurrent running processes

• ...

1. Overview

The purpose of this document is to describe the requirements and a conceptual design for a Business Activity Monitoring component for jBPM.

A Business Activity Monitoring component would bring substantial additional value to jBPM customers. In particular, it would allow them to:

• Understand performance metrics

• Determine process failures

• Improve process performance

• Predict business activity levels

• Assist in business decision making

• Better manage resources

• Avoid degradation of service levels

BAM functionality can be developed using process and task data collected from jBPM, stored in a database schema designed for real-time querying, and accessed via a sophisticated dashboard.

In the future, Business Activity Monitoring will evolve to Business Activity Management. With Business Activity Management, the customer will be able to define activity management rules that will evaluate the incoming process and task data and generate alerts.

2. Information Requirements

Business Activity Monitoring supports real-time monitoring and collection of historical data. In this context, real time data is information about currently executing processes; historical data is information about processes that have completed. With the exception of the state of the process instance and the existence of a end date, there is little else that distinguishes real-time from historical data, thus we treat them the same except where noted.

Process monitoring should include:

Process Instance Summary Data - summary information on the total number of process instances executing grouped by various categories, e.g., processDefinitionName, start, status (active or completed), and other user specified properties.

The data should be displayable in both tabular and graphical representations (e.g., a pie chart). Statistical measures of time these process instances have been executing (e.g., min, max, and mean) should also be provided, as well as a process aging chart that shows the number of process instances by age for active processes and process completion chart that shows number of processes by duration for completed processes.

Multi-level grouping should be provided.

The user should be able to drill down from process instance summary data to process instance detail data, i.e., display all the process instances within the summary grouping.

Process Instance Detail Data - detail information on each executing process instances in tabular form. Information should include id, processDefinitionName, start, end, duration (end - start for completed process instances or current - start for active process instances) and other user-defined properties.

The user should be able to drill down from process instance detail data for a particular process instance to the task instance details.

Task monitoring should include:

Task Instance Summary Data - summary information on the total number of task instances contained in executing and completed process instances in each state:  created, started, overdue, completed). For completed task instances, this display should show the distribution (min, max, and mean) of completion times (end - create), processing times (end - start), and wait times (start - create). This data should also be groupable by name, pooledActorId and or swimlane, and actorId, as well as customer-defined groupings.

Task instance summary data should be represented in tabular and chart forms.

The user should be able to drill down from the task instance summary data to the task instance detail data, i.e., display all the task instances within the selected grouping.

Task Instance Detail Data - information on each task instance contained within an executing or completed process instance in tabular form. Information should include id, name, processInstanceId, state, create, start, end, actorId, pooledActorIds, swimlane, dueDate, cancelled, suspended, open, signaling, blocking, waitTime (start - create), processingTime (end - start), and completionTime (end - create), and other user-defined properties.

3. Presentation Requirements

The graphical user interface should be:

• web based

• rich in content

• tables

• expand/collapse rows

• hide columns

• fast scrolling

• graphs and charts

• drop downs, radio buttons, date pickers, etc. for selecting filtering / grouping

• drill down from one table to another

• dynamically updated as data changes without user interaction

• easily modified by customers to support customer-specified

• layout

• style

• attributes / columns

• filtering criteria

4. Reporting Requirements

Users should be able to create reports from their user interface. At the very least, reports should be output to Excel / OpenOffice.

5. Performance Requirements

Queries should return 100s of rows of data per second

The dashboard GUI should be capable of scrolling through hundreds of rows of data per second.

The application should support hundreds of logged on users, and scores of potential simultaneous requests.

Queries involving customer-specified properties should not perform any slower than the equivalent query without custom properties.

6. Conceptual Design

A conceptual design for the Business Activity Monitoring component could consist of the following components:

BAM Database - database tables that contain the process instance and task instance data. These tables should contain columns for each process instance and task instance attribute, as well as columns that are derived from other columns (e.g., the process instance table should contain a column for duration, where duration is end - start, and age, where age is current - start). Object relational mapping should be provided using Hibernate. Custom properties should be supported through the Hibernate subclass mapping facility.

BAMActionHandler - an ActionHandler that can be configured in the Graphical Process Designer at process, node, and task events, either at the process definition level or at each individual node or task. The BAMActionHandler gets the data from the jBPM objects, formats the data into a JMS XML Message, and sends the message to a JMS Queue. In a non-JMS environment the BAMActionHandler can directly call the BAM Data Insertion functionality.

Configuration of custom properties to capture should be definable by the user in the Graphical Process Designer

BAM Data Insertion Component - an MDB that subscribes to the queue, parses the XML message, and inserts or updates process instance and task instance data into the BAM Database. This component should be designed such that the last piece of functionality can be directly accessed via the BAMActionHandler.

BAM Query Component - uses Hibernate criteria API to construct queries on the fly. This component should provide an interface to the BAM Dashboard GUI that allows query parameters to be specified in a flexible, extensible, manner.

BAM Dashboard - a rich internet application that presents the BAM data to the end-user. The dashboard should be based on some open source rich internet application development tool, ideally with Eclipse plug-in for GUI design. (one candidate is Laszlo, http://www.openlaszlo.org/