27 Getting Started with Human Workflow

This chapter describes for developers the human workflow concepts, features, and architecture. Use cases for human workflow are provided. Instructions for designing your first workflow from start to finish are also provided.

This chapter includes the following sections:

27.1 Introduction to Human Workflow

Many end-to-end business processes require human interactions with the process. For example, humans may be needed for approvals, exception management, or performing activities required to advance the business process. The human workflow component provides the following features:

  • Human interactions with processes, including 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 (human activity)

  • Presentation of tasks to end users through a variety of mechanisms, including a worklist application (Oracle BPM Worklist)

  • 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

Figure 27-1 provides an overview of human workflow.

Figure 27-1 Human Workflow

High-level view of workflow services.
Description of "Figure 27-1 Human Workflow"

In Figure 27-1, the following actions occur:

  • A BPEL process invokes a special activity of the human task type when it needs a human to perform a task.

  • This creates a task in the human task service component. The process waits for the task to complete. It is also possible for the process to watch for other callbacks from the task and react to them.

  • There is metadata associated with the task that is used by the human task service component to manage the lifecycle of the task. This includes specification of the following:

    • Who performs the task. If multiple people are required to perform the task, what is the order?

    • Who are the other stakeholders?

    • When must the task be completed?

    • How do users perform the task, what information is presented to them, what are they expected to provide, and what actions can they take?

  • The human task service component uses an identity directory, such as LDAP, to determine people's roles and privileges.

  • The human task service component presents tasks to users through a variety of channels, including the following:

    • Oracle BPM Worklist, a role-based application that supports the concept of supervisors and process owners, and provides functionality for finding, organizing, managing, and performing tasks.

    • Worklist functionality is also available as portlets that can be exposed in an enterprise portal.

    • Notifications can be sent by email, phone, SMS, and other channels. Email notifications can be actionable, enabling users to perform actions on the task from within the email client without connecting to Oracle BPM Worklist or Oracle WebLogic Server.

    For information about portlets, see

27.2 Introduction to Human Workflow Concepts

This section introduces you to key human workflow design time and runtime concepts. This section also provides an overview of the three main stages of human workflow design.

27.2.1 Introduction to Design and Runtime Concepts

Before designing a human task, it is important to understand the design and runtime concepts. A typical task consists of a subject, priority, task participants, task parameters or data, deadlines, notifications or reminders, and task forms. This section provides an overview of key concepts.

Note:

Human workflow design-time tasks are performed in a graphical editor known as the Human Task Editor. The tutorial in describes how to use this editor.

27.2.1.1 Task Assignment and Routing

Human workflow supports declarative assignment and routing of tasks. In the simplest case, a task is assigned to a single participant (user or group). However, there are many situations in which more detailed task assignment and routing is necessary (for example, when a task must be approved by a management chain or worked and voted on by a set of people in parallel, as shown in Figure 27-2). Human workflow provides declarative, pattern-based support for such scenarios.

Figure 27-2 Participants in a Task

Description of Figure 27-2 follows
Description of "Figure 27-2 Participants in a Task"

27.2.1.1.1 Participant

A participant is a user or set of users in the assignment and routing policy definition. In Figure 27-2, each block with an icon representing people is a participant.

27.2.1.1.2 Participant Type

