Ebase workflow management system (WfMS) is a standalone module which enables the automation and tracking of business processes. A business process, such as processing a loan application or answering a customer support call, is something which may involve a combination of manual and automated activities such as checking the loan request, authorising the request, responding to the requester. The sequence in which activities are performed is important to the correct execution of the process and will often depend on the outcome of previous activities, for example, a loan can not be approved before the application has been made, and if the loan is for an amount greater then £10,000 it can only be authorized by a senior level manager. Although it is possible for a business process to be fully automated, it is often the case that one or more individuals will be required to take part in the process, for example, the manager who authorizes the loan or the customer support engineer who responds to a customer’s query.

The term Workflow is synonymous with a business process in that a workflow is the definition of the ways work can flow around an organization in order to achieve a specific goal.

A Simple Example – A Loan Application

The easiest way to start is to think about a simple example process. A user logs in to a web site to apply for a personal loan. The steps in the process are:

Request – Margaret wants to buy a car. She completes an on-line loan request form entering the amount she wants to borrow and an email address she wants to be contacted at. She submits the request. This starts off the process.
Is finance check required? – This is a decision step where the loan company checks whether the loan request is over £1000. If it is, the loan request has to go to the loan manager for a special manual authorization step. If it’s less than £1000 the system can automatically authorize the loan.
Finance Check – This is a manual step which causes a task to appear on the loan manager’s task list. The loan manager selects the task and opens it which takes him to a loan authorization web page showing the applicant’s information. The manager can then choose to authorize or reject the application.
Notification – Margaret is sent an email to notify her whether or not her loan application has been successful.

This is clearly a very simple example but we will continue to build on it throughout this section.

Workflow Terminology

This section introduces the terms used within the WfMS and identifies the key characteristics of the types of workflow process supported.

Process

A process in the WfMS represents the design of a single business process, for example, handling a loan application or processing a customer order. Each process will usually consist of a number of individual tasks and may also include conditional logic. A process may also contain sub-processes. A process is created by a workflow designer using the graphical Process Designer Tool.

Node

A node is single “step” in the process. Nodes are linked together by Links. Nodes can be either Tasks

, Routing Steps or Sub-processes and define the sequence of events that are required to make up a valid process.

Task

A task represents a single unit of activity to be performed. Tasks can either be interactive (performed by a person) or system (executed automatically by the system with no human interaction). The actual activity to be performed by the task is selected from a pool of activities which can be defined separately and hence reused (see below). From the perspective of the workflow management system, tasks are atomic and cannot be sub-divided. In our loan application example, the tasks are: REQUEST, FINANCE_CHECK and NOTIFICATION.

In the workflow designer, an interactive task is represented as:

And a system task is represented as:

Activity

This represents a specific activity to be performed. There are two types of activity:

· Interactive Activity: An interactive activity is performed by a person, possibly using an IT application, for example completing an on-line form.

· System Activity: A system activity has no human involvement and is executed automatically by the workflow engine, for example, sending an email notifying the loan applicant whether their loan has been approved. System activities are created using any supported server side scripting language.

Each task must be configured with a single activity or the appropriate type. Activities are defined independently of tasks to allow reuse of activity definitions across processes.

Note: We will use the term interactive task to refer to a task configured with an interactive activity and system task to refer to a task configured with a system activity.

In our example, the REQUEST task and FINANCE_CHECK task are both interactive tasks which encapsulate the loan request online form and the loan authorization on-line form respectively. The NOTIFICATION task is a system task whose activity performs the automatic sending of an email to the applicant.

Routing Steps

There are currently two different types of routing steps. These provide conditional routing and parallel routing capability to what would otherwise be a trivial, single path process:

Split (and Join): A split represents a point in the process execution path where two or more paths are to be executed concurrently. This is modelled as shown below. There is no decision logic associated with a split as all split paths will always be activated. All paths leaving a split must ultimately meet at a corresponding join point. A join node will always be generated automatically when a split is added to a process and is shown linked to the split node by a dashed line. There is no limit on the number of links coming out of a split provided that all paths leaving the split ultimately end up at its corresponding join.

Decision: A decision represents a point in the process where one of a number of possible paths may be taken. The path chosen will be based on the decision logic provided by the process designer. There is no corresponding join for a decision as only one path can ever be followed. The ongoing path options are defined by the names on the links coming out of the decision node, for example, do a manual finance check if the loan requested is over £1000, otherwise just authorize it automatically. See Decision Scripts for more details.

Other Nodes

Pause Node: A pause node represents a point in the process where execution stops and waits for some external event to occur. When the event occurs, the node can be posted which then runs the script associated with the node. Additionally, this script can also be executed all regular intervals. The script can decide programmatically whether processing should continue or whether to continue waiting. Pause Nodes are primarily intended to be used to include external services into a workflow process that otherwise do not have the ability to connect to the Wfms, for example to periodically check a database for the existence of a record etc. See Pause Node for details.

Sub-process

Any process can include any other process represented as a single node on the process diagram. A sub-process is represented in the designer as:

This nesting can continue to any level although care should be taken at design-time not to cause an infinite loop (unless specifically required) by including a process which ultimately includes itself. This is a powerful feature that gives the ability to componentize process development. For example, an approval process could be created, then included within multiple parent processes. Note that any process can function as any or all of: a standalone process, a sub-process, or a parent process.

Link

Links are the arrow lines which join tasks, routing steps and sub processes together to define the flow of control through the process. Links may be labelled with a friendly name. This is optional in all cases except following a decision node. In this case, the decision logic will ultimately refer to the link to be chosen as the next step and this is done using the link’s name (See Decision Scripts for more details)

Escalation

Any interactive task in a workflow process may be the subject of one or more escalations. An escalation is essentially a sub-process that is automatically enacted by the Workflow Management System should some timed condition not be achieved. Typically, an escalation is used to define the required schedule for some activity. For example, it might be the case that a particular report was required to be completed within 30 working days.

A task may have multiple escalations with different time requirements. For example, a first escalation could be used when half the available time has expired to raise the priority. Later, when 90% of the time has expired a warning email could be sent to the person allocated to the task to inform them that the deadline was approaching.

When the escalated task is completed any remaining escalations are removed. Each escalation has two workflow nodes related to it:

· The trigger node, which defines when the timing for an escalator starts

· The escalated node, which is the node that, when complete, will remove the escalator enactments.

