Defining Workflows
Developing a Workflow
[Back] [Next]
   
Server:docs2
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

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:
Designing the Business Process
The first step is to design the business process class and make some key decisions.
  1. Identify where calls to workflow (human processes) will occur.
  2. Each of these calls is a task; name each task.
  3. Name each workflow role to which a task is sent.
  4. Decide on a task distribution strategy for each task (perhaps the default strategy).
  5. 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.
  6. 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:
For an example, see the appendix Exploring the Workflow Sample.”
Defining the Task Request
Each <call> in the process should use EnsLib.Workflow.TaskRequest 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.TaskRequest. 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.TaskResponse.
%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.TaskResponse or a subclass), and use it to set the BPL context variable for use in later processing. EnsLib.Workflow.TaskResponse 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:
  1. 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.
  2. In the Processes column, click the Add button (a plus sign).
    Ensemble displays a dialog box.
  3. For Business Process Class, select the class you created in the Business Process Editor.
  4. For Process Name, type a suitable name.
  5. 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:
  1. 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.
  2. In the Operations column, click the Add button (a plus sign).
    Ensemble displays a dialog box.
  3. Click the Workflow tab.
  4. Select the EnsLib.Workflow.Operation class from the Class Name list.
    Or select your custom subclass.
  5. 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.
  6. 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.
  7. Click OK.
For information on other settings, see Configuring Ensemble Productions.
Next Steps