Overview of Workflow within Productions
This chapter provides an overview of workflow features in InterSystems IRIS®. It discusses the following topics:
A workflow management system automates the distribution of tasks among users. Automating the distribution of tasks according to a predefined strategy makes task assignment more efficient and task execution more accountable. A typical example is a help desk application that accepts problem reports from customers, routes the reports to members of the appropriate organizations for action, and upon resolution of the problem, reports the results to the customer.
The InterSystems IRIS Workflow Engine provides a much higher level of functionality than traditional, stand-alone workflow management systems, as the next subsections explain.
Integration into InterSystems IRIS
The InterSystems IRIS Workflow Engine takes full advantage of the InterSystems IRIS architecture. As a result, it can seamlessly interoperate with enterprise applications, technology, and data, as well as human participants. Highlights of this collaboration include the following:
“Straight-through” business processes (that is, completely automated business processes) can incorporate human involvement to handle exception cases, such as approval for especially large orders.
An InterSystems IRIS workflow can call out to enterprise applications: to notify them of events within the human workflow, or to obtain additional information needed by the human workflow.
Persistence: The Workflow Engine leverages InterSystems IRIS persistent storage features to support long-running business processes that may take days or weeks to complete.
Support for Composite Applications
InterSystems IRIS provides a richly stocked development environment that allows developers to easily create composite applications that span disparate systems and technologies across the enterprise. Because the Workflow Engine is fully integrated within InterSystems IRIS:
Composite applications can easily incorporate complex manual interactions that reach across geographical, technological, and departmental divisions.
User-based process definitions can be separated from business logic, allowing developers and analysts to define each segment distinctly within a cohesive whole.
Workflow systems are more versatile, more powerful, easier to create, and simpler to maintain.
The InterSystems IRIS Workflow Engine provides automatic integration with productivity tools such as the following:
Business Process Designer: Workflow analysts can create workflows using the Business Process Designer, the InterSystems IRIS graphical editing tool that automatically generates full-fledged, working code from a business process diagram.
Business Activity Monitoring: Developers can easily create corporate dashboards and event triggers to display current workflow status to enterprise analysts.
Visual Trace: All tasks are sent as messages, so system administrators can view the status of tasks using the powerful Visual Trace message tracing tool.
Workflow Components in a Production
The following figure shows workflow components in a production:
A workflow process is a BPL process that sends task requests to workflow operations. This process is responsible for coordinating work among these workflow operations. It might also invoke standard business operations (that is, ones that do not require human intervention). Both types of element may be required to complete the business process.
A workflow operation is a special-purpose business operation that represents a workflow role (discussed in the next heading). The workflow operation sends tasks, via the Workflow Inbox, to all users who belong to the associated role.
A workflow process sends a task request to a workflow operation in exactly the same way as business processes send other kinds of request messages to other kinds of business operation.
In InterSystems IRIS terms, a workflow task is an item of work that is performed offline in support of an ongoing business process. InterSystems IRIS represents a task with a special-purpose production message object called a task request that carries information about that work. The workflow process sends task requests and receives task responses. As with all other messages, these messages are saved in the database until purged (if ever).
Workflow Roles and Users
In a typical organization, multiple people might be able to fulfill a certain kind of task. Therefore, to organize distribution of tasks to people, InterSystems IRIS uses workflow roles. A workflow role is a list of users that can fulfill a certain kind of task.
In theory, there may be any number of workflow roles defined within an enterprise. In practice, roles map to departments or job positions within in the enterprise, such as Accounting, Finance, Teller, Manager, Supervisor, or Director.
Any number of workflow users may be members of a workflow role. Assignment of users to roles should make sense from a practical and organizational standpoint. If a person is authorized to perform a task, that person should be a member of the corresponding workflow role.
Workflow roles are defined per interoperability-enabled namespace, not per production. This means that the same workflow role definitions are available to all the productions in the same interoperability-enabled namespace. The same is true for workflow users when they correspond to InterSystems IRIS user accounts (as is typically done).
User Interfaces for Workflow
InterSystems IRIS now provides two user interfaces to support workflow. These are intended for different sets of users.
Implementers and Supervisors
The Management Portal provides pages that implementers and supervisors can use to manage workflow roles, users, and tasks. To access them, select Interoperability, click Manage, and then click Workflow.
These pages are not meant for end users. Supervisors can assign or cancel tasks, but other actions (such as marking tasks complete) are not available here.
For details, see “Managing Workflow Roles, Users, and Tasks” in Managing Productions.
Users manage their workflow tasks within the InterSystems User Portal, which also displays InterSystems IRIS dashboards (and Analytics dashboards). The InterSystems User Portal is accessible from the Management Portal, but it is more likely that your application would provide a link directly to it. (Also note that the User Portal does not have a title; it is suitably generic for all users.)
For an InterSystems IRIS workflow user, the main area of the User Portal displays the Workflow Inbox. For example:
When the user clicks Workflow Inbox, the User Portal displays something like the following:
When a user clicks a task, the system displays the corresponding task form, which you can configure or customize. For example:
For details, see “Using the Portal Features” in the Using Dashboards and the User Portal.
Life Cycle of a Task
The life cycle of a task within a production is as follows:
A workflow process receives some input and then creates a task request (a message).
The workflow process sends the task request to a workflow operation.
The workflow operation submits the task request to the Workflow Engine.
The Workflow Engine instantiates the appropriate task response object. This object includes the fields from the original task request, and oversees task distribution to some user.
Task distribution follows either the default strategy or a custom distribution strategy. See “Task Distribution Options,” later in this chapter, for details.
Once the task is assigned and completed, the Workflow Engine returns the task response to the business process.
Task Forms and Customization Options
The InterSystems User Portal (mentioned earlier) provides a Workflow Inbox for each user. When a user clicks a task, the system displays a form that is specific to that task. You can customize this form, as follows:
The form is generated from metadata, which may be contained within reusable template files or defined at runtime by enterprise staff.
The form is easily styled to fit within corporate standards.
If the enterprise wishes to use in-house technologies to drive the user experience, InterSystems IRIS workflow tasks can be exposed to such technologies in a variety of ways, via XML documents, web services, .NET, Java, or as relational structures.
Task Distribution Options
When a workflow operation receives a task request, it turns the request over to the InterSystems IRIS Workflow Engine to distribute the task to one of the users defined for that role. The strategy used to distribute tasks can be the InterSystems IRIS default, which works as follows:
For each workflow user, there is a worklist that lists all the tasks currently assigned to or associated with that user. Only active tasks for the specific user appear on the worklist. Once the task is completed, discarded, cancelled, or reassigned to another user, it disappears from the list.
The Workflow Engine posts any task requests that it receives on the worklist for each user in the workflow role to which the request was sent. When a task is first posted, it has the status Unassigned. The task is said to be associated with all these users. While it remains Unassigned, each of the associated users sees the task on his or her worklist.
It is possible for a user to acquire ownership of a task through assignment by a supervisor, or by default, but in general the user must accept the task to acquire ownership. Any user in the workflow role can accept any task on his or her worklist, on a first-come, first-served basis, using the Workflow Inbox.
Once a user has acquired ownership of a task, the task is said to be assigned to that user. The status of the task changes from Unassigned to Assigned. The task remains in the Workflow Inbox for the user who accepted it, but disappears from the Workflow Inboxes of the other users in that workflow role.
A task request has a property that allows it to express a preference for a specific user. If that user is inactive or not defined at the time the task request is received, the Workflow Engine returns an error to the workflow operation and the task is not performed.
A supervisor can reassign an active task from the workflow pages of Management Portal. In this case, the task leaves the worklist for the previously assigned user and appears on the worklist for the newly assigned user.
The assigned user may relinquish a task without completing it. If a user relinquishes a task unfinished, the task reverts to its original Unassigned status, and the Workflow Engine posts it to the Workflow Inbox for each associated user (each user in the workflow role).
If a supervisor deletes a user definition or marks a user inactive while workflow is proceeding, the result is the same as if that user suddenly relinquished all of his or her tasks. That is, each task that was on the user’s worklist acquires an Unassigned status, and the Workflow Engine posts each task on the Workflow Inbox of every user in the workflow role to which the task was originally sent.
If a supervisor deletes a workflow role definition while workflow is proceeding, outstanding requests to that role are allowed to complete, but future requests to that role cause an error, due to a mismatch between the workflow operation name and the (nonexistent) role definition name.
Each task request specifies one or more actions. Each action is a string that the associated task form displays as a button: Accept, Relinquish, and so on. The assigned user can click one of these buttons to complete the task and send a response back to the business process.
When the assigned user clicks an action button for a task, the Workflow Engine fills in the various properties of the task response object — including the name of the user-selected action — and returns this response to the workflow operation, which relays it to the original requesting business process. The Workflow Engine marks the task Completed and removes it from all worklists.
After completion, a full record of any task remains in the message warehouse for the production, and are visible from the Management Portal. Task details relating directly to workflow are visible from the Workflow Management Portal. This is true even if the message was not properly completed, but was discarded or cancelled, or encountered an error.
The strategy used to distribute tasks is embedded in the OnNewTask() method of the task response class EnsLib.Workflow.TaskResponse. You can subclass this class and the methods to change the logic, if desired. For instructions, see the chapter “Including Custom Features in a Workflow.”
Custom Task Distribution
Workflow designers can make use of a wide variety of task distribution strategies within a workflow definition. The following strategies are built into the InterSystems IRIS Workflow Engine:
First come, first served (FCFS)
Assignment by job title
Assignment by name
Assignment by a user-defined ranking
Assignment by current user workload
It is also possible to create new, custom task distribution strategies.