Nova Bonita documentation

States for package: UNDEPLOYED, DEPLOYED

States for process: UNDEPLOYED, DEPLOYED

Deployment of processes implies deployment of a package. Same thing for the undeployment. Package can be deployed and undeployed several times in order to make modifications onto its contained elements (process, participants, activities, ...). This is the way to maintain processes before the introduction of versionning in next version.

See the developpement guide for more details.

States for process instance: INITIAL, STARTED, FINISHED

No difference with bonita v3.

CANCELED state is not yet supported.

Activity has no state (oly started and finshed date). Notion of state at this level depends only on the type of behavior defined within the activity. A specific body of the activity is created according the type of the activity (Task, Subflow, Route, Automatic). The state is implemented by the body. At now only task has a life cycle.

States for task: INITIAL, READY, EXECUTING, SUSPENDED, FINISHED, CANCELED

State SUSPENDED has been introduced. This state can be reached either from READY or from EXECUTING. transition is also reciproque.

Tasks are particular types of activities (such subflow, route...) associated to human actors.

Xpdl definition of hooks has changed in order to extend rollbacking capabilities to all hook types making by the way the usage of hook simpler. An example of the new one is given here after

<ExtendedAttribute Name="hook" Value="org.ow2.bonita.integration.hook.OnReadyHook">
  <HookEventName>task:onReady</HookEventName>
  <rollback>false</rollback>
</ExtendedAttribute>

The element rollback has been introduced to indicate if the hook will be or not rollbacked.

Hook events have also been adapted to match the constraints of task life cycle.

Main change is the suppression of before/after for terminate and before/after start types because of the introduction of the rollback parameter. An other change is the introduction of new events due to the new state: SUSPENDED.

Note: if using proEd, the designer can select for each hook:

Hooks are always executed into a transaction. In case1, if an exception has occured the exception is raised by the engine and the transaction is rollbacked. In case2, the occuring exception is catched by the engine.

To implement a hook class the developper has the choice between two interfaces. Look at the javadoc of these interfaces for more details:

If rollback=false has been previously defined, only Hook interface can be implemented otherwise an exception is raised at runtime. Then it prevents the use of TxHook interface. These hooks are intended to execute not critical operations for the workflow. Only query API are proposed to be acceeded into the parameters of the execute() method of the interface.

If modification on hook class is required it can be hot deployed to replace the previous one (see the ManagementAPI). It can be also deployed within the bar archive or independendtly. It can be also undeployed if the class is not required by a deployed process.

One type of event can be defined.

ON_INSTANTIATE hook (set within the process element of XPDL definition) is not yet supported.

ON_CANCELLED hook is not yet supported.

Interactive hooks (also called Bean Shell) are not yet supported for activity and process. Those hooks will be implemented soon adding support for others scripting languages such Groovy

To integrate Nova Bonita in your application you only need to add a couple of libraries to your environment.

The following ones are the only required by Nova Bonita:

bonita.jar
pvm.jar
bsh.jar
novaBpmIdentity.jar
novaBpmUtil.jar
xstream.jar

hibernate3.jar
dom4j.jar
commons-logging.jar
commons-collections.jar
hsqldb.jar
cglib.jar
antlr.jar
asm.jar
asm-attrs.jar
jboss-j2ee.jar

Move to the Nova Bonita installation directory and:

Persistence is one of key technical services injected into the services container. This service, as well as other major services in Nova Bonita, is based on a service interface. That means that multiple persistence implementations can be plugged on top.

The Persistence service interface (called DbSession) is responsible to save and load objects from a relational database. By default, a persistence implementation based on the Hibernate ORM framework (called HibernateDbSession) is provided (JPA and JCR to come).

The Process Virtual Machine core definition and execution elements (processes, nodes, transitions, events, actions, variables and executions) as well as the XPDL extension ones (join, split, manual and automatic activities, conditions, variables...) are persisted through this service. Process Virtual Machine core elements are also cached by leveraging the default persistence service implementation (Hibernate based). Workflow packages, processes, instances, tasks and advanced classes (such hooks or mappers) are are stored through this persistence service. Workflow repository is the term used in Nova Bonita to store those entities.

Identity service main objective is to give freedom to system administrators to leverage your organization user repository. Traditional user repositories such LDAP, ActiveDirectory as well as any other user repository (database or API) can be plugged as implementations of this service.

By default, some user repositories implementations are provided for testing purposes: in memory, basic FileSystem based persistence, and basic database persistence (based on a predefined database schema). Those implementations can also be used in production if there is no other user repository available.

