Implementing a Custom Workflow
Assignment Handler
See also: Workflow Index,
Workflow Customization
The general recommendation is to use the supplied Xi workflow assignment handler class com.ebasetech.ufs.xi.workflow.XIAssignmentHandler which provides great flexibility in performing workflow assignments. However, it is also possible to create a new assignment handler by implementing the AssignmentHandler interface. This document contains notes to help you do this.
Company organizational information is
typically dynamic, and can be expected to change both periodically, as
individuals change jobs, and also on a daily basis as people are sick, on
holiday, take on additional responsibilities and so on. There is no generic
model for this, so the most flexible solution is to externalize this into one
or more pluggable components.
Hence, the workflow system provides a
flexible system for resource management, and importantly assignment of those
resources to interactive task enactments that may be specialized for different
situations. This section describes the approach taken to resource management
and how it may be configured by implementers of the workflow system.
There are a number of basic concepts that need to be understood before progressing to the details of resource management. These are described in the following sections.
The workflow system supports two types of
assignments:
At design time, the designer can specify an
assignment mode for each task. This defines whether the assignment will be push
or pull and the rules by which the assignment will be made. Options for
assignment modes are:
The various assignment modes are encapsulated by the AssignmentMode class which is essentially just a number of integer definitions for each possible assignment mode.
The interface essentially provides two
things:
The recommended approach to the provision of
an AssignmentHandler
implementation is to extend the DefaultAssignmentHandler
class which also provides the standard support for the other assignments modes
i.e. JobOpener, NamedResource, Follow-On etc. There are no prerequisites on the
complexity or simplicity of the implementation. It may be as simple as a single
database table containing a list of employee names or as complex as a bespoke
HR application.
The workflow system is configured to accept
a particular assignment handler as described in Workflow Configuration.
Javadoc information is provided for all aspects of the customization classes and interfaces. The rest of this section describes the various interfaces and provides links into this generated documentation.
In order to make the intended process of assignment clearer,
this section provides a couple of UML sequence diagrams showing the intended
sequence of interactions for two different sorts of assignment.
This diagram summarizes the process of pull assignment:
The steps in this indicative diagram are as follows:
Push assignment is essentially the same process:
The essential difference this time is that the assignment
handler makes an immediate decision of the actor to be used by the enactment
and invokes the setActorId
method of the enactment without needing to have a specific actor chosen at a
later stage of the process.
It is possible, in some special cases, that an Assignable
does not support actor pools. An example of this case is for escalator
enactments since there is no concept of an escalator being assigned to a group
and then someone “taking” an escalator. In order to be able to determine this,
Assignable objects provide the supportsActorPools()
method. The AssignmentHandler
is required to test the assignable to see if it supports actor pools. If not,
then push assignment must be used; attempting to use pull assignment
will cause a run-time exception to be thrown.