Customizing Workflow
The
Ebase sample SecurityHandler
See also: Workflow Index
This section discusses the customization of the workflow system.
It addresses three particular areas:
The workflow system assignment process is very flexible and supports the option of “programmed” assignment. This allows you to write scripting code that performs an assignment – this might entail checking attributes from a running job, reading information from a user registry or from an HR system, reading database data, calling a web service etc.
Before we look at the details of assignment, there are a
couple of basic concepts that need to be understood:
The workflow system supports two types of assignments:
From the
end user’s perspective, both push
and pull assignment will probably
look pretty much the same: they will see tasks on a task list and will select
(or “take”) a task to be worked on. Internally, there is a small difference in
the states that the task passes through during its lifecycle:
For a push assignment when the task is
immediately assigned to a specific user, the task goes straight to the waiting state where it will only appear
on the task list of that user. When the user selects the task it will change to
active:
Start > Waiting > Active
For a pull assignment, the task is initially assigned
to some sort of group and there is an extra state of unassigned that represents the time where the task is assigned to
the group but not yet to an individual. During this time, the task will
probably appear on the task list of all eligible users (we say probably here because the task list can
be customized). The task will pass through these states:
Start > Unassigned > Waiting > Active
Click here for more
information on the task lifecycle states.
At design time, the designer can specify an assignment mode for each task:
The assignment handler is the component that makes the assignment process flexible. It is possible to write your own assignment handler – this means writing Java code – however the default assignment handler provided with the system allows you to perform assignment using script code and this provides enough flexibility for all but the most extreme of requirements. If you’re still interested in writing your own Java assignment handler, click here for more details.
The default assignment handler – called the Xi Assignment Handler – works by delegating the assignment decision to a workflow assignment system service (this is like a web service that operates internally). You then write code to implement whatever assignment logic you require, and this supports both pull and push assignment. The default logic provided with the system supports simple role based assignment, but this is intended to be changed or augmented.
Here is a complete list of the assignment handlers supplied with the Ebase Xi workflow system:
Name |
Classname |
Description |
com.ebasetech.ufs.xi.workflow.XIAssignmentHandler |
This is the default assignment handler and is recommended
for almost all requirements. It provides a flexible technique for
implementing assignment using server side scripts. |
|
EbaseAssignmentHandler |
com.ebasetech.ufs.workflow.resource.example. EbaseAssignmentHandler |
For use only with the supplied Ebase security system.
Assignment based on groups and group membership. |
EbaseDynamicAssignmentHandler |
com.ebasetech.ufs.workflow.resource.example. EbaseDynamicAssignmentHandler |
The same as EbaseAssignmentHandler,
but supports dynamic assignment using process attribute variables. |
com.ebasetech.ufs.workflow.resource.example. LDAPAssignmentHandler |
Assignment based on attributes in an LDAP User Registry
(note this can also be achieved using XIAssignmentHandler). |
The assignment
handler is configured on both the designer and the server: on the designer
using the Workflow tab of Designer Preferences, on the
server with server property Assignment
Handler.
!!Warning: the assignment handlers listed above
are not compatible with each other. Changing the assignment handler in a system
with live workflow data can lead to assignable tasks.
Access to the workflow system is controlled by an implementation of the SecurityHandler interface. The workflow system is supplied with two implementations of this interface as described here. It is also possible to create a new implementation and the following notes are designed to help with this.
Each method called on the workflow API is checked before it
is executed, using the checkAllowable method of this interface.
The workflow system provides a simple abstract
implementation of the security handler interface as the DefaultSecurityHandler class.
The details of this interface, are
fully documented in the linked javadoc pages. In
order to provide a context for this, the following UML sequence diagram shows
the typical security interaction
The general action of the security process is then:
The workflow system is configured to accept a particular
security handler as described in Workflow
Configuration.
The workflow system provides, by default, three activity
types namely EbaseActivityType, ManualActivityType
and CustomActivityType. For details on these, see Activity Types.
Alternatively, the ActivityType interface may be implemented in order to provide
new user-specific activity types.
Once implemented and in order for the new type to be made
available in the interactive activity designer selection menu, the ActivityType implementation class must be configured in the
Workflow tab of Designer Preferences. For details
on how to do this, see Workflow
configuration.