The Identity service is so an extensible interface (known as IdentityServiceOp) build around three main concepts: Users, Groups and Memberships:

Both Security and Human Task services will use the Identity one by checking user login/password and user rights (Security) and by resolving workflow logical roles with users and so to assign manual activities to users based on some hierarchical information (Tasks Management)

By default, Nova Bonitais packaged with a test based identity module based on a properties file. This file contains the user/login allowed to reach Nova Bonita APIs. This properties file is in fact a Test Login Module (see security module description below), meaning that the same properties file is used for security and identity configuration.

The security service is based on JAAS standard. Main purpose of this service is to provide both authentication and authorization capabilities to the workflow engine. As security directly relates to users permissions, this service also relates to the identity one (commonly security is based on top of the identity service).

As for other services, the Nova Bonita team is concerned on let you the freedom to choose and plug your favorite security implementation. At the same time we also want to provide one ore more default implementations that allow users to quickly set up and start playing with Nova Bonita.

For testing purposes Nova Bonita includes a default JAAS login module checking user/password values stored in a file. This easily allow to start playing with Nova Bonita in a testing security environment in which the login module acts as a lightweight users repository. This login module (org.ow2.novabpm.identity.auth.PlainLoginModule) is the one provided in Nova Bonita examples directory.

The current implementation of the security service allows you directly work with the default identity service to handle users authentication. Users must login before start calling the Bonita APIs. The current Nova Bonita RC is not yet leveraging the Authorization capabilities provided by traditional security services, meaning that any authenticated user can reach Nova Bonita APIs. In next releases autorization will apply at APIs methods level. We could also imagine fine grained security uses cases in which authorization is not only applied at API method level but also applies to the engine itself, to a particular workflow instance or to the actions executed by the engine.

The Security service is composed by two different JAAS LoginModules. The first one (called PlainLoginModule) is responsible to handle security authentication and authorization. This one could be just replaced by you favorite JAAS Login Module. The second one (StorageLoginModule) is responsible to keep data of authenticated users (basically for security context initialization). Those login modules can be configured in both standard and enterprise environments (note that most of JEE servers already provides a Storage Login Module so you could just replace the one proposed by Nova Bonita by the one leveraged by you app server.)

Task management is all about providing the right information to the right people at the right time !. This is one of the most important services that must be provided by a workflow solution.

As human task management can be re-used in other domains (not only by workflow solutions but by any Java based application) we wanted those features to be a service rather than an internal workflow module. As a result, this service is generic and extensible Task Management service that can be either used in Nova Bonita extension to handle manual task assignments and executions or either by any Java application or Domain Specific Language (i.e BPEL4People extension for instance).

Traditional features such users - roles/group mapping, delegation, scalation, task deadlines handling or manual activities execution life cycle are in scope of this service. Advanced features such configurable activity life cycle, interactions with other task managements system, services or collaborative applications and integration with organizational rules are also part of the main responsabilities of this service.

The current implementation focus on support of manual tasks (also known as manual activities) in Nova Bonita. Basic features such Bonita RoleMappers and Performer Assignments entities allowing users - roles mapping are already supported. Together with the identity and security service, users can login into the system, get their tasks todo list and execute them. As other service in Nova Bonita this module is executed in a persistent environment.

This module concerns the way in which the workflow data is stored during the workflow execution and archived when the execution is completed. This is indeed a crucial module in a workflow solution.

While in Bonita v3 journal data (aka execution workflow data) and history data (aka archived data) where handled by different mechanism, in Nova Bonita we decided to unify them as the underlying essence of both is to handle workflow data. For that to be done, we created the concept of workflow record. A record is a minimal set of attributes describing a workflow entity execution. That means that each workflow entity related to the execution has its own associated record: instance record, task record, hook record...

Those records are recorded during the workflow execution and stored depending on the persistence service implementation (db, xml...). The Nova Bonita API will retrieve record data from the records storage and sent them back to the users (meaning that records also acts as value objects in Nova Bonita APIs).

As soon as a workflow instance is finished, a typical scenario would be (by default) to move instance related workflow data from the production environment to a history one. While the physical device and the data structure could changed from one workflow engine deployment to another (XML, BI database...), the internal format could remain the same (records). This is exactly what is happening in Nova Bonita, when archiving data the engine just move execution records from the production to the history environment without data transformation inbetween.