In simple cases, a participant maps to a user, group, or role. However, as discussed in Section 27.2.1.1, "Task Assignment and Routing," workflow supports declarative patterns for common routing scenarios such as management chain and group vote.The following participant types are available:

  • Single approver

    This is the simple case where a participant maps to a user, group, or role.

    For example, a vacation request is assigned to a manager. The manager must act on the request task three days before the vacation starts. If the manager formally approves or rejects the request, the employee is notified with the decision. If the manager does not act on the task, the request is treated as rejected. Notification actions similar to the formal rejection are taken.

  • Parallel

    This participant indicates that a set of people must work in parallel. This pattern is commonly used for voting.

    For example, multiple users in a hiring situation must vote to hire or reject an applicant. You specify the voting percentage that is needed for the outcome to take effect, such as a majority vote or a unanimous vote.

  • Serial

    This participant indicates that a set of users must work in sequence. While working in sequence can be specified in the routing policy by using multiple participants in sequence, this pattern is useful when the set of people is dynamic. The most common scenario for this is management chain escalation, which is done by specifying that the list is based on a management chain within the specification of this pattern.

  • FYI (For Your Information)

    This participant also maps to a single user, group, or role, just as in single approver. However, this pattern indicates that the participant just receives a notification task and the business process does not wait for the participant's response. FYI participants cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.

    For example, a regional sales office is notified that a candidate for employment has been approved for hire by the regional manager and their candidacy is being passed onto the state wide manager for approval or rejection. FYIs cannot directly impact the outcome of a task, but in some cases can provide comments or add attachments.

For more information, see Section 29.4, "Assigning Task Participants."

27.2.1.1.3 Participant Assignment

A task is work that must be done by a user. When you create a task, you assign humans to participate in and act upon the task. Participants can perform actions upon tasks during runtime from Oracle BPM Worklist, such as approving a vacation request, rejecting a purchase order, providing feedback on a help desk request, or some other action. There are three types of participants:

  • Users

    You can assign individual users to act upon tasks. For example, you may assign users jlondon or jstein to a particular task. Users are defined in an identity store configured with the SOA Infrastructure. These users can be in the embedded LDAP of Oracle WebLogic Server, Oracle Internet Directory, or a third party LDAP directory.

  • Groups

    You can assign groups to act upon tasks. Groups contain individual users who can claim and act upon a task. For example, users jcooper and fkafka may be members of the group LoanAgentGroup that you assign to act upon the task.

    As with users, groups are defined in the identity store of the SOA Infrastructure.

  • Application roles

    You can assign users who are members of application roles to claim and act upon tasks.

    Application roles consist of users or other roles grouped logically for application-level authorizations. These roles are application-specific and are defined in the application Java policy store rather than the identity store. These roles are used by the application directly and are not necessarily known to a Java EE container.

    Application roles define policy. Java permissions can be granted to application roles. Therefore, application roles define a set of permissions granted to them directly or indirectly through other roles (if a role is granted to a role). The policy can contain grants of application roles to enterprise groups or users. In the jazn-data.xml file of the file-based policy store, these roles are defined in <app-role> elements under <policy-store> and written to system-jazn-data.xml at the farm level during deployment. You can also define these roles after deployment using Oracle Enterprise Manager Fusion Middleware Control. You can set a task owner or approver to an application role at design time if the role has been previously deployed.

For more information about Oracle BPM Worklist, see Section 27.2.1.6, "Task Forms."

27.2.1.1.4 Ad Hoc Routing

In processes dealing with significant variance, you cannot always determine all participants. Human workflow enables you to specify that a participant can invite other participants as part of performing the task.

For more information, see Section 29.5.1.1, "Allowing All Participants to Invite Other Participants."

27.2.1.1.5 Outcome-based Completion of Routing Flow

By default, a task goes from starting to final participant according to the flow defined in the routing policy (as shown in Figure 27-2). However, sometimes a certain outcome at a particular step within a task's routing flow makes it unnecessary or undesirable to continue presenting the task to the next participants. For example, if an approval is rejected by the first manager, it does not need to be routed to the second manager. Human workflow supports specifying that a task or subtask be completed when a certain outcome occurs.

For more information, see Section 29.5.1.2, "Stopping Routing of a Task to Further Participants."

27.2.1.2 Static, Dynamic, and Rule-Based Task Assignment

