Customising Workflow

Introduction. 1

Resource Management 1

Push and pull assignment 2

Assignment Modes 2

Assignment Handler 2

Assignment scenarios 3

Supplied Assignment Handlers 6

Security Management 6

The Ebase sample SecurityHandler 7

Activity Types 7

Introduction

This section discusses the customization of the WfMS. In particular, it addresses three particular areas:

• Resource management
• Security management
• Activity types

Each of these (particularly the first two) is a potentially complex area for any individual implementation of the WfMS and so a general approach is taken to allow implementers to customize the WfMS to their needs.

The general approach in each situation is the same in that the WfMS defines a number of standard classes and interfaces. Each WfMS installation will require a particular implementation of some of these interfaces in order to customize that particular installation of the WfMS to the user’s requirements. In most cases some “standard” aspects of the implementation of the interfaces is provided in the form of default abstract implementations of the interfaces. Typically, implementation will proceed by extending these abstract implementation classes.

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.

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 WfMS 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 WfMS.

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

WfMS supports two types of assignments:

1. Push Assignment
   A push assignment is where the WfMS assigns the task enactment to an individual actor when the enactment is created. Such task enactments are likely to always appear in the tasklist 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 WfMS 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 tasklist 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 details of how to achieve these various assignments are handled by the AssignmentHandler interface, the complete description of which is contained in the linked javadoc document. Implementers of the WfMS are required to provide an implementation of this interface to handle the details of the assignment process that is required for that particular implementation. Note that the interface provides essentially 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 WfMS is configured to accept a particular assignment handler using the techniques described in the Workflow Configuration section of this document.

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 WfMS
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 WfMS 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 WfMS 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.

Supplied Assignment Handlers

The following assignment handlers are supplied with the Ebase system:

Name	Classname	Description
XIAssignmentHandler	com.ebasetech.ufs.xi.workflow.XIAssignmentHandler	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 in UFSSetup.properties with parameter Workflow.AssignmentHandler e.g.

Workflow.AssignmentHandler=com.ebasetech.ufs.xi.workflow.XIAssignmentHandler

!!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

In a similar manner to that described above with respect to resource management, the WfMS is designed to be configurable in the way it secures access to the external facilities that it provides. Each implementation of the WfMS must provide an implementation of the SecurityHandler interface. Each method called on the external API is checked, before it is executed, using the checkAllowable method of this interface.

The WfMS provides a simple abstract implementation of the security handler interface as the DefaultSecurityHandler class.

The details of this interface, as before, 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 to be hidden entirely from some users.
6. The results are returned to the user

In the same manner as for the assignment handler, the WfMS is configured to accept a particular security handler using the techniques described in the Workflow Configuration section of this document.

Note: When implementing the Assignment and Security handlers, it is perfectly reasonable to implement them both in the same class. If this is the case, the WfMS will only instantiate a single instance of that class.

The Ebase sample SecurityHandler

This sample implementation uses the standard Ebase security and user management model. For further details please contact Ebase support.

Activity Types

WfMS 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 UFSSetup.properties file. For details on how to do this, see Workflow configuration.