Developing a Workflow

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.

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

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

• Associate workflow users with the appropriate workflow roles. See Managing Workflow Roles, Users, and Tasks.

• Test the workflow as described in Testing a Workflow.

• Optionally add a dashboard so supervisors can monitor workflow progress. InterSystems IRIS automatically collects certain workflow metrics. The general development and configuration tasks are as usual:

  1. Create one or more business metric classes. See Defining Business Metrics.

     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 Available Workflow Metrics.

  2. When configuring the production, add each business metric as a business service.

  3. Define dashboards. See Defining Dashboards in Configuring Productions.