There are different methods for assigning users, groups, and application roles to tasks.

  • Assign tasks statically

    You can assign users, groups, and application roles statically (or by browsing the identity service). The values can be either of the following:

    • A single user, group, or application role (for example, jstein, CentralLoanRegion, or ApproverRole).

    • A delimited string of users, groups, or application roles (for example, jstein, wfaulk, cdickens).

  • Assign tasks dynamically

    You can assign users, groups, and application roles dynamically in the following ways:

    • By using a task-assignment pattern. This pattern enables you to do the following:

      • Simply enable participants to claim the task manually. This is the default behavior. No task-assignment pattern is applied.

      • If the participant type is either Single or FYI, then apply a task-assignment pattern to select a single assignee of a requested type from all potential assignees in the participant.

        For example, suppose that the potential assignees comprise the user jcooper, the group LoanAgent, and the application role Developers. Suppose further that the requested type is user. Applying this task-assignment pattern selects a single user from the user jcooper, and from all members of the group LoanAgent, and from all users with the application role Developers.

      • If the particulates type is Parallel or Serial, then apply a task-assignment pattern to select a single assignee of a requested type from each of the potential assignees in the participant.

        For example, suppose that the potential assignees comprise the user jcooper, the group LoanAgent, and the application role Developers. Suppose further that the requested type is user. Applying this task-assignment pattern selects the user jcooper, and one user from the group LoanAgent, and one user with the application role Developers.

    • By using XPath expressions. These expressions enable you to dynamically determine assignment to users not included in the participant type. Here you create a list of potential assignees, one of whom must then claim the task.

      For example, you may have a business requirement to create a dynamic list of task approvers specified in a payload variable. The XPath expression can resolve to zero or more XML nodes. Each node value can be either of the following:

      • A single user, group, or application role

      • A delimited string of users, groups, or application roles. The default delimiter for the assignee delimited string is a comma (,).

      For example, if the task has a payload message attribute named po within which the task approvers are stored, you can use the following XPath expression:

      • /task:task/task:payload/po:purchaseOrder/po:approvers

      • ids:getManager('jstein', 'jazn.com')

        This returns the manager of jstein.

      • ids:getReportees('jstein', 2, 'jazn.com')

        This returns all reportees of jstein up to two levels.

      • ids:getUsersInGroup('LoanAgentGroup', false, 'jazn.com')

        This returns all direct and indirect users in the group LoanAgentGroup.

    You can use both options simultaneously—for example, you can use an XPath expression to dynamically select a group, and then apply a task-assignment pattern to dynamically select a user from that group.

  • Assign tasks with business rules

    You can create the list of task participants with complex expressions. The result of using business rules is the same as using XPath expressions.

27.2.1.3 Task Stakeholders

A task has multiple stakeholders. Participants are the users defined in the assignment and routing section of the task definition. These users are the primary stakeholders that perform actions on the task.

In addition to the participants specified in the assignment and routing policy, human workflow supports additional stakeholders:

  • Owner

    This participant has business administration privileges on the task. This participant can be specified as part of the task definition or from the invoking process (and for a particular instance). The task owner can act upon tasks they own and also on behalf of any other participant. The task owner can change both the outcome of the task and the assignments.

    For more information, see Section 29.2.7, "How to Specify a Task Owner" to specify an owner in the Human Task Editor or to specify an owner in the Advanced tab of the Human Task dialog.

  • Initiator

    The person who initiates the process (for example, the initiator files an expense report for approval). This person can review the status of the task using initiated task filters. Also, a useful concept is for including the initiator as a potential candidate for request-for-information from other participants.

    For more information, see

  • Reviewer

    This participant can review the status of the task and add comments and attachments.

  • Admin

    This participant can view all tasks and take certain actions such as reassigning a test, suspending a task to handle errors, and so on. The task admin cannot change the outcome of a task.

    While the task admin cannot perform the types of actions that a task participant can, such as approve, reject, and so on, this participant type is the most powerful because it can perform actions such as reassign, withdraw, and so on.

  • Error Assignee

    When an error occurs, the task is assigned to this participant (for example, the task is assigned to a nonexistent user). The error assignee can perform task recovery actions from Oracle BPM Worklist, the task form in which you perform task actions during runtime.

    For more information, see Section 29.5.4, "How to Configure the Error Assignee."

27.2.1.4 Task Deadlines