For more information see escalations later in this document.

Job

A Job is one specific execution of a process, for example, handling Mrs. Jones’s burglary insurance claim or processing Margaret’s loan application. In discussion of workflow, the term case is sometimes used to mean the same thing; however in the context of the WfMS, the term job will be used throughout. During its lifetime, a process will have many jobs created for it, for example:

Enactment

An enactment is one specific execution of a node, for example, the loan manager clicking the reject button to reject Margaret’s loan application would be an enactment of the “FINACNCE_CHECK” interactive task, or, the automatic sending of a rejection email to Margaret would be an enactment of the NOTIFICATION system task. During it’s lifetime a process node will have many enactments created for it, for example:

Resource

A resource represents the entity to whom an interactive task will be assigned and hence, the individual who will enact the activity. In our example, the resource to which the FINANCE_CHECK task will be assigned to is the person who is identified as the loan manager.

The concept of resource assignment is only applicable to interactive tasks since system tasks are automatically enacted by the WfMS. At design-time, the resource associated with a task may either be an explicit individual or an expression which will identify an individual at runtime, for example, “any user who belongs to the Customer Support Team” or, “the line manager of the employee requesting the car hire”. WfMS provides a generic interface allowing organizations to plug-in modules representing their own specific HR structure. This supports a powerful and flexible capability to assign tasks to groups, teams, roles, individuals with full contextual information. See Resource Management for more information.

Audit Record

Audit records are generated as and when events happen within the workflow runtime which need to be recorded for historical reasons. Audit records log the event that occurred, the reason for the event (in the case where the event is user requested) and the resource name who requested the event. For example, If a job is cancelled by an administrator, the reason for cancellation and the name of that administrator are logged against the cancel action.

Task List

A task list is a separate runtime application which enables end-users to see which tasks are assigned explicitly to them and which tasks are available to them for the taking (e.g. tasks to be performed by any member of their team). A sample tasklist is provided, but the Workflow API can also be used to create a customer specific task list application.

It is worth noting that the concepts above fall into two distinct groups:

· Design-time concepts: Process, Task, Activity, Split, Join, Decision and Sub-process.
These are the terms that will be involved when designing a workflow using the graphical workflow designer tool.

· Runtime concepts: Job, Task Enactment, Task List

These are the terms that will be involved when the workflow is executed.

This distinction will be carried throughout the remainder of this documentation.

Components of the Workflow Management System

The WfMS is made up of the following components:

Graphical Process Designer

This is the GUI tool which allows workflow designers to create and test processes and save these in the database.

Workflow Repository

This stores all workflow process and activity definitions.

Workflow Enactment Service

This is the heart of the WfMS and supports the creation and processing of jobs. At it’s core is a work queue which is continually running and processing task enactments as they become due.

Workflow Client Applications

These represent external applications that interface with the workflow system via the Job Management API. The most common of these are expected to be the task list application and the workflow administration application (see below). Other possible applications may be developed using the Ebase forms applications developer which provides integration to the Job Management API via a scripting language.

Task List Application

This is an example client application provided with the WfMS. It presents all outstanding tasks which may be performed by an individual and allows the individual to select items from the list and complete them. This is implemented using the Job Management API. It is anticipated that the client may wish to develop a more advanced version of this application to meet their specific requirements, for example, including ability to change priority of a task, re-assigning a task etc All this capability is available from the Job Management API.

Workflow Administration Application

This is an example client application provided with the WfMS. It enables an administrator to browse both current and historical jobs, tasks, processes and audit records. It also allows the user to perform administration activities on these objects, for example, cancelling jobs or reassigning tasks. This application makes use of the filtered list methods on the Job Management API. (See Workflow API for more information)

Job Management API: This is a public interface which provides information on interactive task enactments which are sitting and waiting on the work queue for a user to take them and act on them. The implementation of this API is provided by the Workflow Enactment Service. (See Workflow API for more information)

Assignment Handler API

This controls the ability to assign task enactments to resources. The open API provides the flexibility to allow WfMS to integrate to the client’s individual resource management solution. The implementation of this API must be provided by the client for each installation of the WfMS and will differ for each HR solution. A default implementation is provided in the form of the DefaultAssignmentHandler but it is left open to allow for organization-specific customization of role/group/team rules. (See Workflow Customization for more information)

Security Handler API

This controls the access to operations on the Job Management API and the visibility of results returned from these calls. This provides the flexibility to allow WfMS to integrate to the client’s individual security management solution. A default implementation is provided in the form of the EbaseSecurityHandler which integrates into the native Ebase security solution. This can easily be replaced with a custom implementation allowing for organization-specific access and visibility rules. See Workflow Customization for more information)

Local calendar

Some aspects of workflow process enactment require access to the calendar used by the organization using each installation of the WfMS. (See Calendar for more information)

Design-time Concepts - Processes

This section discusses in more detail the elements involved in designing a process. It will cover processes, tasks, activities, routing steps and use of sub-processes.

Process structure

In order to avoid badly structured processes, WfMS provides a process validation facility which verifies that the process meets the following criteria:

· Processes:

o A process has a single start point and a single end point which are created automatically when a new process is created. All paths in a process must ultimately originate from the same start node and culminate in the same end node. This means that it is clear when a process is finished since it is not valid to have multiple branches of a process with their own individual end points.

o All nodes in a process are connected somehow to all other nodes. That is, there is no part of the process (sub-graph) which is disconnected from the rest of the process.

o The only nodes allowed to have more than one output link are decisions and splits

· Tasks:

o A task must refer to a valid activity.

o Input and output parameters for the activity must all be mapped to valid process attributes.

o All tasks must have a specified assignment mode.

o If a task has an assignment mode which refers to the resource assigned to a previous task, that task must exist in the process path before the referring task.

· Links:

o A link must always connect two nodes, and all nodes (other than the start and end nodes) have at least one input and one output link.

· Splits/Joins:

o All splits must have a matching join.

o All process paths from a split point must rejoin at a subsequent join node without passing the original split. This means that looping back from a path resulting from a split to a node before the split is not allowed since this would result in processes where the number of times the process exits the split will not be equal to the number of times it enters the join. For example:

· Decisions:

o A decision node must have at least two links coming out of it.

o All links coming out of a decision node must have a non-default name. When a link is first created it is given a default name of the form “Link xx” where xx is the link number. This must be replaced by a meaningful name in the case of decision node output links so that the link names can be used in the decision logic script.

