Skip to main content

Developing a Workflow

This topic describes how to develop a workflow and add it to a production. Optional customizations are described separately.

Exploring the Workflow Sample presents a simple example.

Overview

The following diagram shows workflow elements in a production:

classes for workflow operations already exist. you must create classes for the workflow process

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.

  • A workflow process that serves as the coordinator of the communications. To create this:

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

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

  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.

  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.

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 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 an InterSystems IRIS® web 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:

  1. Display the production in the Interoperability > Configure > Production page of the Management Portal.

  2. In the Processes column, select the Add button (a plus sign).

    InterSystems IRIS 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 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 Interoperability > Configure > Production page of the Management Portal.

  2. In the Operations column, select the Add button (a plus sign).

    InterSystems IRIS displays a dialog box.

  3. Select the Workflow tab.

  4. Select the EnsLib.Workflow.OperationOpens in a new tab 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 select Auto-Create Role. If enabled, this option causes InterSystems IRIS to automatically create a workflow role whose name is identical to Operation Name.

    You can enable this setting later, if wanted.

  7. Select OK.

For information on other settings, see Configuring Productions.

Next Steps

FeedbackOpens in a new tab