Implementing a Custom Workflow Assignment Handler

Documentation Home

Introduction. 1

Resource Management 1

Push and pull assignment 1

Assignment Modes 2

Assignment Handler 2

Assignment scenarios 3

See also: Workflow Index, Workflow Customization

Introduction

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.

Resource Management

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.

Push and pull assignment

The workflow system supports two types of assignments:

1. Push Assignment
   A push assignment is where the workflow system assigns the task enactment to an individual actor when the enactment is created. Such task enactments are likely to always appear in the task list of the individual. An example of this might be a request approval task that is assigned to the manager of the individual who raised the request.
2. Pull Assignment
   A pull assignment is where the workflow system assigns the task to a list of candidate actors when the task is created. For example a task to check an insurance claim might be assigned to the CLAIMS team, meaning any member of that team. At some later time, the task will be assigned to an explicit actor, and this could be done in one of two ways:
1. a supervisor displays a list of all assignment candidates, then selects one from the list.
2. an individual’s task list contains currently unassigned group tasks which could be executed by that individual, and then selects a task from the list.

Assignment Modes

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:

• Push assignment modes:
• Job opener – Assigns to the individual who originally opened the job. Note that if a job is opened by an unauthenticated user, job opener is set to “PUBLIC”. Assigning a subsequent task to job opener in this circumstance will lead to the task being “lost”, unless a user named “PUBLIC” exists.
• Resource from previous task – Assigns to the individual who was assigned to the last enactment of the named task.
• Process variable – Assigns to the individual named in the selected process variable.
• Named resource – Assigns to an explicitly named individual.
• Follow-on task – Assigns to the individual who was assigned to the previous task enactment.
• Unauthenticated – Any individual is acceptable.
• Pull assignment modes:
• Custom assignment – Assign to a resource as identified by the user’s own custom resource management application (see Assignment Handler).

The various assignment modes are encapsulated by the AssignmentMode class which is essentially just a number of integer definitions for each possible assignment mode.

Assignment Handler

The interface essentially provides two things:

1. Operations that carry out the enactment-time provision of individual resources.
2. Definition of the user interface components that are needed to define the particular “resource related” characteristics of each part of a workflow process. These components are used at workflow process design time and may be configured as the user wishes.

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.

Assignment scenarios

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:

1. At some point the user creates something like a Task, instances of which will later be enacted by the workflow system
2. As part of the creation process the user defines the assignment expression used by the Task. This part of the process is enabled by the user interface component provided by the AssignmentHandler.
3. At some subsequent point in the processing, the internals of the workflow system finishes processing a prior node enactment and this causes:
4. …
5. the creation of the enactment of the Task defined earlier.
6. As part of the creation process the task enactment invokes the assign method of the AssignmentHandler.
7. This method checks the assignment mode of the enactment,
8. retrieves the assignment expression
9. which is actually retrieved from the Task itself
10. and then, having worked out the right set of possible actors for the enactment, the assignment handler defines the set of possible actors for the enactment.
11. At some later point, the user—presumably  through the medium of a task list application—uses the assign method of the external API to define the appropriate actor for the enactment created at step 5.
12. The API sets the resource’s name on the enactment object
13. which is then checks for validity with the assignment handler.
14. Subsequently, after the user has completed the task, the workflow system proceeds to enacting the successors of the enactment created at step 5.

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.