27 Getting Started with Human Workflow

This chapter introduces 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:

For information about composite sensors, see Chapter 47, "Defining Composite Sensors."

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

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 Section 27.3.2, "Designing a Human Task from Start to Finish" 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 28.3.6, "How to Assign 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 permission 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 Console. 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 28.3.7.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 28.3.7.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 using XPath expressions. These expressions enable you to dynamically determine the task participants at runtime. 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.

  • 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 28.3.4.6, "Specifying a Task Owner" to specify an owner in the Human Task Editor or Section 28.4.4.2, "Specifying a Task Owner" to specify an owner in the Advanced tab of the Create 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 Section 28.4.3.2, "Specifying the Task Initiator and Task Priority."

  • 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 28.3.7.4, "Configuring 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 28.3.9, "How to Escalate, Renew, or End 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 life cycle. 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

In order for me to approve this task, I need more information 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.

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 28.3.7.2, "Specifying 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 be associated with a participant.

For more information, see Section 28.3.6, "How to Assign 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 28.3.6, "How to Assign 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 28.3.11.1, "Specifying 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 28.3.14.1, "Specifying 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 Chapter 30, "Using Oracle BPM Worklist."

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.

Section 28.2.1, "Create a Human Task Definition."

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.

Section 28.2.2, "Associate the Human Task Definition with a BPEL Process."

3

You create a task form. This form is used for displaying the task details on which you act at runtime in Oracle BPM Worklist.

Section 28.2.3, "Generate the Task Form."


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.3.2 Designing a Human Task from Start to Finish

This section guides you through design of your first human task.

This sample describes how an employee submits a vacation request that is automatically routed to their manager for approval. Once the manager responds (approved or rejected), a notification is sent to the employee.

This sample illustrates creation of a SOA composite application with two components:

  • A BPEL process

  • A human task, for approving a vacation request submitted by an employee

This example highlights the use of the following:

  • Using the SOA Composite Editor

  • Modeling a single approval workflow using Oracle BPEL Designer

  • Creating an Oracle ADF-based Oracle BPM Worklist

  • Using Oracle BPM Worklist to view and respond to the task

27.3.2.1 Prerequisites

This tutorial makes the following assumptions:

  • Oracle SOA Suite is installed on a host on which the SOA Infrastructure is configured.

  • You are familiar with basic BPEL constructs, including BPEL activities and partner links, and basic XPath functions. Familiarity with the SOA Composite Editor and Oracle BPEL Designer, the environment for designing and deploying BPEL processes, is also assumed.

  1. Create a file named VacationRequest.xsd with the following syntax. This file includes the schema for the vacation request and subsequent response.

    <schema attributeFormDefault="qualified" elementFormDefault="qualified"
            targetNamespace="http://xmlns.oracle.com/VacationRequest"
            xmlns="http://www.w3.org/2001/XMLSchema">
     <element name="VacationRequestProcessRequest">
      <complexType>
       <sequence>
        <element name="creator" type="string"/>
        <element name="fromDate" type="date"/>
        <element name="toDate" type="date"/>
        <element name="reason" type="string"/>
       </sequence>
      </complexType>
     </element>
     <element name="VacationRequestProcessResponse">
      <complexType>
       <sequence>
        <element name="result" type="string"/>
       </sequence>
      </complexType>
     </element>
    </schema>
    

    Note:

    The VacationRequest.xsd file is also available for download as part of tutorial workflow-100-VacationRequest. See Section 27.3.3, "Additional Tutorials" for information on downloading this and other tutorials.

27.3.2.2 How to Create the Vacation Request Process

In this tutorial, you create a new application and SOA project and design the human task to send a vacation request to a manager for approval or rejection. You also create a second application and project in which you create an Oracle ADF-based task form from which to act upon the vacation request.

27.3.2.2.1 Creating an Application and a Project with a BPEL Process

