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 – how users are assigned to tasks
• Security management
• Activity types

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:

• Job opener – Assigns to the user 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. This is a push assignment.
• Resource from previous task – Assigns to the user who was assigned to the last enactment of the named task. This is a push assignment.
• Process variable – Assigns to the user named in the selected process variable. This is a push assignment.
• Named resource – Assigns to an explicitly named user. This is a push assignment.
• Follow-on task – Assigns to the user who was assigned to the previous task enactment. This is a push assignment.
• Custom assignment – Assignment using the implemented Assignment Handler. This supports both push and pull assignments and is used for all assignment requirements other than the specific options listed above – in practice, most assignments will be in this category.

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. Use this in conjunction with XILogonexit.
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.