3.4. Hooks

Pieces of end-users java code that are executed at particular moments of either a process instance or a task or an "automatic activity" (route and subflow type activity cannot have hook).

3.4.1. for task

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.

  • task:onReady

  • task:onStart

  • task:onFinish

  • task:onSuspend

  • task:onResume

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:

  • either rollback=true (case1)

  • or rollback=false (case2)

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:

  • org.bonita.ow2.definition.TxHook

  • org.bonita.ow2.definition.Hook

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.