Human workflow supports the specification of deadlines associated with a task. You can associate the following actions with deadlines:

  • Reminders:

    The task can be reminded multiple times based on the time after the assignment or the time before the expiration.

  • Escalation:

    The task is escalated up the management hierarchy.

  • Expiration:

    The task has expired.

  • Renewal:

    The task is automatically renewed.

For more information, see Section 29.7, "Escalating, Renewing, or Ending the Task."

27.2.1.5 Notifications

You can configure your human task to use notifications. Notifications enable you to alert interested users to changes in the state of a task during the task lifecycle. For example, a notification is sent to an assignee when a task has been approved or withdrawn.

You can specify for notifications to be sent to different types of participants for different actions. For example, you can specify the following:

  • For the owner of a task to receive a notification message when a task is in error (for example, been sent to a nonexistent user).

  • For a task assignee to receive a notification message when a task has been escalated.

You can specify the contents of the notification message and the notification channel to use for sending the message.

  • Email

    You can configure email notification messages to be actionable, meaning that a task assignee can act upon a task from within the email.

  • Voice message

  • Instant messaging (IM)

  • Short message service (SMS)

For example, you may send the message shown in Example 27-1 by email when a task assignee requests additional information before they can act upon a task:

Example 27-1 Email Message

For me to approve this task, more information is required to justify the need
 for this business trip

During runtime, you can mark a message sender's address as spam and also display a list of bad or invalid addresses. These addresses are automatically removed from the bad address list.

For more information about notifications, see the following:

27.2.1.6 Task Forms

Task forms provide you with a way to interact with a task. Oracle BPM Worklist displays all worklist tasks that are assigned to task assignees in the task form. When you drill down into a specific task, the task form displays the contents of the task to the user's worklist. For example, an expense approval task may show a form with line items for various expenses, and a help desk task form may show details such as severity, problem location, and so on.

The integrated development environment of Oracle SOA Suite includes Oracle Application Development Framework (Oracle ADF) for this purpose. With Oracle ADF, you can design a task form that depicts the human task in the SOA composite application.

ADF-based task forms can be automatically generated. Advanced users can design their own task forms by using ADF data controls to lay out the content on the page and connect to the workflow service engine at execution time to retrieve task content and act on tasks.

You can create task forms in JSF, .NET, or any other client technologies using the APIs.

Integration with Microsoft Excel for initiating and acting on tasks is also provided.

For more information, see the following:

27.2.1.7 Advanced Concepts

This section describes advanced human workflow concepts.

27.2.1.7.1 Rule-based Routing

You can use Oracle Business Rules to dynamically alter the routing flow. If used, each time a participant completes their step, the associated rules are invoked and the routing flow can be overridden from the rules.

For more information, see Section 29.5.2, "How to Specify Advanced Task Routing Using Business Rules."

27.2.1.7.2 Rule-based Participant Assignment

You can use Oracle Business Rules to dynamically build a list of users, groups, and roles to associate with a participant.

For more information, see Section 29.4, "Assigning Task Participants."

27.2.1.7.3 Stages

A stage is a way of organizing the approval process for blocks of participant types. You can have one or more stages in sequence or in parallel. Within each stage, you can have one or more participant type blocks in sequence or in parallel.

For more information, see Section 29.4, "Assigning Task Participants."

27.2.1.7.4 Access Rules

You can specify access rules that determine the parts of a task that assignees can view and update. For example, you can configure the task payload data to be read by assignees. This action enables only assignees (and nobody else) to have read permissions. No one, including assignees, has write permissions.

For more information, see Section 29.9.1, "How to Specify Access Policies on Task Content."

27.2.1.7.5 Callbacks

While human workflow supports detailed behavior that can be declaratively specified, in some advanced situations, more extensible behavior may be required. Task callbacks enable such extensibility; these callbacks can either be handled in the invoking BPEL process or a Java class.

For more information, see Section 29.11.1, "How to Specify Callback Classes on Task Status."

27.2.1.8 Reports and Audit Trails

