Developing a Workflow
This chapter describes how to develop a workflow and add it to a production. The next chapter provides details on optional customizations you can perform during development.
This chapter includes the following topics:
The appendix “Exploring the Workflow Sample” presents a simple example, available within the ENSDEMO namespace.
Overview
The following diagram shows workflow elements in a production:
These components are as follows, from left to right:
-
A message request class carries the specific details of the workflow from its originator elsewhere in the production. This is a standard message request class that you define, that is, a subclass of Ens.RequestOpens in a new tab or some (less often) another persistent class.
-
A message response class carries the specific details of the workflow back to the originator, once the task has been completed or otherwise handled. This is a standard message response class that you define, that is, a subclass of Ens.ResponseOpens in a new tab or some (less often) another persistent class.
This book does not provide any special details on defining this class or the corresponding request class, because the implementation is completely dependent on your needs.
-
A workflow process that serves as the coordinator of the communications. To create this:
-
Use the Business Process Designer and create a business process based on the class Ens.BusinessProcess.BPL. It must contain the logic to receive the inbound messages and to call (asychronously) to business operations in the same production, as needed.
-
Add the business process to the production as usual.
-
-
A special message class EnsLib.Workflow.TaskRequestOpens in a new tab carries requests from the business process.
Likewise, the special message class EnsLib.Workflow.TaskResponseOpens in a new tab carries replies from the Workflow Engine.
You can create and use subclasses, but that is not generally necessary, because these classes are designed to carry information in a flexible manner.
-
Each workflow operation receives task requests and communicates with the Workflow Engine, which makes tasks visible to specific users. In particular, each workflow operation has exactly one associated workflow role. The workflow operation makes tasks visible to all users who belong to that workflow role; other users do not see these tasks.
To create each of these, you add a business operation based on EnsLib.Workflow.OperationOpens in a new tab. Little configuration is needed.
Or you can subclass EnsLib.Workflow.OperationOpens in a new tab and implement its callback methods to interact with the Workflow Engine in a custom way.
Designing the Business Process
The first step is to design the business process class and make some key decisions.
-
Identify where calls to workflow (human processes) will occur.
-
Each of these calls is a task; name each task.
-
Name each workflow role to which a task is sent.
-
Decide on a task distribution strategy for each task (perhaps the default strategy).
-
Create any message types needed to invoke the business process.
This book does not provide any special details on defining these messages, because the implementation is completely dependent on your needs.
-
Create the business process class as described in the next section.
Creating the Workflow Process
To create the workflow process, use the Business Process Designer as described in Developing BPL Processes.
For each task in the business process:
-
Provide a <call> to invoke the workflow operation asynchronously.
-
In the <call> identify the destination workflow operation by name. Each workflow operation is associated with exactly one workflow role, which in turn corresponds to a configurable set of users.
-
In the <call> use the correct task request object (EnsLib.Workflow.TaskRequestOpens in a new tab or a subclass) and sets its properties.
The <call> should also examine the task response object (EnsLib.Workflow.TaskResponseOpens in a new tab or a subclass), and use it to set the BPL context variable for use in later processing.
-
Provide a <sync> to catch the results of the asynchronous <call>.
For an example, see the appendix “Exploring the Workflow Sample.”
Defining the Task Request
Each <call> in the process should use EnsLib.Workflow.TaskRequestOpens in a new tab or a subclass as its message class. To define the request, the <call> should set properties of the callrequest variable.
The following table lists the available properties in EnsLib.Workflow.TaskRequestOpens in a new tab. These properties are all optional, but of course your business process must send all the information that the Workflow Engine needs.
Property | Purpose |
---|---|
%Actions | Optional. Comma-delimited list of Actions defined for this task. For example: "Approve,Reject,NeedMoreInfo" These determine the action buttons displayed when a user reviews a task. The selected user action is returned as part of the task response. |
%Command | Optional. Command string to be passed to the Workflow Engine. You can use this to provide additional data-driven custom behavior for tasks. |
%FormTemplate | Optional. Name of a Caché Server Pages (CSP) page that provides the HTML form template for this task. |
%FormFields | Optional. Comma-separated list of fields that should appear in the form associated with this task. |
%FormValues | Optional. Collection of values to display within the form displayed for this task. |
%Message | Optional. Detailed message body for this task. This is displayed when the user reviews a task. |
%Priority | Optional. Priority of the requested task: 1 is highest. This value is used to sort items in the user worklist. |
%Subject | Optional. Short summary of this task. This is displayed in the User worklist. |
%TaskHandler | Optional. Name of response class that is used to manage the distribution of this task. It is also used as the response type for this request. The class named in %TaskHandler must be a subclass of EnsLib.Workflow.TaskResponseOpens in a new tab. |
%Title | Optional. The name of the title within the given that is preferred for handling this task. Whether or not this user actually is assigned to the task depends on how the distribution strategy used for this task. |
%UserName | Optional. The name of the user that is preferred for handling this task. Whether or not this user actually is assigned to the task depends on how the distribution strategy used for this task. |
Using the Task Response
As noted earlier, the <call> for a given task should also examine the task response object (EnsLib.Workflow.TaskResponseOpens in a new tab or a subclass), and use it to set the BPL context variable for use in later processing. EnsLib.Workflow.TaskResponseOpens in a new tab defines the following properties:
Property | Purpose |
---|---|
%Action | Optional. Once the task is complete, this property will contain the value of the action that the user selected to complete the task. See %Actions. |
%Actions | Optional. A comma-delimited list of actions defined for this task. For example: "Approve,Reject,NeedMoreInfo" These determine the action buttons displayed when a user reviews a task. The selected user action is returned in the %Action property of the task response. |
%FormFields | Optional. Comma-separated list of fields that should appear in the form associated with this task. This is a copy of the value provided from the initial task request. |
%FormTemplate | Optional. Name of the CSP page that provides the form template for this task. This is a copy of the value provided from the initial task request. |
%FormValues | Optional. A collection of values from the form associated with this task (if any). |
%Message | Optional. Detailed message body for this task. This is a copy of the value provided from the initial task request. |
%Priority | Optional. The priority of the requested task: 1 is highest. This is a copy of the value provided from the initial task request. |
%RoleName | Optional. The name of the role that handled this task. This is a copy of the value provided from the initial task request. |
%Status | Optional. The external status of this task. Used to query the current status of a task. |
%Subject | Optional. Short summary of this task. This is a copy of the value provided from the initial task request. |
%TaskStatus | Optional. The internal status of this task (Assigned, Unassigned, Cancelled, Discarded, Deleted). Used by the Workflow Engine to manage the task. Custom code should not modify the value of this property. |
%UserName | Optional. The name of the user that last handled this task. This value is set when the task is completed. |
%UserRanking | Optional. The ranking associated with the user that last handled this task (if the user has a role-assigned ranking). |
%UserTitle | Optional. The title associated with the user that last handled this task (if the user has a role-assigned title). |
Adding the Workflow Process to the Production
To add the workflow process to a production, do the following:
-
Display the production in the Ensemble, Production Configuration page of the Management Portal. To access this page, click Ensemble, click Configure, click Production, and then click Go.
-
In the Processes column, click the Add button (a plus sign).
Ensemble displays a dialog box.
-
For Business Process Class, select the class you created in the Business Process Editor.
-
For Process Name, type a suitable name.
-
Click OK.
For information on other settings, see Configuring Ensemble Productions.
Adding the Workflow Operations to a Production
To add a workflow operation to a production, do the following:
-
Display the production in the Ensemble, Production Configuration page of the Management Portal. To access this page, click Ensemble, click Configure, click Production, and then click Go.
-
In the Operations column, click the Add button (a plus sign).
Ensemble displays a dialog box.
-
Click the Workflow tab.
-
Select the EnsLib.Workflow.OperationOpens in a new tab class from the Class Name list.
Or select your custom subclass.
-
For Operation Name, type the name of this business operation. The name must match the target attribute in the corresponding <call> from the BPL business process.
-
Optionally click Auto-Create Role. If enabled, this option causes Ensemble to automatically create a workflow role whose name is identical to Operation Name.
You can enable this setting later, if wanted.
-
Click OK.
For information on other settings, see Configuring Ensemble Productions.
Next Steps
-
Associate workflow users with the appropriate workflow roles. See “Managing Workflow Roles, Users, and Tasks” in Managing Ensemble.
-
Test the workflow as described in the chapter “Testing a Workflow.”
-
Optionally add a dashboard so supervisors can monitor workflow progress. Ensemble automatically collects certain workflow metrics. The general development and configuration tasks are as usual:
-
Create one or more business metric classes. See “Defining Business Metrics” in Developing Ensemble Productions.
Each class can invoke methods of the class EnsLib.Workflow.EngineOpens in a new tab, which provides methods that report statistics about workflow roles.
For quick reference, these are listed in the appendix “Available Workflow Metrics.”
-
When configuring the production, add each business metric as a business service.
-
Define dashboards. See “Defining Dashboards” in Configuring Ensemble Productions.
-