View source | View content page | Page history | Printable version   






The goal of this development is to embed/integrate a BPM engine within the Openbravo application. There are several bpm solutions available. The first action of this project should be to choose an open source BPM solution which to use as a solution. Two main solutions are clear candidates:

The choice has been made to use and integrate with Activiti as it can easily be embedded within the Openbravo webapp.


Videos showing an example of a work flow implementation for dunning including configuring the work flow system:

Development Project

Feature overview

A summary of the planned work flow integration features:

Status Overview (Feb 2012)

The current status (Feb 2012), activiti has been integrated within the Openbravo app:

Bpm workflow administration.png

Bpm workflow definition.png

Bpm task view.png

The main open topics are:

Development Steps

The implementation steps (with their status):



This feature development is tracked using the following issue(s): to-be-added


This section discusses the detailed design of the work flow integration of Openbravo with Activiti. It combines both the existing functionality as planned new functionality.

The work flow integration makes it possible to define work flows in Openbravo, start work flows, get an overview of current tasks, visualize which work flows are available for a certain record/object, and in which work flows a certain record/object is the main subject.

Data/Object Oriented Work Flow integration

Linking work flow definitions to window/tabs

The idea is that a work flow is enabled/available for a certain tab. So when defining work flows in Openbravo it is possible to specify for which tabs this work flow should be available.

The tab-work flow link should also allow to define an expression which specifies if a certain work flow is valid for a certain record. For example, an expression like e.orderQuantity > 0 defines that a work flow is only available for a sales order line with an order quantity larger than 0. This expression is executed on the client, it should be possible to use other javascript (global) objects in this expression.

The work flow tab link should also define if a work flow may be started once or multiple times for a certain record.

Visualization of available work flows in a tab

The link of a work flow definition with a tab is visualized as follows in the target window/tab:

Bpm window workflow.png

Bpm window flyout.png

Current work flows for a record

When a record is selected then the fly out will also show an option to show all the current work flows in which a record currently participates.

Bpm workflow section.png

When the user selects this option then a section in the form is opened which lists (in a grid) all the current work flows in which a record is the main subject. For each work flow the following information is displayed:

User Oriented Work Flow Integration

The previous section discusses how work flows relate to data in the system. This section focuses on the user oriented part of the work flow integration.

The user oriented approach is visualized in different ways:

Task View

The task view is currently available as part of the Activiti integration. It shows the current list of tasks assigned to a user and the tasks assigned to the group of the user, which the user can claim.

Bpm task view.png

From the task view the user can also see the current location in the work flow:

Bpm task view current location.png

The functionality of the task view has to be extended in several ways:

These actions can be made available on the task list using a right-mouse button click on the task. Both actions should be executed after first confirming with the user.

Work flow button in each window/tab

If the work flow module is installed then in each window there is a work flow button which shows a flyout (see also the data-oriented work flow integration above). The flyout can show the current list of tasks assigned to the user, by clicking on a task the task specific user interface is opened for that task (see next section).

Task specific user interface

The current prototype allows the work flow to define a target window/tab for a user task. In the task view list this is visualized as a link which opens the window/tab for the selected record. When the user clicks that link the openbravo window/tab is opened for that record, this is a standard openbravo window/tab with all the available functionality enabled.

This is fine for an initial approach, however the main drawback of the current approach is that the user can perform any action on the opened window/tab: delete, edit, click buttons etc. Also it is not clear/defined which of these action accomplishes/finishes the task. So the user needs, as an extra step, to click a button to tell the system that a certain task is finished.

To solve this there are 2 solutions possible:

For the second option we can re-use most/all of the window/tab definition in the Application Dictionary and also re-use large parts of the client and server code. Imv the second approach is the prefered approach, both approaches can also be implemented together.

Defining Work Flows within the Openbravo UI

The initial/current implementation (Febr 2012) allows you to define work flows as XML within Openbravo.

Bpm workflow definition.png

There are 2 options for defining work flows in Openbravo in a more detailed way than xml:

The second approach is the preferred approach, to allow graphical editing of work flows through the web browser/Openbravo user interface. It should be possible to refer to Openbravo Application Dictionary components (window/tabs) from within the graphical editor.


The system should define that a user is allowed to start work flows or even stop/delete an work flow instance.

The idea is to add a Role Work Flow table which defines for a combination of role and work flow definition that a work flow maybe started or stopped by that user.

The user interface discussed in previous sections should take these authorizations into consideration.

Starting work flows from alerts

The idea is that a work flow could also be started automatically based on an alert. To accomplish this the alert rule should have a reference to a work flow definition. If an alert is created for that alert rule then this work flow is started.

To implement this functionality, probably the alert generation mechanism needs to be made extensible. Or another approach is to have a separate process running, just after generating alerts. This separate process iterates over all non-solved/non-ignored alerts and if the alert rule has a work flow link, start the work flow.

The target record/tab of the alert can be used as the target of the work flow.

Administrative User Interface

The System Administrator has direct access to the Activiti Explorer UI which will be opened in a separate tab. The Activiti Explorer UI is available as the Work Flow Administration menu option.

Bpm workflow administration.png


Retrieved from ""

This page has been accessed 15,085 times. This page was last modified on 23 November 2015, at 08:37. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.