Oracle BPM Worklist provides several out-of-the-box reports for task analysis:

  • Unattended tasks

    Analysis of tasks assigned to users' groups or reportees' groups that have not yet been acquired.

  • Tasks priority

    Analysis of tasks assigned to a user, reportees, or their groups, based on priority.

  • Tasks cycle time

    Analysis of the time taken to complete tasks from assignment to completion based on users' groups or reportees' groups.

  • Tasks productivity

    Analysis of assigned tasks and completed tasks in a given time period for a user, reportees, or their groups.

  • Tasks time distribution

    The time an assignee takes to perform a task.

You can view an audit trail of actions performed by the participants in the task and a snapshot of the task payload and attachments at various points in the workflow. The short history for a task lists all versions created by the following tasks:

  • Initiate task

  • Reinitiate task

  • Update outcome of task

  • Completion of task

  • Erring of task

  • Expiration of task

  • Withdrawal of task

  • Alerting of task to the error assignee

For more information, see

27.2.2 Introduction to the Stages of Human Workflow Design

Human workflow modeling consists of three stages of modeling, as described in Table 27-1.

Table 27-1 Stages of Human Workflow Modeling

Step Description For More Information...

1

You create and define contents of the human task in the Human Task Editor, including defining a participant type, routing policy, escalation and expiration policy, notification, and so on.

 

2

You associate the human task definition with a BPEL process. The BPEL process integrates a series of activities (including the human task activity) and services into an end-to-end process flow.

 

3

You create a task form. This form displays the task details on which you act at runtime in Oracle BPM Worklist.

 

27.3 Introduction to Human Workflow Features

This section provides an introduction to use cases for human workflow. After that, a tutorial guides you through the design of a human task from start to finish.

27.3.1 Human Workflow Use Cases

The following sections describe multiple use cases for workflow services.

27.3.1.1 Task Assignment to a User or Role

A vacation request process may start with getting the vacation details from a user and then routing the request to their manager for approval. User details and the organizational hierarchy can be looked up from a user directory or identity store. This scenario is shown in Figure 27-3.

Figure 27-3 Assigning Tasks to a User or Role from a Directory

Assigning tasks in workflow.
Description of "Figure 27-3 Assigning Tasks to a User or Role from a Directory"

27.3.1.2 Use of the Various Participant Types

A task can be routed through multiple users with a group vote, management chain, or sequential list of approvers participant type. For example, consider a loan request that is part of the loan approval flow. The loan request may first be assigned to a loan agent role. After a specific loan agent acquires and accepts the loan, the loan may be routed further through multiple levels of management if the loan amount is greater that $100,000. This scenario is shown in Figure 27-4.

Figure 27-4 Flow Patterns and Routing Policies

Description of Figure 27-4 follows
Description of "Figure 27-4 Flow Patterns and Routing Policies"

You can use these types as building blocks to create complex workflows.

27.3.1.3 Escalation, Expiration, and Delegation

A high-priority task can be assigned to a certain user or role based on the task type through use of custom escalation functions. However, if the user does not act on it in a certain time, the task may expire and in turn be escalated to the manager for further action. As part of the escalation, you may also notify the users by email, telephone voice message, or SMS. Similarly, a manager may delegate tasks from one reportee to another to balance the load between various task assignees. All tasks defined in BPEL have an associated expiration date. Additionally, you may specify escalation or renewal policies, as shown in Figure 27-5. For example, consider a support call, which is part of a help desk service request process. A high-priority task may be assigned to a certain user, and if the user does not respond in two days, the task is routed to the manager for further action.

Figure 27-5 Escalation and Notification

Escalation and notification
Description of "Figure 27-5 Escalation and Notification"

27.3.1.4 Automatic Assignment and Delegation

A user may decide to have another user perform tasks on their behalf. Tasks can be explicitly delegated from the Oracle BPM Worklist or can be automatically delegated. For example, a manager sets up a vacation rule saying that all their high priority tasks are automatically routed to one of their direct reports while the manager is on vacation. In some cases, tasks can be routed to different individuals based on the content of the task. Another example of automatic routing is to allocate tasks among multiple individuals belonging to a group. For example, a help desk supervisor decides to allocate all tasks for the western region based on a round robin basis or assign tasks to the individual with the lowest number of outstanding tasks (the least busy).