· Pause Nodes:

o If an event id is specified, it must be unique within the process

· Sub-processes:

o Sub-process nodes must refer to a sub-process that exists.

o Input and output parameters for the sub-process must all be mapped to valid process attributes.

· Escalations:

o Escalations must refer to escalation sub-processes that exist

o Escalated nodes cannot exist within a loop in the containing process structure. That is, they may not appear in a place in the process flow where a decision could cause the same escalated node to be enacted more than once.

o If escalations inherit their assignment details from their escalated node then that node must be of a type that supports such things.

Process Properties

A process has the following properties associated with it:

· Name: This must be unique and is used to identify a process throughout it’s lifetime.

· Description: This is a textual description of the purpose of this process.
Note: Descriptions support multilingual text in the same manner as all other Ebase forms applications.

· Process Creator: This is the User ID of the designer who released the process last.

· Process owner: The user Id of the person who is ultimately responsible for the design of this process although not necessarily for it’s implementation.

· Job Owner assignment: This defines how the ownership of an individual job opened on this process will be decided. A job may well need to have a person defined who is ultimately responsible for that specific job. In our example, the job owner may be the person to whom Margaret is referred when she phones the bank to contest why her loan has not been approved. There are two modes for assigning Job ownership:

§ Static assignment - This is where the job owner is assigned explicitly at the start of a job. In this case the assignment will persist throughout the life of the job.

§ Dynamic assignment - This is where an assignment expression is defined for the job owner, for example, “the current loan manager”. This is then re-evaluated each time a task enactment refers to the job owner via the integration to the resource management system. The benefit of dynamic job ownership is that if the current loan manager changes job and a new loan manager is appointed, the dynamically evaluated job owner continues to be a valid individual.

· Security: This defines who is authorized to perform the various activities on any given job for this process. For example, any user who can see task enactments on their task list may be allowed to open a task but only someone with “administrator” privileges may be allowed to cancel an entire job. Process security also controls visibility of task enactments for a job since some tasks may contain sensitive information and may only be visible to individuals with higher access privileges, for example, anyone with “basic loans manager” privileges may be allowed to view all loan applications for up to £50,000 but only those with “senior loan manager” status are allowed to view applications for more than £50,000.

· Error recovery process: The process designer has the option of specifying an error recovery process which will be executed at the time when a task fails during enactment. The error recovery process is just another process but will automatically be passed a number of input parameters to allow it to notify the relevant person that something bad has happened. The parameters available are:

§ FAILEDPROCESSNAME – the name of the process for which a task enactment has just failed.

§ FAILEDTASKNAME – the task enactment which has just failed.

§ FAILUREREASON – a text string describing the reason for failure. This will typically be the error message generated by the workflow system.

§ TARGETEMAIL – an email address which can be globally configured (see Workflow Preferences) to which all system failure notifications should be sent.

If these are to be used in the error recovery process, they need to be declared as its process attributes.

Process attributes

Process attributes are variables that can have explicit values for each job. For example, a process to handle insurance claims might have an attribute claim_number. Any number of such attributes can be defined by the process designer.

Values for these attributes can be passed to task enactments as they are started, read and written by task enactments or by scriptable process routing steps as they are executed for example, they could be used to determine branching logic within decision nodes. As each workflow step completes, these attribute values are persisted to the database.

Data types supported for process attributes are: character, numeric, integer, date, boolean, currency, datetime, time.

Process attributes are analogous to Ebase form fields and can be used in exactly the same way. Hence they can be:

· Read and written in decision and system task scripts (see decisions and system activities).

· Imported from a business view set on the process and mapped to resource fields.

Process table attributes

Process table attributes are similar to process attributes but support the storage and manipulation of tabular data. Process table attributes are analogous to Ebase tables and can be used in exactly the same way.

Table data can be accessed and manipulated in system activity and decision scripts. They can be mapped to any tabular Ebase resources (such as database tables or XML resources) and then initialised from and saved to those resources using the fetchtable and updatetable commands (see Business views). As for simple process attributes, their runtime data is specific to each job.

Note: If an external resource mapped to a process table attribute is to be kept up-to-date with changes made during the execution of a job, each activity script which makes changes to that table attribute MUST call updatetable to commit the changes to that resource at the end of the script.

Table attributes can also be treated as completely local data (not mapped to any resource) in which case the tables must be initialized using activity scripts, adding rows and setting column values, and this data will then be available to other activities within the job context.

Process In/Out Parameters

Process attributes can be declared as IN (process input) or OUT (process output) or both. The IN designation has meaning for all process types, whereas the OUT designation is only applicable for attributes of sub-processes (see sub processes). A value for an IN attribute can be supplied when a new job is created.

The process attributes of a sub-process are ‘private’ to that process and cannot be accessed by a calling process. Similarly, the process attributes of a calling process cannot be accessed by a called process. Hence, when a process is included as a sub-process of another process, the process designer will be requested to map the IN and OUT attributes of the sub-process to attributes in the parent process. The WfMS will automatically populate values for these attributes as applicable when the sub-process starts and ends.

Process table attributes may also be designated IN or OUT parameters in a similar way to simple process attributes but with a few differences:

1. Process table attributes can not be passed as IN parameters on job creation.

2. When mapping process table attributes onto the IN/OUT parameters of a sub-process, the table structures must be identical ie. they must have the same set of columns with the same names and same column types. This is checked by the process validation facility and an error will be reported if the table structures do not match.

Business views

A process may have a business view associated with it. This is analogous to the use of business views in Ebase forms applications. The business view can contain resources which may be imported into the process to create process attributes (essentially form fields) which map to the resource fields. If the resource is fetched, the data is loaded from the resource based on populated key fields. If the resource is updated, the attribute values will be propagated down to the resource fields, for example, to populate an email resource.

Resources can be manipulated from system task and decision scripts in the same manner as for Ebase forms.

System attributes

In addition to explicitly declared process attributes, a number of system supplied attributes are also available. These supply information on aspects of a job as it executes and can also be used to control job behaviour for example, if an approval step needs to be assigned to the manager of the person who initiated the job the system attribute which refers to the job opener would be used which is: $OPENER_RESOURCE.

System attribute names begin with a $, and hence it is illegal for non-system attributes to begin with a $.

System attributes can be either read-only or read-write as shown in the table below:

