Introduction to Human Workflow 11g
- by agiovannetti
Human Workflow is a component of SOA Suite just like BPEL, Mediator, Business Rules, etc. The Human Workflow component allows you to incorporate human intervention in a business process.
You can use Human Workflow to create a business process that requires a manager to approve purchase orders greater than $10,000; or a business process that handles article reviews in which a group of reviewers need to vote/approve an article before it gets published. Human Workflow can handle the task assignment and routing as well as the generation of notifications to the participants.
There are three common patterns or usages of Human Workflow:
1) Approval Scenarios: manage documents and other transactional data through approval chains . For example: approve expense report, vacation approval, hiring approval, etc.
2) Reviews by multiple users or groups: group collaboration and review of documents or proposals. For example, processing a sales quote which is subject to review by multiple people.
3) Case Management: workflows around work management or case management. For example, processing a service request. This could be routed to various people who all need to modify the task. It may also incorporate ad hoc routing which is unknown at design time.
SOA 11g Human Workflow includes the following features:
Assignment and routing of tasks to the correct users or groups.
Deadlines, escalations, notifications, and other features required for ensuring the timely performance of a task.
Presentation of tasks to end users through a variety of mechanisms, including a Worklist application.
Organization, filtering, prioritization and other features required for end users to productively perform their tasks.
Reports, reassignments, load balancing and other features required by supervisors and business owners to manage the performance of tasks.
Human Workflow Architecture
The Human Workflow component is divided into 3 modules: the service interface, the task definition and the client interface module. The Service Interface handles the interaction with BPEL and other components. The Client Interface handles the presentation of task data through clients like the Worklist application, portals and notification channels. The task definition module is in charge of managing the lifecycle of a task. Who should get the task assigned? What should happen next with the task? When must the task be completed? Should the task be escalated?, etc
Stages and Participants
When you create a Human Task you need to specify how the task is assigned and routed. The first step is to define the stages and participants. A stage is just a logical group. A participant can be a user, a group of users or an application role. The participants indicate the type of assignment and routing that will be performed.
Stages can be sequential or in parallel. You can combine them to create any usage you require. See diagram below:
Assignment and Routing
There are different ways a task can be assigned and routed:
Single Approver: task is assigned to a single user, group or role. For example, a vacation request is assigned to a manager. If the manager approves or rejects the request, the employee is notified with the decision. If the task is assigned to a group then once one of managers acts on it, the task is completed.
Parallel : task is assigned to a set of people that must work in parallel. This is commonly used for voting. For example, a task gets approved once 50% of the participants approve it. You can also set it up to be a unanimous vote.
Serial : participants must work in sequence. The most common scenario for this is management chain escalation.
FYI (For Your Information) : task is assigned to participants who can view it, add comments and attachments, but can not modify or complete the task.
Task Actions
The following is the list of actions that can be performed on a task:
Claim : if a task is assigned to a group or multiple users, then the task must be claimed first to be able to act on it.
Escalate : if the participant is not able to complete a task, he/she can escalate it. The task is reassigned to his/her manager (up one level in a hierarchy).
Pushback : the task is sent back to the previous assignee.
Reassign :if the participant is a manager, he/she can delegate a task to his/her reports.
Release : if a task is assigned to a group or multiple users, it can be released if the user who claimed the task cannot complete the task. Any of the other assignees can claim and complete the task.
Request Information and Submit Information : use when the participant needs to supply more information or to request more information from the task creator or any of the previous assignees.
Suspend and Resume :if a task is not relevant, it can be suspended. A suspension is indefinite. It does not expire until Resume is used to resume working on the task.
Withdraw : if the creator of a task does not want to continue with it, for example, he wants to cancel a vacation request, he can withdraw the task. The business process determines what happens next.
Renew : if a task is about to expire, the participant can renew it. The task expiration date is extended one week.
Notifications
Human Workflow provides a mechanism for sending notifications to participants to alert them of changes on a task. Notifications can be sent via email, telephone voice message, instant messaging (IM) or short message service (SMS).
Notifications can be sent when the task status changes to any of the following:
Assigned/renewed/delegated/reassigned/escalated
Completed
Error
Expired
Request Info
Resume
Suspended
Added/Updated comments and/or attachments
Updated Outcome
Withdraw
Other Actions (e.g. acquiring a task)
Here is an example of an email notification:
Worklist Application
Oracle BPM Worklist application is the default user interface included in SOA Suite. It allows users to access and act on tasks that have been assigned to them. For example, from the Worklist application, a loan agent can review loan applications or a manager can approve employee vacation requests.
Through the Worklist Application users can:
Perform authorized actions on tasks, acquire and check out shared tasks, define personal to-do tasks and define subtasks.
Filter tasks view based on various criteria.
Work with standard work queues, such as high priority tasks, tasks due soon and so on. Work queues allow users to create a custom view to group a subset of tasks in the worklist, for example, high priority tasks, tasks due in 24 hours, expense approval tasks and more.
Define custom work queues.
Gain proxy access to part of another user's tasks.
Define custom vacation rules and delegation rules.
Enable group owners to define task dispatching rules for shared tasks.
Collect a complete workflow history and audit trail.
Use digital signatures for tasks.
Run reports like Unattended tasks, Tasks productivity, etc.
Here is a screenshoot of what the Worklist Application looks like. On the right hand side you can see the tasks that have been assigned to the user and the task's detail.
References
Introduction to SOA Suite 11g Human Workflow Webcast
Note 1452937.2 Human Workflow Information Center
Using the Human Workflow Service Component 11.1.1.6
Human Workflow Samples
Human Workflow APIs Java Docs
