Skip Headers
Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite
11g Release 1 (11.1.1.5.0)

Part Number E10224-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

26 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:

26.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:

Figure 26-1 provides an overview of human workflow.

Figure 26-1 Human Workflow

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

In Figure 26-1, the following actions occur:

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

26.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 26.3.2, "Designing a Human Task from Start to Finish" describes how to use this editor.

26.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 26-2). Human workflow provides declarative, pattern-based support for such scenarios.

Figure 26-2 Participants in a Task

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

26.2.1.1.1 Participant

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

26.2.1.1.2 Participant Type

In simple cases, a participant maps to a user, group, or role. However, as discussed in Section 26.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 27.3.6, "How to Assign Task Participants."

26.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 26.2.1.6, "Task Forms."

26.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 27.3.7.1.1, "Allowing All Participants to Invite Other Participants."

26.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 26-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 27.3.7.1.2, "Stopping Routing of a Task to Further Participants."

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

26.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 27.3.4.6, "Specifying a Task Owner" to specify an owner in the Human Task Editor or Section 27.4.4.2, "Specifying a Task Owner" 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 Section 27.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 27.3.7.4, "Configuring the Error Assignee."

26.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 27.3.9, "How to Escalate, Renew, or End the Task."

26.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 26-1 by email when a task assignee requests additional information before they can act upon a task:

Example 26-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:

26.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:

26.2.1.7 Advanced Concepts

This section describes advanced human workflow concepts.

26.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 27.3.7.2, "Specifying Advanced Task Routing Using Business Rules."

26.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 27.3.6, "How to Assign Task Participants."

26.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 27.3.6, "How to Assign Task Participants."

26.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 27.3.11.1, "Specifying Access Policies on Task Content."

26.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 27.3.14.1, "Specifying Callback Classes on Task Status."

26.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 29, "Using Oracle BPM Worklist."

26.2.2 Introduction to the Stages of Human Workflow Design

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

Table 26-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 27.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 27.2.2, "Associate the Human Task Definition with a BPEL Process."

3

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

Section 27.2.3, "Generate the Task Form."


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

26.3.1 Human Workflow Use Cases

The following sections describe multiple use cases for workflow services.

26.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 26-3.

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

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

26.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 26-4.

Figure 26-4 Flow Patterns and Routing Policies

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

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

26.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 26-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 26-5 Escalation and Notification

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

26.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).

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

26.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 and Human Task 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

26.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 26.3.3, "Additional Tutorials" for information on downloading this and other tutorials.

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

26.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 Process, 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 File dialog appears.

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

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

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

    Description of Figure 26-6 follows
    Description of "Figure 26-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 26-7.

    Figure 26-7 BPEL Process Dialog

    Description of Figure 26-7 follows
    Description of "Figure 26-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, as shown in Figure 26-8. 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 26-8 BPEL Process in SOA Composite Editor

    Description of Figure 26-8 follows
    Description of "Figure 26-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."

26.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 Service Components section 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 26-2.

    Table 26-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 26.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 26-9.

    Figure 26-9 Human Task Icon in SOA Composite Editor

    Description of Figure 26-9 follows
    Description of "Figure 26-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.

26.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 parameter.

    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 26-10 provides details.

    Figure 26-10 Type Chooser Dialog

    The Human Task window
    Description of "Figure 26-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 26-11.

    Figure 26-11 Assignment and Routing Policy

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

  13. At the top of the Human Task Editor, click the Edit icon.

    The Edit Participant Type dialog appears. You now add participants to this task. As described in Section 26.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 26-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 26.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 26-12 Selection of By Expression from the Data Type Column

    Description of Figure 26-12 follows
    Description of "Figure 26-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 26-13 provides details.

    Figure 26-13 XPath Expression

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

  24. Click OK to exit the Expression Builder dialog.

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

  26. From the File menu, select Save All.