To handle activities deadlines, a timer service is required that can schedule timers to be executed in the future. Timers must have the ability to contain some contextual information and reference the program logic that needs to be executed when the timer expires. A typical scenario would be a manual activity (task) that needs to be monitored with a timer. For example, if this task is not completed within 2 days, notify the manager.

This service, as well as any other asynchrous service in Nova Bonita is based on the Process Virtual Machine Job executor framework. Job executor framework is responsible for handling jobs. A job could be a timer scheduling or an asynchronous message for instance. When a job is created and stored in the database, the job executor starts a new transaction, fetch the job from the database and perform the instructions contained in the message.

A package has its own life cycle:

Versionning is not fully managed for this RC2 version. Contraints on regards to the version for the deployment are the following:

A process has the following life cycle:

A process instance has the following life cycle:

There are scenarios where the re-use of a process definition is of key importance; in these scenarios, a long-time is spent carefully defining a generic process model that instantiates in the same way many times. These processes are called administrative processes (aka process models).

A process is a specific definition of a process that may be instantiated multiple times. These processes are based on a process-instance workflow paradigm. Processes are created into the the engine via the ManagmentAPI (deploy operations giving an XPDL file). No java DefinitionAPI allowing the creation of a process is supported for this release canditate. When the process is created, the workflow users are able to instantiate the workflow process via RuntimeAPI to create process instance(s). Once the process instance(s) are created, workflow participants can access the QueryRuntimeAPI to accomplish the following: obtain their "ToDo list", done list, suspended list, execute assigned activities, or access the QueryDefinitionAPI to get complementary/static definition informations onto tasks, instances, participants....

A process model keeps track of all its instances. That is, all instances of this process are retrievable through the QueryRuntimeAPI functions.

Bonita instantiation mechanism:

At process instantiation a new (XPDL) process object issued form the deployed process definition is created (and initiated with definition elements and specific parameters such as variables). A root execution object pointing to the process object is created and started. It causes the execution to point/enter onto the first activity of the process. The root execution references a ProcessInstance object representing the runtime data to be recorded in the journal all along the life of the process instance.

Versionning is not fully managed for this RC2 version. Contraints on regards to the version for the deployment are:

Hooks are user-defined logic that can be triggered at some defined point in the process life cycle. No process hooks are supported for this RC.

The types of Hooks are:

Sometimes, an independently existing business process can take part in another more sophisticated process. Instead of redefining the activities, edges, properties, and hooks in the parent process, the independent process could be included as a “subProcess” within a specific node. As the execution logic is inside the subProcess, the subProcess activities are started and terminated automatically by the Workflow engine according to the subProcess state. Creating a SubProcess Activity: When a subProcess activity is defined in the process, a specific activity with subflow behavior is created with the definition of the parsed activity (process id of the process, local variables, in/out/in-out parameters of the sub...).. Instantiating a Process with a SubProcess Activity: At execution phase when the execution enter into the subflow type activity, the following operations are done:

The activity is the basic unit of work within a process.

Several types of activity exist according on the activity definition.

Task has its own life cycle whith the folowing states:

Bonita engine creates a common object in order to manage runtime informations for all activities. The interface InstanceActivity is returned by a lot of the QueryRuntimeAPI methods to give access to these runtime informations. According the type of the activity, a specialized body can be acceeded.

Activity itself has no states. Only start and finish date are managed.

Route and subflow activity type can't execute hook. Task has its own hook events. Automatic activity can execute one type of hook event executed after the execution enters in the activity.

Nova Bonita APIs are divided into 5 different areas:

There's also a generic API that allow to execute specific commands that should be needed by the workflow based application.

Nova Bonita RC2 is an extensible and embeddable workflow solution that can be easily deployed in both standard (JSE) and Enterprise (JEE) environments.

        APIAccessorImpl accessor = new APIAccessorImpl();
        RuntimeAPI runtimeAPI = accessor.getRuntimeAPI();

        QueryAPIAccessorImpl accessorQ = new QueryAPIAccessorImpl();
        QueryRuntimeAPI queryRuntimeAPI = accessorQ.getQueryRuntimeAPI();
      

        RuntimeAPI runtimeAPI = (RuntimeAPI) initialContext.lookup("runtimeAPI");
        QueryDefinitionAPI queryDefinitionAPI =
        (QueryDefinitionAPI)  initialContext.lookup("QueryDefinitionAPI ");
      

        RuntimeAPI runtimeAPI = AccessorUtil.getRuntimeAPI();
        QueryDefinitionAPI queryDefinitionAPI = AccessorUtil.getQueryRuntimeAPI();