This chapter provides an overview of workflow features in Ensemble. 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 Ensemble Workflow Engine provides a much higher level of functionality than traditional, stand-alone workflow management systems, as the next subsections explain.
The Ensemble Workflow Engine takes full advantage of the Ensemble 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:
business processes (that is, completely automated business processes) can incorporate human involvement to handle exception cases, such as approval for especially large orders.
An Ensemble 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 Ensemble persistent storage features to support long-running business processes that may take days or weeks to complete.
Ensemble 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 Ensemble:
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 Ensemble 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 Ensemble 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.
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 Ensemble terms, a workflow task
is an item of work that is performed offline in support of an ongoing business process. Ensemble represents
a task with a special-purpose Ensemble 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).
In a typical organization, multiple people might be able to fulfill a certain kind of task. Therefore, to organize distribution of tasks to people, Ensemble 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 Ensemble namespace, not per production. This means that the same workflow role definitions are available to all the productions in the same Ensemble namespace. The same is true for workflow users when they correspond to Ensemble user accounts (as is typically done).
Ensemble now provides two user interfaces to support workflow. These are intended for different sets of users.
The Management Portal provides pages that implementers and supervisors can use to manage workflow roles, users, and tasks. To access them, select Ensemble
, 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.
Users manage their workflow tasks within the DeepSee User Portal, which also displays Ensemble dashboards (and DeepSee dashboards). The DeepSee 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 Ensemble 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:
The life cycle of a task within an Ensemble 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.
Once the task is assigned and completed, the Workflow Engine returns the task response to the business process.
The DeepSee 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, Ensemble workflow tasks can be exposed to such technologies in a variety of ways, via XML documents, Web services, .NET, Java, C++ objects, or as relational structures.
When a workflow operation receives a task request, it turns the request over to the Ensemble Workflow Engine to distribute the task to one of the users defined for that role. The strategy used to distribute tasks can be the Ensemble 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.
Workflow designers can make use of a wide variety of task distribution strategies within a workflow definition. The following strategies are built into the Ensemble Workflow Engine:
First come, first served (FCFS)
Assignment by a user-defined ranking
Assignment by current user workload
It is also possible to create new, custom task distribution strategies.