To create an application and a project with a BPEL process:

  1. Start Oracle JDeveloper.

  2. From the File main menu, select New > Applications > SOA Application.

  3. Click OK.

  4. In the Application Name field, enter VacationRequest, and click Next.

  5. In the Project Name field, enter VacationRequest, and click Next.

  6. In the Composite Template list, select Composite with BPEL, and click Finish.

  7. The Create BPEL Process dialog appears.

  8. In the Name field, enter VacationRequestProcess.

  9. Go to the bottom of the Create BPEL Process dialog.

  10. To the right of the Input field, click the Search icon.

    The Type Chooser dialog appears.

  11. In the upper right corner, click the Import Schema File icon.

    The Import Schema dialog appears.

  12. Browse for and select the VacationRequest.xsd file you created in Section 27.3.2.1, "Prerequisites."

  13. Click OK until you are returned to the Type Chooser dialog, as shown in Figure 27-6.

    Figure 27-6 Type Chooser Dialog with the Request and Response Elements

    Description of Figure 27-6 follows
    Description of "Figure 27-6 Type Chooser Dialog with the Request and Response Elements"

  14. Select the input element VacationRequestProcessRequest, and click OK.

    You are returned to the Create BPEL Process dialog.

  15. To the right of the Output field, click the Search icon.

  16. Select the output element VacationRequestProcessResponse, and click OK.

    You are returned to the Create BPEL Process dialog, as shown in Figure 27-7.

    Figure 27-7 BPEL Process Dialog

    Description of Figure 27-7 follows
    Description of "Figure 27-7 BPEL Process Dialog"

  17. Accept the default values for all other settings, and click OK.

    A BPEL process service component is created in the SOA Composite Editor. Because Expose as a SOAP service was selected in the Create BPEL Process dialog, the BPEL process is automatically connected with a service binding component. The service exposes the SOA composite application to external customers.

    Figure 27-8 BPEL Process in SOA Composite Editor

    Description of Figure 27-8 follows
    Description of "Figure 27-8 BPEL Process in SOA Composite Editor"

    For more information about service components and the SOA Composite Editor, see Chapter 2, "Developing SOA Composite Applications with Oracle SOA Suite."

27.3.2.2.2 Create the Human Task Service Component

You are now ready to create the human task service component in which you design your human task.

To create the human task service component:

  1. From the SOA list of the Component Palette, drag a Human Task into the SOA Composite Editor.

    The Create Human Task dialog appears.

  2. Enter the details described in Table 27-2.

    Table 27-2 Create Human Task Dialog Fields and Values

    Field Value

    Name

    Enter VacationRequestTask.

    Namespace

    Accept the default value.

    Create Composite Service with SOAP Bindings

    Do not select the checkbox. Instead, you create a human task that you later associate with the BPEL process you created in Section 27.3.2.2.1, "Creating an Application and a Project with a BPEL Process." The BPEL process was created with an automatically-bound web service.


  3. Click OK.

    The Human Task icon appears in the SOA Composite Editor above the BPEL process, as shown in Figure 27-9.

    Figure 27-9 Human Task Icon in SOA Composite Editor

    Description of Figure 27-9 follows
    Description of "Figure 27-9 Human Task Icon in SOA Composite Editor"

  4. Double-click the Human Task icon.

    The Human Task Editor appears. You are now ready to begin design of your human task.

27.3.2.2.3 Designing the Human Task

To design the human task:

  1. In the Task Title field, enter Request for Vacation.

  2. Accept the default values for outcomes (APPROVE and REJECT). For this task, these outcomes represent the two choices the manager has for acting on the vacation request.

  3. Click the Data tab on the left side of the editor.

  4. Click the Add icon to specify the task payload.

  5. Select Add string payload.

    The Add Task Parameter dialog is displayed. You now create parameters to represent the elements in your XSD file. This makes the payload data available to the workflow task.

  6. Select Element.

  7. To the right of the Element field, click the Search icon.

    The Type Chooser dialog appears.

  8. Expand and select Project Schema Files > VacationRequest.xsd > VacationRequestProcessRequest, and click OK. Figure 27-10 provides details.

    Figure 27-10 Type Chooser Dialog

    The Human Task window
    Description of "Figure 27-10 Type Chooser Dialog"

  9. Ensure that the Editable via worklist checkbox is selected. This provides you with the option to modify this parameter during runtime from Oracle BPM Worklist.

  10. Click OK on the Add Task Parameter dialog.

  11. Click the Assignment tab on the left side of the editor.

  12. Highlight the <Edit participant> box below Stage1, as shown in Figure 27-11.

    Figure 27-11 Assignment and Routing Policy

    Description of Figure 27-11 follows
    Description of "Figure 27-11 Assignment and Routing Policy"

  13. Click the Edit icon.

    The Edit Participant Type dialog appears. You now add participants to this task. As described in Section 27.2.1.1.2, "Participant Type," Oracle SOA Suite provides several out-of-the-box patterns known as participant types for addressing specific business needs.

  14. Accept the default participant type of Single that displays in the Type list. You select this type because a single assignee, the manager, acts on the vacation request task.

  15. In the Participant Names table, click the Add icon, and select Add User.

    This participant type acts alone on the task.

  16. Click the Data Type column, and select By Expression from the list that is displayed. Figure 27-12 provides details.

    This action enables the task to be assigned dynamically by the contents of the task. The employee filing the vacation request comes from the parameter passed to the task (the creator element in the XSD file you imported in Section 27.3.2.2.1, "Creating an Application and a Project with a BPEL Process"). The task is automatically routed to the employee's manager.

    Figure 27-12 Selection of By Expression from the Data Type Column

    Description of Figure 27-12 follows
    Description of "Figure 27-12 Selection of By Expression from the Data Type Column"

  17. In the Value column, click the Browse icon (the dots) to invoke the Expression Builder dialog.

  18. In the dropdown list in the Functions section, select Identity Service Functions.

  19. Select getManager. This function gets the manager of the user who created the vacation request task.

  20. Above the Functions section, click Insert into Expression.

  21. Place the cursor between the parentheses of the function.

  22. In the Schema section, expand task:task > task:payload > ns1:VacationRequestProcessRequest > ns1:creator.

    where ns1 is the namespace for this example; your namespace may be different.

  23. Click Insert into Expression.

    The Expression Builder dialog displays the XPath expression in the Expression section. Figure 27-13 provides details.

    Figure 27-13 XPath Expression

    Description of Figure 27-13 follows
    Description of "Figure 27-13 XPath Expression"

  24. Click OK to exit the Expression Builder dialog.

  25. From the File menu, select Save All.

  26. Click OK to exit the Add Participant Type dialog.