26.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 26.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. In the Component Palette, expand SOA Components.

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

  5. Double-click the activity.

    The Human Task dialog appears.

  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 26-14 to display additional fields.

    Figure 26-14 Human Task Dialog

    Description of Figure 26-14 follows
    Description of "Figure 26-14 Human Task Dialog"

  7. In the BPEL Variable column, click the Browse icon (dots) shown in Figure 26-15.

    Figure 26-15 BPEL Variable Entry

    Description of Figure 26-15 follows
    Description of "Figure 26-15 BPEL Variable Entry"

    The Task Parameters dialog appears.

  8. From the Type list, select Variable.

  9. Expand Process > Variables > inputVariable > payload > ns1:VacationRequestProcessRequest. Figure 26-16 provides details.

    Figure 26-16 Variable Selection

    Description of Figure 26-16 follows
    Description of "Figure 26-16 Variable Selection"

  10. Click OK.

    When complete, the dialog looks as shown in Figure 26-17:

    Figure 26-17 BPEL Variable

    Description of Figure 26-17 follows
    Description of "Figure 26-17 BPEL Variable"

  11. Click OK to close the Human Task dialog.

    The human task activity appears as shown in Figure 26-18.

    Figure 26-18 Human Task and Partner Links in Oracle BPEL Designer

    Description of Figure 26-18 follows
    Description of "Figure 26-18 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 26-19 provides details.

    Figure 26-19 SOA Composite Editor

    Description of Figure 26-19 follows
    Description of "Figure 26-19 SOA Composite Editor"

  13. From the File menu, select Save All.

26.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. These instructions describe how to create a connection to Oracle WebLogic Server. For information about creating a connection to other application servers such as IBM WebSphere Server, see Oracle Fusion Middleware Third-Party Application Server Guide.

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 26-20 is displayed.

    Figure 26-20 Connection Success

    Description of Figure 26-20 follows
    Description of "Figure 26-20 Connection Success"

  13. Click Finish.

  14. From the File menu, select Save All.

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

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

    The project is deployed.

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

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

26.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 VacationRequestTask human task.

    The Human Task Editor is displayed.

  2. From the Create Form menu at the top, select Auto-Generate Task Form. Figure 26-21 provides details.

    Figure 26-21 Task Form Creation

    Description of Figure 26-21 follows
    Description of "Figure 26-21 Task Form Creation"

    The Create Project dialog appears.

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

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

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

26.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 > VacationRequestTaskFlow.

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

26.3.3 Additional Tutorials

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

https://soasamples.samplecode.oracle.com

Table 26-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 26-3 End-to-End Examples

Sample Description Name

Demo Community Seed Application

Performs demo community seeding. This is a prerequisite for all other workflow samples.

workflow-001-DemoCommunitySeedApp

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

Sales Quote Request

Provides a complex workflow sample with chaining of multiple tasks.

workflow-102-SalesQuote

Contract Approval

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

workflow-104-ContractApproval

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

Workflow Customizations

Demonstrates how to deploy customizations to workflow service APIs, such as custom resource strings for task attributes, view names, and so on.

workflow-110-workflowCustomizations

MLS Sample

Demonstrates the setting up of a task with multiple translations for the task title.

workflow-114-MLSSample

Workflow Event Callback

Demonstrates the use of the workflow event callback. Workflow events generated by task lifecycle events are consumed by an Oracle Mediator.

workflow-116-WorkflowEventCallback

User Config Data Migrator

Moves user configurations (views, mapped attributes, and so on) from one instance to another through an intermediate export file.

workflow-117-UserConfigDataMigrator

Java Samples

Provides an assortment of samples that use Java to interact with human workflow.

workflow-118-JavaSamples


26.4 Introduction to Human Workflow Architecture

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

26.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 26-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 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 WebLogic 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 Section 31.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 mapped attribute mappings.

  • Evidence service

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

Figure 26-22 Workflow Services Components

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

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

Figure 26-23 Workflow Services and Business Process Interactions

Description of Figure 26-23 follows
Description of "Figure 26-23 Workflow Services and Business Process Interactions"

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

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