Attribute	Description	Read	Write
Job level attributes:
$NEXT_STEP	The name of the next step to be executed on the current path of a job. This is used in decision scripts to set the next step (see Decision Scripts)	Yes	Yes (only in a decision step)
$PAUSE_COMPLETED	Set to 'Y' indicate that a Pause Node should complete (see Pause Nodes).	Yes	Yes (only in a Pause Node)
$CREATION_RESOURCE	The resource (user) that created the job.	Yes	No
$OWNER_RESOURCE	The resource that currently owns the job	Yes	Yes
$OPENER_RESOURCE	The resource that opened the job	Yes	No
$COMPLETION_STATE	The completion state for the current task.	Yes	Yes (can only be set by system tasks and sets the completion state for the currently executing task)
$CREATION_DATE	Job creation date	Yes	No
$CREATION_TIME	Job creation time	Yes	No
$JOB_ID	Job id.	Yes	No
Task level attributes: following attributes apply to each task where xxxx is the task name. If the task is executed more than once, they apply to the most recently executed instance of the task.
$WF_xxxx_RESOURCE	The resource that executed the most recent enactment of this task on the current stream	Yes	Yes (this is a future configuration)
$WF_xxxx_COMPLETION_STATE	The completion state of the most recent enactment of this task	Yes	No
$WF_xxxx_STATE	The workflow state of the most recent enactment of this task	Yes	No
$WF_xxxx_PRIORITY	The priority of the most recent enactment of this task on the current stream	Yes	Yes (this is a future configuration)
$WF_xxxx_CREATION_DATE	The creation date of the most recent enactment of this task	Yes	No
$WF_xxxx_CREATION_TIME	The creation time of the most recent enactment of this task	Yes	No

Parent attributes

For processes with sub processes, particularly in the case of escalation processes, it may be necessary for the sub process to access process or system attributes from the parent process. For example, an escalation process may well want to increase the priority of a task in the parent process. This involves getting the task’s current priority value, incrementing it by one and setting it back on the parent process. This can be done using the PARENT. prefix for any process or system attribute. In our example, to increment the priority of a task in the parent process you would write:

SET PARENT.$WF_xxxx_PRIORITY = PARENT.$WF_xxxx_PRIORITY + 1

Where xxxx is the name of the task who’s priority is to be set (see System attributes)

This mechanism can also be used with any process attribute, for example, to make a check based on the value of the AMOUNT attribute of the parent process you would write:

If [ PARENT.AMOUNT > 1000 ]

Although, for simple process attributes, this could also be achieved by specifying an AMOUNT attribute on the sub process, specifying it as an input parameter and mapping it to the AMOUNT attribute of the parent process.

Future configuration

Setting the value of either $WF_xxxx_RESOURCE or $WF_xxxx_PRIORITY results in a future configuration being stored for the named task on the current stream. This configuration will be applied to the next enactment encountered for the named task on the same stream.

In the following example, the process contains an interactive task, DO_SOMETHING, followed by an ESCALATE task which, if the priority is greater than 1 (1 being the most severe) will increase the priority for the next occurrence of the DO_SOMETHING task and set a more senior resource to whom that task will be assigned next time it comes around. This is a fairly pathological example but is useful to demonstrate these attributes. The LOOP_BACK decision node will return to the DO_SOMETHING task if the priority is greater than 1.

When the DO_SOMETHING task is first enacted, lets assume its priority is 5. The enactment is opened by the resource to whom it is assignable and subsequently completed. The ESCALATE task is then enacted. It sets up a future configuration for the next enactment of the DO_SOMETHING task which will set it’s priority to 2 and assign it to Alan. The LOOP_BACK decision is then enacted and returns to the DO_SOMETHING task since the last priority of that task was 5.

The next task to enact is DO_SOMETHING so the future configuration which was previously set up is applied to this enactment. This means that the enactment’s priority is set to 2 and it is automatically assigned to Alan. Once Alan completes this task, the ESCALATE task will set up a new future configuration for the DO_SOMETHING task which will set it’s priority to 1 and assign it to Berol (the head honcho!). The LOOP_BACK decision is then enacted again. This time it checks the priority of the last enactment of DO_SOMETHING and finds that it was 2. This is greater than 1 so again it loops back and returns to the DO_SOMETHING task.

This time the future configuration is applied to the DO_SOMETHING task its priority is set to 1 and it is automatically assigned to Berol. When Berol completes the task, the ESCALATE task finds that there is nothing to do and processing goes on to the LOOP_BACK task, This time the priority of the last enactment of the DO_SOMETHING task is 1 so the LOOP_BACK task steps on to the end node.

Streams

A stream defines a single runtime path through a process. At the start of a job, a stream is created which follows the path of the process. In the example below, this is the Main Stream. When the enactment engine encounters the split node, the stream splits into 2 sub-streams which continue to run in parallel. When the join is reached, the two sub-streams are consolidated back into the main stream and processing continues in a single path.

In general the designer need not be aware of streams. The only place where this is of concern is when setting up future configuration for task assignment and priorities. All future assignments apply within the context of the stream from which they are issued.

Versioning and the release cycle

Once a process designer is happy with the design of a process, the process can be released. Releasing a process allocates the next version number to that version of the process and makes the process available to the workflow enactment engine. When a new job is opened, the latest released version of the process will automatically be used.

The benefit of supporting process versions is that if there are already a number of jobs open for process LOAN_APPLICATION which is at version 1 and the designer wishes to introduce a change to this process, this can be done immediately without impacting running jobs. The NEXT time a job is opened on that process, the new version, i.e. version2, will be used while the existing jobs (which still may not have completed) can continue running against version 1.

Without versioning, the only alternative would be to wait until all active jobs for a process had ended – which may well be impossible in real life.

Activities are versioned in the same way that processes are versioned.

The versioning of activities (and, for that matter, sub-processes and escalators, since they are just processes in their own right) means that there needs to be some binding of versions, between any specific process and the activities and sub-processes which it uses, to avoid definitions changing under foot. This is done using version binding.

At release time, all tasks, process nodes and escalators are bound to the latest versions of the activities and sub-processes to which they refer.

The implication of this is that when a process is released, all versions of all participating activities and sub-processes are tied together as far as the workflow enactment engine is concerned and will not vary as future modifications are made in the designer tool.