27.3.2.2.4 Associating the Human Task and BPEL Process Service Components

You are now ready to associate your human task with the BPEL process you created in Section 27.3.2.2.1, "Creating an Application and a Project with a BPEL Process."

To associate the human task and BPEL process service component:

  1. In the Application Navigator, double-click composite.xml.

  2. Double-click the VacationRequestProcess BPEL process service component in the SOA Composite Editor.

    The BPEL process displays in Oracle BPEL Designer.

  3. From the list at the top of the Component Palette, select BPEL.

  4. Expand BPEL Activities and Components.

  5. Drag a Human Task beneath the receiveInput receive activity.

    The Create Human Task dialog appears, as shown in Figure 27-14.

    Figure 27-14 Human Task Creation

    Description of Figure 27-14 follows
    Description of "Figure 27-14 Human Task Creation"

  6. From the Task Definition list, select the VacationRequestTask task you created (if it is not currently displaying).

    The dialog refreshes as shown in Figure 27-15 to display additional fields.

    Figure 27-15 Create Human Task Dialog

    Description of Figure 27-15 follows
    Description of "Figure 27-15 Create Human Task Dialog"

  7. In the BPEL Variable column, click the Browse icon (dots) shown in Figure 27-16 for the requester parameter.

    Figure 27-16 BPEL Variable Entry

    Description of Figure 27-16 follows
    Description of "Figure 27-16 BPEL Variable Entry"

    The Task Parameters dialog appears.

  8. From the Type list, select Variable.

  9. Expand Process > Variables > inputVariable > payload > ns1:VacationRequestProcessRequest. Figure 27-17 provides details.

    Figure 27-17 Variable Selection

    Description of Figure 27-17 follows
    Description of "Figure 27-17 Variable Selection"

  10. Click OK.

    When complete, the dialog looks as shown in Figure 27-18:

    Figure 27-18 BPEL Variable

    Description of Figure 27-18 follows
    Description of "Figure 27-18 BPEL Variable"

  11. Click OK to close the Create Human Task dialog.

    The human task activity and request and response partner links now appear.

    Figure 27-19 Human Task and Partner Links in Oracle BPEL Designer

    Description of Figure 27-19 follows
    Description of "Figure 27-19 Human Task and Partner Links in Oracle BPEL Designer"

  12. Return to the SOA Composite Editor and note that the BPEL process and human task service components have been automatically connected.

    Figure 27-20 SOA Composite Editor

    Description of Figure 27-20 follows
    Description of "Figure 27-20 SOA Composite Editor"

  13. From the File menu, select Save All.

27.3.2.2.5 Creating an Application Server Connection

You are now ready to create a connection to the application server on which Oracle SOA Suite is installed and configured with the SOA Infrastructure.

