JBoss.org BPM Life Cycle

BPM Life Cycle: Execute

Drools Flow: BPMN2-based execution engine

The Business Process Model and Notation (BPMN) 2.0 specification is steadily moving forward on its way to become a great standard, and we are adopting it for our process modeling in Drools Flow. BPMN 2.0 not only defines a standard on how to graphically represent a business process (like BPMN 1.1), but now also includes execution semantics for the elements defined, and an XML format on how to store (and share) process definitions. Drools Flow currently supports the following BPMN 2.0 elements:

  • Flow objects
    • Activities
      • Script Task (Java or MVEL expression language)
      • (Abstract) Task
      • Service Task
      • User Task
      • Manual Task
      • Send Task
      • Receive Task
      • Business Rule Task
      • Reusable Sub-Process (Call Activity)
      • Embedded Sub-Process
      • AdHoc Sub-Process
      • AdHoc Sub-Process
    • Events
      • Start Event (None, Conditional, Message, Signal)
      • End Event (None, Terminate, Escalation, Error, Message, Signal)
      • Intermediate Catch Event (Timer, Conditional, Message, Signal)
      • Intermediate Throw Event (None, Escalation, Message, Signal)
      • Non-interrupting Boundary Event (Escalation, Timer)
      • Interrupting Boundary Event (Escalation, Error, Timer)
    • Gateways
      • Diverging
        • Exclusive (constraints using Java, MVEL or XPath expression language)
        • Inclusive (constraints using Java, MVEL or XPath expression language)
        • Parallel
      • Converging
        • Exclusive
        • Parallel
    • Lanes
  • Data
    • Java type language
    • Process properties
    • Sub-process properties
    • Activity properties
    • Data Object
  • Connecting objects
    • Sequence flow
  • Extensibility

For those that might not be familiar with the BPMN2 specification, this means that almost all activity types are currently supported (the transaction has not been implemented yet). Most of the event types are supported as well (cancel and compensation are the missing ones, and the aggregation of different types as multiple or parallel multiple), in all the various situations where they can be used (i.e. as start, intermediate or end event, boundary events, etc.).

There is still a list of issues to be resolved before we can claim full process execution compatibility with the BPMN2 specification, but the most used (and thus most important) process constructs are already supported. Thanks to our community support and contributions, we hope to complete this as soon as possible.

Persistence, transactions and events

Whenever a process is started, a process instance is created, which represents the execution of the process in that specific context. The process instance represents the current execution state in that specific context, and contains all the information related to that process instance. The runtime state of an executing process can be made persistent, for example, in a database. This allows to restore the state of execution of all running processes in case of unexpected failure, or to temporarily remove running instances from memory and restore them at some later time. Drools Flow allows you to plug in different persistence strategies.

Persistence is implemented as an orthogonal concern, which means persistence can (more) easily be changed according to the customers needs. The default implementation uses the Java Persistence API (JPA) to store the session state. The state of each process instance is stored separately as a (small) binary object (using a custom serialization mechanism) annotated with meta-information to simplify querying (one row per process instance). It also supports pluggable variable persistence (as user-defined data might need to be handled separately).

Whenever you do not provide transaction boundaries inside your application, the engine will automatically execute each method invocation on the engine in a separate transaction. If this behavior is acceptable, you don't need to do anything else. You can, however, also specify the transaction boundaries yourself, using user-defined transactions.

Rule integration

Rule integration into processes (and vice versa) is considered an important feature. When you're defining your business logic, not all information can easily be defined using process flow constructs. Similarly, when using business rules, some fragments of your business logic might more easily be expressed as a process flow. Drools Flow allows you to seamlessly combine processes and rules. This includes the ability to use rules in almost any part of your process, for example as constraint expression langauge. Rules can also be used to more easily handle exceptional situations, without ending up with an overly complex flow chart.

Process instance migration

Over time, processes may evolve, for example because the process itself needs to be improved, or due to changing requirements. Whenever a process is updated, it is important to determine what should happen to the already running process instances. There are various strategies one could consider for each running instance, like proceed, abort or transfer. By default, Drools Flow uses the proceed approach, meaning that multiple versions of the same process can be deployed, but existing process instances will simply continue executing based on the process definition that was used when starting the process instance.

Transfering a running process instance to a newer version so it uses the new process logic instead of the old one is simply a matter of changing the referenced process definition. However, this does not take into account that the state of the process instance (the variable instances and the node instances) might need to be migrated as well. In cases where the process is only extended and all existing wait states are kept, this is pretty straightforward, the runtime state of the process instance does not need to change at all. However, it is also possible that a more sofisticated mapping is necessary. Drools Flow provides a process instance migrator that allows you to migrate process instances to a newer version using a simple or more advanced mapping of runtime state.

WS-HumanTask service

Human tasks are an important part of a BPM solution. While some of the work performed in a process can be executed automatically, some tasks need to be executed with the interaction of human actors. This includes task lists for users, claiming and/or assigning tasks, etc.

The process engine itself is not tied to one specific, internal implementation but allows for other implementations to be plugged in. By default Drools Flow currently supports a WS-HT service as the default implementation. The life cycle as supported by the Human Task specification is shown below. Note that the WS-HT service also includes features like group assignment, escalation, assignment rules, etc.

Task client

A task client is the application that an end user uses to see all the tasks that are assigned to him/her, claim tasks, complete tasks, etc. Drools Flow provides a web-based implementation integrated in the BPM console and an Eclipse-based client for testing and demo purposes.

Template-based task forms

The web-based management console (see the "Monitor" life cycle phase) includes support for handling human tasks. It allows a user to see his/her current task list, including all the tasks that the user could claim and all tasks that are assigned to the current user. A custom task form can be associated with a task, so that it is shown to the user when completing the task. This form can request additional information needed for completing the task.

Different implementations of task forms could be provided. By default, the console uses FreeMarker templates. This allows you to define a form using standard HTML but also add dynamic information (like data relevant to that specific task using special tags.

The following screencast shows the web-based management console in action. Since the process contains some simple human tasks (and task forms), it also includes an overview of how task lists can be queried and how tasks can be completed using custom task forms.

Eclipse client

The Drools IDE contains a org.drools.eclipse.task plugin that allows you to test and/or debug processes using human tasks. In contains a Human Task View that can connect to a running task management component, request the relevant tasks for a particular user (i.e. the tasks where the user is either a potential owner or the tasks that the user already claimed and is executing). The life cycle of these tasks can then be executed, i.e. claiming or releasing a task, starting or stopping the execution of a task, completing a task, etc.