While a process is being edited it will be referring to the very latest versions of any activities or sub-processes. When a process is released, if the activities or sub-processes it refers to are also currently being edited or are considered to have changed (see definition below), they will be also be released to conform with the binding rules.

A process is considered to have changed if either, it itself has been edited or, any of it’s supporting objects (namely activities or sub-processes) have changed since they were last released. An activity is considered to have changed if it itself has been edited.

The following example is for a process with two tasks and a sub-process.

Activate/Quiesce

There may be cases where an administrator wishes to stop any jobs being opened for a process. This can be achieved by quiescing the process. When in the quiescent state, no jobs may be opened for the process. To clear this state, the process should be activated. The active state is the default state for a process. Quiescing or activating a process can be done from the Workflow administration application.

Deletion

When a process is deleted from the designer, it is not physically deleted but instead is marked as deleted in the repository. This means that any jobs still running against this process can continue running with no risk that the process definition will suddenly disappear. A further reason for not physically deleting process definitions is to retain the history of the process structure for audit purposes.

The only exception to this rule is if the process has never been released. In this case, deleting the process will physically delete it from the repository since there is no risk that it may already have jobs running against it.

Once a process has been marked as deleted, it will no longer be visible in the designer. The Workflow Administration application may still be used to view deleted processes and reinstate them if required.

If a user attempts to create a new process from the designer with the same name as a process which has been marked as deleted, the user will be prompted whether they wish to reinstate the deleted process or create a new one. If they opt to create a new process, this will actually result in the original process being reinstated and then a new (empty) process version being added as the latest version of the original process thus retaining the original process’s history for the same reasons as defined above.

This principle also applies to Activities.

Import/Export

Processes (and Activities) may be exported and imported in a similar manner to any other Ebase forms but with the following differences:

· Exporting a process will automatically export all associated activities and sub-processes in order to preserve version bindings across the import.

· Importing a process will automatically import all associates activities and sub-processes in order to preserve version bindings.

· There are two modes for exporting a process:

o For development – this mode only exports the latest versions of the process and all associated activities and sub-processes since that is all that is required to continue development in another environment.

o For deployment – this mode exports the latest released versions back to the required bound versions for all associated activities and sub-processes.

· When importing a process, if a process of the same name already exists, the imported process will be added as a new version on top of any existing versions. The process versions are encoded in the export file as relative versions so that once a process and all it’s supporting activities and sub-processes are imported, all version bindings are resolved.

· In the following scenario we have a process which has two tasks and one sub-process. This process has been edited and released several times and the associated activities and sub-process have also been edited and released separately. The process used is as for the Versioning example (above).

Exporting the MainProcess (at this stage) for development will result in the following export items:

In the export file, the versions will be numbered with the relative numbers (in red) so that if they are imported into a system which already contains processes or activities with the same name, they will just be added as new versions of those processes/activities. This relative numbering becomes more important for the export for deployment option.

Exporting for deployment will result in the following export items:

In this case, since MainProcess is currently being edited at version 3, the latest released version, v2, is also exported. In order to support released version v2 of the MainProcess, versions of Activity1, Activity2 and Sub-process are also exported back to the version numbers which were bound to MainProcess v2 at release time. The version are numbered relative to the earliest version which is being exported.

When this export selection is imported, these versions will be renumbered in the new system depending on whether processes or activities already exist with these names. For example, if the target system already has a MainProcess and an Activity1 as follows:

and the export for deployment above is imported, the following versioning will result:

Design-time Concepts – Activities

An activity represents the actual item of work that is to be performed by a task. Activities are defined independently of processes and can be shared across processes (with some limitations, see below). WfMS defines two types of activities, system activities which are performed by the WfMS in their entirety and interactive activities which require user interaction in order to be completed.

System Activities

System activities are defined by server side scripts. Each system activity contains a single script which is loosely bound to the process definition. This has the following implications:

· A script can refer directly to any process attributes within its logic and these can be both read and written.

· A script’s knowledge of process attribute names is implicit. No mapping is provided. This knowledge is implied rather than enforced since activities can be shared.

· If a script makes a reference to a process attribute that does not exist or performs any other type of illegal operation, a process runtime failure will occur. Therefore script development is an integral part of process development. This implies that process development can be considered as more of an IT task as opposed to a business task.

The ability to execute a script as a part of a process provides a lot of power. For example, a script could perform any or all of the following:

· Send an email

· Read or write data to or from a database

· Call a web service

· Perform complex logic which can then be fed back into the process and used to control conditional process steps

Some of these may require access to Ebase external resources and mappings between the resource fields and the process attributes. This is done in exactly the same way as for Ebase form fields using resources grouped in a business view.

In addition to the script, a system activity can also define a set of Completion States. A system activity can set the completion state from it’s implementing script by setting the value of the $COMPLETION_STATE system attribute.

Interactive Activities

Interactive activities are typically performed by a person interacting with a system other than the WfMS. They are typically started by an application such as the Task List. For example, Albert the loans manager has a task list application running which shows him the loan applications which have reached the FINANCE_CHECK task and require his authorization. He can pick one of these tasks off the list and open it which should take him automatically into an authorization form. This form is the interactive activity.

There can be many different types of interactive task such as: running an Ebase form, running an in-house web application, running a third party application and so on. Each of these will require a potentially very different set of information to even get connected to the external system on which the activity will be performed. For example, for an Ebase form, the minimum set of information required is the form name, the hostname on which the form is to run, the host port number and the host web application name. This information is encapsulated by an ActivityType implementation. Each activity is defined based on a selected ActivityType which provides it’s startup parameters by default.

In addition to the startup information, an interactive activity also encapsulates the following information:

· Input parameters – Data that needs to be supplied to an activity when it starts up.

· Output parameters – Data which is set as a result of the completion of an activity.

· Completion states – As for system activities, this is the list of state names which can be set to let the process know how this task completed. See Completion States for more details. In the case of interactive activities, the completion state must be set, along with the output parameters, when the task completion is signalled back to the WfMS via the Workflow Management API.

Both input and output parameter names are local to an activity definition. These will be mapped to process attributes when the activity is configured on a task in a process (see Interactive Tasks).

If the application on which the activity is to be performed is not accessible programmatically (i.e. it can not be launched automatically from another application), a manual ActivityType can be used which simply provides textual instructions to the user as to how to manually start up the third party application, perform the task and then enter the output parameter values and select a completion state.