To create an application server connection

  1. From the File main menu, select New > Connections > Application Server Connection.

  2. Click OK.

  3. In the Connection Name field, enter a connection name.

  4. From the Connection Type list, select WebLogic 10.3.

  5. Click Next.

  6. In the Username field, enter weblogic.

  7. In the Password field, enter the password for connecting to the application server.

  8. Click Next.

  9. Enter the hostname for the application server that is configured with the SOA Infrastructure.

  10. In the Weblogic Domain field, enter the Oracle WebLogic Server domain.

  11. Click Next.

  12. Click Test Connection.

    If successful, the message shown in Figure 27-21 is displayed.

    Figure 27-21 Connection Success

    Description of Figure 27-21 follows
    Description of "Figure 27-21 Connection Success"

  13. Click Finish.

  14. From the File menu, select Save All.

27.3.2.2.6 Deploying the SOA Composite Application

You are now ready to deploy to the application server on which you created the connection.

To deploy the SOA composite application

  1. In the Application Navigator, right-click the VacationRequest project and select Deploy > VacationRequest > application_server_connection_name.

  2. Follow the pages of the deployment wizard to deploy the project.

    The project is deployed.

    For more information about deployment, see Section 41.7, "Deploying SOA Composite Applications."

27.3.2.2.7 Initiating the Process Instance

To initiate the process instance:

  1. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle BPM Suite for instructions on accessing the Test Web Service page for initiating the process instance.

27.3.2.2.8 Creating a Task Form Project

You are now ready to create a project for the task form. This is a separate project from the one in which you created the human task.

To create a task form project:

  1. Double-click the VacationRequestProcess BPEL process.

  2. Right-click the VacationRequestTask_1 human task activity in Oracle BPEL Designer.

  3. Select Auto-Generate Task Form.

    The Create Project dialog appears.

  4. In the Project Name field, enter VacationRequestTaskFlow, and click OK.

  5. From the File main menu, select Save All.

27.3.2.2.9 Acting on the Task in Oracle BPM Worklist

To resolve the task in Oracle BPM Worklist:

  1. Go to Oracle BPM Worklist:

    http://hostname:7001/integration/worklistapp
    
  2. Log in to Oracle BPM Worklist.

  3. Resolve the task.

27.3.2.2.10 Deploying the Task Form

To deploy the task form:

  1. In the Application Navigator, right-click the VacationRequestTaskFlow project and select Deploy > to > VacationRequestTaskFlow > application_server_connection_name.

  2. Follow the pages of the deployment wizard to deploy the task form.

    The task form is deployed.

    For more information about deployment, see Section 41.7, "Deploying SOA Composite Applications."

  3. Return to Oracle BPM Worklist.

  4. Note that the task form now appears at the bottom of Oracle BPM Worklist.

27.3.3 Additional Tutorials

In addition to the vacation request use case, other tutorials are available at the following URL:

http://www.oracle.com/technology/sample_code/products/hwf

Table 27-3 provides an overview of some samples. All samples show the use of worklist applications and workflow notifications. For the complete list of samples, visit the URL.

Table 27-3 End-to-End Examples

Sample Description Name

Vacation Request

Provides a sample in which a user submits a vacation request that gets assigned to their manager for approval or rejection. This sample also describes how to create Oracle ADF task forms for the vacation request to act on the task.

workflow-100-VacationRequest

Help Desk Request

Provides a simple workflow sample using Oracle ADF task forms for task approval.

workflow-101-HelpDeskRequest

Sales Quote Request

Provides a complex workflow sample with chaining of multiple tasks.

workflow-102-SalesQuote

Expense Application

Provides a sample that integrates workflow with Oracle ADF Business Components. Events are raised to the BPEL process and the human workflow is invoked for task approval.

workflow-103-ExpenseApp

Contract Approval

Provides a sample of approving a contract. This sample uses digital signatures for tasks.

workflow-104-ContractApproval

Document Workflow

Provides a sample in which a document is reviewed by a group of participants in parallel. In the end, voting determines if the document is approved or rejected.

workflow-105-documentworkflow

Iterative Design

Provides a sample in which a workflow task can be passed multiple times between assignees during the design process. Advanced routing rules implement the routing behavior.

workflow-106-IterativeDesign

Office Integration

Provides a sample in which Microsoft Excel attachments are enabled with workflow notifications.

 

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 life cycle 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-22 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 the 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 to any of the following channels: email, telephone voice message, IM, and SMS. See Section 32.2, "Notifications from Human Workflow" 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 flex field mappings.

  • Evidence service

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

Figure 27-22 Workflow Services Components

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

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

Figure 27-23 Workflow Services and Business Process Interactions

Description of Figure 27-23 follows
Description of "Figure 27-23 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 BPM Suite.