Customizing Workflow

 

Documentation Home

 

Introduction. 1

Task Assignment 1

Push and pull assignment 1

Assignment Modes 2

Assignment Handler 2

Supplied Assignment Handlers 3

Security Management 3

The Ebase sample SecurityHandler 4

Activity Types 4

 

See also: Workflow Index

 

Introduction

This section discusses the customization of the workflow system. It addresses three particular areas:

 

 

 

Task Assignment

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:

 

Push and pull assignment

The workflow system supports two types of assignments:

 

  1. Push Assignment
    Push assignment is where the workflow system immediately assigns a task to one individual user. Such tasks 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
    Pull assignment is where the workflow system assigns the task to a group of potential users 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 user, and this can be done in one of two ways:
    1. An individual’s task list contains currently unassigned group tasks which could be executed by anyone in the group, and the user then selects a task from the list.
    2. A supervisor displays a list of all assignment candidates then selects one from the list.

 

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.

 

Assignment Modes

At design time, the designer can specify an assignment mode for each task:

 

 

Assignment Handler

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.

 

Supplied Assignment Handlers

Here is a complete list of the assignment handlers supplied with the Ebase Xi workflow system:

 

Name

Classname

Description

XIAssignmentHandler

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.

LDAPAssignmentHandler

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.

 

 

Security Management

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:

 

  1. The user invokes one of the externally accessible methods on the API
  2. The API locates the particular instance of the Function class that represents the operation being invoked
  3. The API uses the security handler to check if it’s acceptable to perform the indication function on the indicated target by the current user
  4. If acceptable the API determines the result of the operation
  5. If there are results from this particular API call (for example, for the example getJobs() operation there would most likely be some results) then each of the results is passed to the security handler to see if the current user is allowed to see this particular result object. (This allows, for example, some processes or tasks to be hidden entirely from some users).
  6. The results are returned to the user

 

The workflow system is configured to accept a particular security handler as described in Workflow Configuration.

 

 

Activity Types

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.