The following diagram illustrates the interactions between the WfMS, the Task List application, and an example target application which, in this case, is an Ebase form (Note: This interaction is described in much more detail in the Workflow form integration section).

All interactions between the Task List application (or for that matter, any external application) and the WfMS are via the Workflow Management API.

ActivityType

Activity types are provided by implementing the ActivityType Java interface and declaring the implementing class in the UFSSetup.properties file.

ActivityType definitions also have the option to pre-define the input parameters, output parameters and completion states for an activity if they are constrained by (and available from) the target application. It may also provide a pre-configured or dynamically populated choice for values to be set in the startup parameters list.

WfMS provides three default ActivityTypes:

· CustomActivityType – this is the simplest possible implementation of the ActivityType interface and allows the activity designer to define whatever they wish with no restrictions.

· EbaseActivityType - this defines an activity which is based on an Ebase form. It defines the following:

o The startup parameters required, namely the form name, server host, server port and server web app.

o The choice of names available for the form name startup parameter. This is the list of forms available within the Ebase forms repository and which are declared to support workflow. This list is automatically offered as a drop-down menu in the activity designer when selecting a value for the form name.

o The input parameters, output parameters and completion states as defined on the workflow-enabled form. These are used to automatically populate the input/output/completions lists when a form is selected in the activity designer.

· ManualActivityType – This defines a more generic activity which can be presented using the WF_MANUAL_TASK Ebase form. This form will display an instruction to the user at the top of the page. This will be followed by a read-only table showing all input parameters.

Below this are two tables showing the output parameters and completion states (as defined in the activity). The individual enacting the activity can then manually set values or each of the output parameters, select a completion state and click the Finished button to complete the activity.

The workflow designer uses the ActivityType definitions to customize the activity designer screens according to the startup parameter definitions in the ActivityType.

Additional activity types can be provided by implementing the ActivityType interface and declaring the implementation in the system configuration file . (See Workflow Customization for more information)

Completion State ($COMPLETION_STATE)

A completion state serves as an indication to the remainder of the process of how this task completed. This could be as simple as “Succeeded” and “Failed” or more detailed, for example, “authorized”, “rejected”, “referred” etc. Subsequent tasks will have access to the completion state of this activity (via the $COMPLETION_STATE system attribute) and can make decisions based upon it.

Note: Completion state is not the same as the processing status of an enactment. These are discussed in more detail in Task Enactment Lifecycle.

When a completion state is set as a result of a task enactment being completed, the state is logged in the audit log and can be viewed using the workflow administration application.

Versioning, Deletion and Import/Export

These all work in the same way as for processes.

Design-time Concepts – Tasks

There are two types of task: System tasks and interactive tasks. They have the following properties in common:

1. Name – This is used to identify a task in the case it needs to be referred to in a script. It is not compulsory for all tasks to have names and neither must they be unique. In the majority of cases, the name is purely for ease of reference when viewing the process in the designer.

2. Description – This is a textual description used to aid identification of a particular task enactment. The description may contain embedded references to process attributes which will be populated at the time the description is read. For example, the FINANCE_CHECK interactive task in our original example could have the following description:

Loan finance check dated &&APPLICATION_DATE for &&APPLICANT_NAME requesting a loan of £&&AMOUNT

The &&APPLICATION_DATE , &&APPLICANT_NAME and &&AMOUNT are references to process attributes and will be substituted when the description is fetched and displayed in the task list application. So for Margaret’s application it would appear as:

Loan finance check dated 02/01/2006 for Margaret Wainright requesting a loan of £12,000

The loan manager browsing the task list can therefore identify the loan request easily.

Note: Descriptions also support multilingual text in the same manner as all other Ebase forms applications.

Design-time Concepts - System tasks

System tasks are simple in the sense that they are little more than the activity which defines them. For more details on the runtime behaviour of system tasks, see Task Enactments.

Design-time Concepts - Interactive tasks

Interactive tasks require considerably more configuration than System tasks. Aside from the task name, description, the actual activity with which they are associated, interactive tasks also require the following configuration:

Activity parameter mapping

Since activity input and output parameters are local to the activity, these need to be mapped to process attributes. Once this is set up, the WfMS will automatically pass the values of the mapped process attributes into the activity on initialization and then save the values of the activity’s output parameters into the corresponding mapped process attributes on completion.

Assigning Resources to Interactive Tasks

Since, by definition, an interactive task is one which is performed by a person, it is necessary to define who will be allowed to perform any given task. This is likely to depend on a company’s internal HR (human resources) structure, for example, perhaps any loan advisor in the Loans department is allowed to authorize a loan of less than £50,000 but for loans over £50,000 a further authorization is required from that particular loan advisor’s manager. This could be defined in a process as follows:

The assignment constraint defines which tasks will be visible on each individual’s task list. For example, if Gilbert is a member of the Loans department, tasks assignable to the Loans department will be visible on his task list and he will be allowed to open a task and enact it. Whereas Derek in the Savings department will not even see the BASIC_AUTHORISATION tasks as they are created.

The assignment configuration for a task offers some standard assignment modes. These are:

· Public – this is a non-authenticated assignment mode. It may only be used for the first task in any process and represents, say an application form submitted by a member of the general public.

· Job opener – this automatically assigns the task to the same resource who opened the job.

· Resource from previous task – this automatically assigns the task to the same individual who completed the selected previous task.

· Process attribute – this automatically assigns the task to a resource named in a process attribute.

· Named resource – this automatically assigns the task to the resource named in the configuration.

· Follow-on task – this automatically assigns the task to the resource who completed the previous task in the same stream.

· Custom – this assigns the task either to an individual resource or to a pool of resources identified by a custom assignment expression. The custom assignment expression is free to be defined by the organization using the WfMS. Custom assignment may cover things like assignment to the manager of an individual or, assignment to anyone from the Loans department. Implementation of the custom assignment feature is described in detail in the Workflow Customization section.

The custom assignment mode is special in that it can work in two different ways:

1. Assignment to an individual – In this case the custom assignment expression resolves to an individual resource to which the task can be immediately assigned.

2. Assignment to a pool – In this case the custom assignment expression resolves to a collection (or pool) of resources. This could be the name of a department, a role or just a list of possible individuals. In this case, when a person who belongs to the pool views their task list, they will not only see tasks which are explicitly assigned to them but also tasks which are available to them as a member of the pool. The person may then “take” the task which means that the task will then be assigned to them and will no longer be visible on the task lists of other pool members.