27.3.1.5 Dynamic Assignment of Users Based on Task Content

An employee named James in the human resources department requests new hardware that costs $5000. The company may have a policy that all hardware expenses greater than $3000 must go through manager and vice president approval, and then review by the director of IT. In this scenario, the workflow can be configured to automatically determine the manager of James, the vice president of the human resources department, and the director of IT. The purchase order is routed through these three individuals for approval before the hardware is purchased.

27.4 Introduction to Human Workflow Architecture

This section provides an overview of human workflow architecture. The following topics are discussed:

  • The services that perform a variety of operations in the lifecycle of a task, such as querying tasks for a user, retrieving metadata information related to a task, and so on.

  • The two ways to use a human task:

    • Associated with a BPEL process service component

    • Used in standalone mode

  • The role of the service engine in the life of a human task

27.4.1 Human Workflow Services

Starting with release 11g, all human task metadata is stored and managed in the Metadata Service (MDS) repository. The workflow service consists of many services that handle various aspects of human interaction with a business process.

Figure 27-6 shows the following workflow service components:

  • Task Service:

    The task service provides task state management and persistence of tasks. In addition to these services, the task service exposes operations to update a task, complete a task, escalate and reassign tasks, and so on. The task service is used by Oracle BPM Worklist to retrieve tasks assigned to users. This service also determines if notifications are to be sent to users and groups when the state of the task changes. The task service consists of the following services.

    • Task Routing Service

      The task routing service offers services to route, escalate, and reassign the task. The service makes these decisions by interpreting a declarative specification in the form of the routing slip.

    • Task Query Service

      The task query service queries tasks for a user based on a variety of search criterion such as keyword, category, status, business process, attribute values, history information of a task, and so on.

    • Task Metadata Service

      The task metadata service exposes operations to retrieve metadata information related to a task.

  • Identity Service

    The identity service is a thin web service layer on top of the Oracle Application Server 11g security infrastructure or any custom user repository. It enables authentication and authorization of users and the lookup of user properties, roles, group memberships, and privileges.

  • Notification Service

    The notification service delivers notifications with the specified content to the specified user through any of the following channels: email, telephone voice message, IM, and SMS. See for more information.

  • User Metadata Service

    The user metadata service manages metadata related to workflow users, such as user work queues, preferences, vacations, and delegation rules.

  • Runtime Config Service

    The runtime config service provides methods for managing metadata used in the task service runtime environment. It principally supports management of task payload mapped attribute mappings.

  • Evidence service

    The evidence service supports storage and nonrepudiation of digitally-signed workflow tasks.

Figure 27-6 Workflow Services Components

Description of Figure 27-6 follows
Description of "Figure 27-6 Workflow Services Components "

Figure 27-7 shows the interactions between the services and the business process.

Figure 27-7 Workflow Services and Business Process Interactions

Description of Figure 27-7 follows
Description of "Figure 27-7 Workflow Services and Business Process Interactions"

27.4.2 Use of Human Task

There are two ways in which to use a human task:

  • Human task associated with a BPEL process

    In most cases, you associate your human task with a BPEL process. The BPEL process integrates a series of activities (including the human task activity) and services into an end-to-end process flow.

  • Standalone human task

    You can also create the human task as a standalone component only in the SOA Composite Editor and not associate it with a BPEL process. Standalone human task service components are useful for environments in which there is no need for any automated activity in an application. In the standalone case, the client can create the task themselves.

27.4.3 Service Engines

During runtime, the business logic and processing rules of the human task service component are executed by the human workflow service engine. Each service component (BPEL process, human workflow, decision service (business rules), and Oracle Mediator) has its own service engine container for performing these tasks. All human task service components, regardless of the SOA composite application of which they are a part, are executed in this single human task service engine.

For more information about configuring, monitoring, and managing the human workflow service engine, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.