In general, all assignment modes ought to be supported by a separate validation step which checks whether the individual being assigned is, at a bare minimum, a member of the organization who is actually allowed to perform this task. This is important since assigning a task to someone who is not part of the organization will mean that the task will never appear on anyone’s task list and will never be executed! This validation step is left to the customization of the resource management interface. For more details see Workflow Customization.

Security

In addition to task assignment, it is also important to be able to check whether a person actually has the authority to perform, or even to view a specific task. For example, Gerald, a loan manager may only be allowed to view tasks or jobs regarding loans for which he is registered as the job owner. If Gerald uses the workflow administration application to try to view all loan application task enactments, only those tasks which are visible to him as the job owner will be displayed. Alternatively, Gerald may be allowed to view all loan application task enactments but only be allowed to modify, assign, cancel etc, task enactments for which he is the job owner.

A security constraint can be defined for an entire process but may be overridden at the task level where required.

Defining task security is another customization activity and is defined by a Java implementation of the SecurityHandler interface. This is discussed in more detail in the Workflow Customization section.

Priorities

Each task has a priority represented by an integer. This priority is not used in job execution by the WfMS and is provided only to assist client applications to prioritize tasks. For example, the Task List application may wish to present task enactments in descending order of priority. An initial (default) priority can be assigned to the task via the process designer. Thereafter it can be adjusted using Workflow API calls to meet the requirement of client applications. The default workflow administration application also allows for task priorities to be modified.

Priority numbers may also be mapped to a friendly name, for example, 1=critical, 2=high, 3=medium, 4=low. This is done by creating a static list which maps integers to names and configuring it as the WfMS’s priority mappings list (See Workflow Configuration for more details).

Design-time Concepts – Process Routing Steps

As well as tasks - described in the previous section, a process can also contain routing steps that are used to control the execution paths of a process. Any conditional logic associated with routing steps is implemented as a server side script. This provides a means of both supplying the conditional logic and resolving references to process context variables.

Split/Join

A split represents a point in the process execution path where two or more paths are to be executed concurrently. There is no scripted logic associated with a split as all split paths will always be activated.

All paths of a split must meet at a corresponding join point (See Process Structure Restrictions).

Decisions

Decisions are controlled using server side scripts. The only difference from a regular script as used in the system activity definitions is that the goal of a decision script is to set the value of the $NEXT_STEP system variable to the name of one of the links coming out of the decision node.

The logic used to decide which value to set $NEXT_STEP to can be dependant on any of the process attributes or system attributes available on the process.

If an error is found during execution of the decision script or, for some reason, the value of $NEXT_STEP has not been set, the node will be put in the failed state. There is no option to correct a decision script during runtime since this would involve the release of a new version of the process. It is therefore very important to test each decision thoroughly before releasing a process into the live environment.

Design-time Concepts – Pause Node

A Pause Node causes the process execution path to stop until some external event completes. Pause Nodes are primarily intended to be used to integrate external services that do not have the ability to connect to the WfMS; however they can also be used to integrate with forms, workflow sub-processes, other workflow jobs etc within an Ebase system.

Each Pause Node contains a script which is run each time the node is posted. If the script sets system variable $PAUSE_COMPLETED to value 'Y', the node completes and the process execution continues with the next node. Otherwise the node remains in the Paused state.

A Pause Node can be posted using either or both of the following:

· Scheduling: the node’s script is executed at regular intervals, which can be specified as daily or a specific number of hours or minutes. This allows the script to repeatedly check for some external event e.g. database data, existence of a file etc. When setting the scheduling interval, it should be borne in mind that the script will be executed for each active job in the system. So if there are 200 active jobs and the scheduling interval is the minimum – 1 minute – the script will be executed 200 times each minute. This might result in an unacceptable load on an external system. Please also see the paragraph below discussing errors when checking external systems.

· Explicitly by command: using the FPL workflow post command or one of the workflow API post() methods. These statements provide two variants, each one requires the event id associated with the Pause Node. The first variant requires a job id, whereas the second variant allows specification of process attribute values that uniquely identify a particular job. See workflow FPL command or workflow API.post().

If an error is found during execution of a Pause Node’s script, the node will be put in the failed state. Therefore, when checking external systems, precautions should be taken against intermittent failures such as inaccessibility of a database system. This can be achieved using the NOFAIL option which is available with a number of FPL commands, or with and API based language using try {} catch {} syntax to catch errors.

Runtime Concepts

This section discusses in more detail the elements involved when running a process. It will cover Node Enactments, jobs and sub-jobs.

Node Enactments

A node enactment is a single execution of a process node. Enactments are created for all node types: tasks, routing steps and sub-processes. Each enactment goes through a lifecycle of states which depend on the type of node.

The following states are supported by all node enactments:

Live states (those which may occur while an enactment is still live)

Active: the task is in the process of being run by the WfMS or has been opened by a person who is enacting it manually.

End states (those which signal the end of an enactment’s lifecycle)

Completed: indicates that the task has been enacted through to completion successfully.
Note: This is not the same as saying that the task has completed with a successful completion state. The completion state is independent of the lifecycle state and shows the outcome of the task activity, for example, the loan has been approved.
Failed: indicates that a technical problem has occurred during execution of the task. Once the cause of the problem has been corrected, the task can be re-executed. This is the only time it is possible to return from an end state.
Skipped: this state is set if an enactment has failed irrecoverably and the administrator wants to just force the process to continue regardless of the failure.

Interactive task enactments may additionally take on any of the following states:

Live states

Unassigned: the enactment has been created but a resource has not yet been assigned.
Waiting: a resource has been assigned. The task is now ready to be opened.
Paused: a state that allows the user to pause an activity and then resume. For a Pause Node, this is a normal state and indicates that the node is waiting. For other node types, this is more of a marker to show to an administrator that the task has been intentionally paused.

End states

Cancelled: indicates that the task has been cancelled from active state. Note that it is possible to cancel either an individual task or an entire job. Cancelling an individual task is only possible if the task is marked as cancellable at design time – job execution then continues with the next task or condition. Cancelling a job is always possible, even when the active task is not marked as cancellable.

Enactment Lifecycles

The lifecycle for all enactments other than interactive task enactments is very simple. An enactment is normally created by the WfMS with state Active and is executed immediately. The normal sequence of state transitions will be:

Active -> Any valid end state

Once the activity has completed, the WfMS will automatically transition the enactment to the appropriate end state.

Since Interactive tasks are executed by a person, possibly with the assistance of an IT application, when the WfMS creates an instance of a task as part of job execution, the task will initially be put in state Waiting or Unassigned depending on whether or not a resource has been automatically assigned. All subsequent state transitions are signalled through the Workflow API. The normal sequence of state transitions will be:

Unassigned -> Waiting -> Active -> Any valid end state

In both cases, the WfMS monitors invoked enactments for technical failures (such as loss of database connectivity) and will set the task state to Failed if this occurs. If this happens, in general, the problem causing the failure will need to be corrected and the task re-executed. In most cases this will be possible, however if the problem is an error in the process design itself, a new version of the process will need to be released in order for any changes to be made available and these changes will only be available to new jobs. So in the case of a design error, it will not be possible to re-execute a failed node.

Any activity associated with an interactive task must be workflow aware in that it must signal transition to an appropriate end state by means of the Workflow Management API.

Parallel Processing

If a job contains a split node which splits the processing into multiple paths which each result in the execution of system tasks, these tasks will be executed in parallel (if a multi-processor environment is available) by the WfMS and the order of execution will not be predictable. Therefore there can be no interdependencies between such tasks. Processing beyond the Join node will not continue until all incoming paths have completed.

Escalations

Escalations are provided so that a workflow process can be annotated with actions that should be taken should some part of the process not be completed within some desired timescale. Each individual escalation is actually just another workflow sub-process (see Sub-processes). The workflow designer can include whatever is needed in escalation sub-processes but the most likely actions are such things as:

A system task that raises the priority of the associated task in the main process
A system task that alerts the owner of the Job that some task has not been completed.

Each escalation includes three important pieces of information:

The escalated node which is the workflow node, completion of which will cancel any future enactment of the escalation process.
The trigger node which is the workflow node whose enactment will start the process of timing of an escalation. The escalation may be triggered by the trigger node either being started or completed.
The time that should elapse before the escalation process is enacted.

The timeout for an escalation process may be expressed in a number of different ways and may represent an absolute time (e.g. 10 days) or a day relative to a local calendar (e.g. 15 working days). It can also be set dynamically using a process attribute.

Apart from the fact that an escalation sub-process is automatically enacted by the WfMS when necessary, there is nothing special about such enactments: they’re mostly like ordinary sub-processes. The escalation itself, though, has a slightly different lifecycle from that used by conventional enactments and which has already been described.

The state model for escalator enactments looks like this:

· When an escalator enactment is created, it is in the waiting state. An escalator is assigned in the same manner as a normal interactive task enactment and it is the responsibility of the defined Assignment Handler to do this assignment. The assigned actor for an escalator is the person who will see the pending escalators in their task list as the escalator counts down its timeout period before firing.

In the case where the escalated node is an interactive task, it is possible to declare that the assignment details for an escalator are inherited from the escalated node. In this way the target actor and assignment expression are declared to be simply the same as those for the escalated node. This is not possible for other types of node so explicit assignment criteria need to be specified.
When an escalators fires (that is, its timeout expires) it transitions to the active state when the associated sub-process is enacted in the usual way.
Once the subprocess completes the escalator enactment transitions to completed.
If the escalated node, or its containing job, is cancelled then any outstanding escalator enactments (those existing in either the waiting or the active states) are also placed into the cancelled state.
If the escalated node completes, any extant escalators for that node are placed into the skipped state.

Integration with Ebase Forms

WfMS provides full integration with Ebase forms to allow forms applications to be used to open a job on a process or act as interactive activities. There are two aspects to this integration: invoking operations and finding workflow entities to invoke the operations on.

Invoking operations

In order to open jobs, assign tasks, complete tasks and so on, it is necessary to be able to invoke operations on workflow entities. This is done using an extensive set of workflow scripting statements including:

· open job

· open task

· assign task

· complete task

(See Workflow Form Integration for the complete set of commands)

Finding workflow entities

To assist in finding outstanding tasks, jobs and processes, a set of custom resources have been implemented which make use of the filtering methods available on the Workflow Management API. To demonstrate the use of these resources, two sample applications are provided:

· the task list application: this displays a list of outstanding task enactments which are assigned or assignable to the user logged in to the application. This uses the WorkflowTaskList custom resource implementation in the workflow custom resources package. It enables the user to select a task and assign it to themselves or open it.

· the workflow administration application: this is a more complex application which displays fully filterable lists of processes, jobs, task enactments and audit records. Along with the WorkflowTaskList custom resource, this application also makes use of the WorkflowProcessesList, WorkflowJobsList and WorkflowAuditList custom resource implementations. For each workflow entity type, the application enables the user to perform all available actions on that entity, for example, quiesce or activate a process, re-assign a task enactment, re-execute a failed node enactment or cancel a job.

For further details on general development using Ebase see Working with Forms

For further details on the use of custom resources see Working with Custom Resources.

Job and task ids

Throughout the workflow system, job ids and task ids are used to uniquely identify a job or a node enactment respectively. The formats of these ids is shown below.

Job Id

“JOB” : Process Name : Process Version : Job Sequence

Where..

Process Name is the name of the process

Process Version is the version of the process used for the job i.e. the latest released version when the job was created

Job Sequence is a sequential number incremented each time a new job is created

e.g.

JOB:LOAN_APPLICATION:25:11

JOB:HIRE_CAR_PROCESS:5:101

When a job is created with FPL command workflow open job or workflow start job, the job id is available as system variable $WF_JOB_ID. The job id is returned by the corresponding API methods Workflow.openJob() and Workflow.openJobAndCompleteFirstTask().

When a job is executing, the job id is available to system tasks or decision nodes as system variable $JOB_ID.

Task Id

“JOB” : Process Name : Process Version : Job Sequence: Node Enactment Sequence

Where..

Process Name is the name of the process

Process Version is the version of the process used for the job i.e. the latest released version when the job was created

Job Sequence is a sequential number incremented each time a new job is created

Node Enactment Sequence is a sequential number incremented each time a new node is created for the job

e.g.

TASK:LOAN_APPLICATION:25:11:1

TASK:HIRE_CAR_PROCESS:5:101:16

When a form is running under workflow control, the task id is available as system variable $WF_TASK_ID.