|Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite
11g Release 1 (11.1.1)
Part Number E10224-03
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 44, "Defining Composite Sensors."
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 25-1 provides an overview of human workflow:
Figure 25-1 Human Workflow
In Figure 25-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.
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.
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 25.3.2, "Designing a Human Task from Start to Finish" describes how to use this editor.
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 25-2). Human workflow provides declarative pattern-based support for such scenarios.
Figure 25-2 Participants in a Task
A participant is a user or set of users in the assignment and routing policy definition. In Figure 25-2, each block with an icon representing people is a participant.
In simple cases, a participant maps to a user, group, or role. However, as discussed in Section 22.214.171.124, "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:
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.
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.
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.
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 26.3.6, "How to Assign Task Participants."
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:
You can assign individual users to act upon tasks. For example, you may assign users
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.
You can assign groups to act upon tasks. Groups contain individual users who can claim and act upon a task. For example, users
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.
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 126.96.36.199, "Task Forms."
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 188.8.131.52.1, "Allowing All Participants to Invite Other Participants."
By default, a task goes from starting to final participant as per the flow defined in the routing policy (as shown in Figure 25-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 184.108.40.206.2, "Stopping Routing of a Task to Further Participants."
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,
A delimited string of users, groups, or application roles (for example,
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:
This returns the manager of
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
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.
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:
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 220.127.116.11, "Specifying a Task Owner" to specify an owner in the Human Task Editor or Section 18.104.22.168, "Specifying a Task Owner" to specify an owner in the Advanced tab of the Create Human Task dialog.
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 22.214.171.124, "Specifying the Task Initiator and Task Priority."
This participant can review the status of the task and add comments and attachments.
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.
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 126.96.36.199, "Configuring the Error Assignee."
Human workflow supports the specification of deadlines associated with a task. You can associate the following actions with deadlines:
The task can be reminded multiple times based on the time after the assignment or the time before the expiration.
The task is escalated up the management hierarchy.
The task has expired.
The task is automatically renewed.
For more information, see Section 26.3.9, "How to Escalate, Renew, or End the Task."
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.
You can configure email notification messages to be actionable, meaning that a task assignee can act upon a task from within the email.
Instant messaging (IM)
Short message service (SMS)
For example, you may send the following message by email when a task assignee requests additional information before they can act upon a task:
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:
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:
This section describes advanced human workflow concepts.
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 188.8.131.52, "Specifying Advanced Task Routing Using Business Rules."
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 26.3.6, "How to Assign Task Participants."
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 26.3.6, "How to Assign Task Participants."
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 184.108.40.206, "Specifying Access Policies on Task Content."
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 220.127.116.11, "Specifying Callback Classes on Task Status."
Oracle BPM Worklist provides several out-of-the-box reports for task analysis:
Analysis of tasks assigned to users' groups or reportees' groups that have not yet been acquired.
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.
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:
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 28, "Using Oracle BPM Worklist."
Human workflow modeling consists of three stages of modeling, as described in Table 25-1.
Table 25-1 Stages of Human Workflow Modeling
|Step||Description||For More Information...|
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.
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.
You create a task form. This form is used for displaying the task details on which you act at runtime in Oracle BPM Worklist.
This section provides an introduction to use cases for human workflow. After that, a tutorial is provided that guides you through the design of a human task from start to finish.
The following sections describe multiple use cases for workflow services.
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 25-3.
Figure 25-3 Assigning Tasks to a User or Role from a Directory
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 25-4.
Figure 25-4 Flow Patterns and Routing Policies
You can use these types as building blocks to create complex workflows.
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 25-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 25-5 Escalation and Notification
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).
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.
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
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.
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>
VacationRequest.xsdfile is also available for download as part of tutorial
workflow-100-VacationRequest. See Section 25.3.3, "Additional Tutorials" for information on downloading this and other tutorials.
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.
To create an application and a project with a BPEL process:
Start Oracle JDeveloper.
From the File main menu, select New > Applications > SOA Application.
In the Application Name field, enter
VacationRequest, and click Next.
In the Project Name field, enter
VacationRequest, and click Next.
In the Composite Template list, select Composite with BPEL, and click Finish.
The Create BPEL Process dialog appears.
In the Name field, enter
Go to the bottom of the Create BPEL Process dialog.
To the right of the Input field, click the Search icon.
The Type Chooser dialog appears.
In the upper right corner, click the Import Schema File icon.
The Import Schema dialog appears.
Browse for and select the VacationRequest.xsd file you created in Section 18.104.22.168, "Prerequisites."
Click OK until you are returned to the Type Chooser dialog, as shown in Figure 25-6.
Figure 25-6 Type Chooser Dialog with the Request and Response Elements
Select the input element VacationRequestProcessRequest, and click OK.
You are returned to the Create BPEL Process dialog.
To the right of the Output field, click the Search icon.
Select the output element VacationRequestProcessResponse, and click OK.
You are returned to the Create BPEL Process dialog, as shown in Figure 25-7.
Figure 25-7 BPEL Process Dialog
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 25-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."
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:
From the SOA list of the Component Palette, drag a Human Task into the SOA Composite Editor.
The Create Human Task dialog appears.
Enter the details described in Table 25-2.
Table 25-2 Create Human Task Dialog Fields and Values
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 22.214.171.124.1, "Creating an Application and a Project with a BPEL Process." The BPEL process was created with an automatically-bound web service.
The Human Task icon appears in the SOA Composite Editor above the BPEL process, as shown in Figure 25-9.
Figure 25-9 Human Task Icon in SOA Composite Editor
Double-click the Human Task icon.
The Human Task Editor appears. You are now ready to begin design of your human task.
To design the human task:
In the Title field, enter
Request for Vacation.
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.
On the right side of the Parameters section, click the Add icon to specify the task 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.
To the right of the Element field, click the Search icon.
The Type Chooser dialog appears.
Expand and select Project Schema Files > VacationRequest.xsd > VacationRequestProcessRequest, and click OK. Figure 25-10 provides details.
Figure 25-10 Type Chooser Dialog
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.
Click OK on the Add Task Parameter dialog.
In the Assignment and Routing Policy section, highlight the <no participants> box below Stage1, as shown in Figure 25-11.
Figure 25-11 Assignment and Routing Policy
On the right side of the Assignment and Routing Policy section, click the Edit icon.
The Edit Participant Type dialog appears. You now add participants to this task. As described in Section 126.96.36.199.2, "Participant Type," Oracle SOA Suite provides several out-of-the-box patterns known as participant types for addressing specific business needs.
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.
In the Participant Name table, click the Add icon, and select Add User.
This participant type acts alone on the task.
Click the Data Type column, and select By Expression from the list that is displayed. Figure 25-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 188.8.131.52.1, "Creating an Application and a Project with a BPEL Process"). The task is automatically routed to the employee's manager.
Figure 25-12 Selection of By Expression from the Data Type Column
In the Value column, click the Browse icon (the dots) to invoke the Expression Builder dialog.
In the dropdown list in the Functions section, select Identity Service Functions.
Select getManager. This function gets the manager of the user who created the vacation request task.
Above the Functions section, click Insert into Expression.
Place the cursor between the parentheses of the function.
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.
Click Insert into Expression.
The Expression Builder dialog displays the XPath expression in the Expression section. Figure 25-13 provides details.
Figure 25-13 XPath Expression
Click OK to exit the Expression Builder dialog.
From the File menu, select Save All.
Click OK to exit the Add Participant Type dialog.
You are now ready to associate your human task with the BPEL process you created in Section 184.108.40.206.1, "Creating an Application and a Project with a BPEL Process."
To associate the human task and BPEL process service component:
In the Application Navigator, double-click composite.xml.
Double-click the VacationRequestProcess BPEL process service component in the SOA Composite Editor.
The BPEL process displays in Oracle BPEL Designer.
From the list at the top of the Component Palette, select BPEL.
Expand BPEL Activities and Components.
Drag a Human Task beneath the receiveInput receive activity.
The Create Human Task dialog appears, as shown in Figure 25-14.
Figure 25-14 Human Task Creation
From the Task Definition list, select the VacationRequestTask task you created (if it is not currently displaying).
The dialog refreshes as shown in Figure 25-15 to display additional fields.
Figure 25-15 Create Human Task Dialog
In the BPEL Variable column, click the Browse icon (dots) shown in Figure 25-16 for the requester parameter.
Figure 25-16 BPEL Variable Entry
The Task Parameters dialog appears.
From the Type list, select Variable.
Expand Process > Variables > inputVariable > payload > ns1:VacationRequestProcessRequest. Figure 25-17 provides details.
Figure 25-17 Variable Selection
When complete, the dialog looks as shown in Figure 25-18:
Figure 25-18 BPEL Variable
Click OK to close the Create Human Task dialog.
The human task activity and request and response partner links now appear.
Figure 25-19 Human Task and Partner Links in Oracle BPEL Designer
Return to the SOA Composite Editor and note that the BPEL process and human task service components have been automatically connected.
Figure 25-20 SOA Composite Editor
From the File menu, select Save All.
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
From the File main menu, select New > Connections > Application Server Connection.
In the Connection Name field, enter a connection name.
From the Connection Type list, select WebLogic 10.3.
In the Username field, enter
In the Password field, enter the password for connecting to the application server.
Enter the hostname for the application server that is configured with the SOA Infrastructure.
In the WLS Domain field, enter the Oracle WebLogic Server domain.
Click Test Connection.
If successful, the message shown in Figure 25-21 is displayed.
Figure 25-21 Connection Success
From the File menu, select Save All.
You are now ready to deploy to the application server on which you created the connection.
To deploy the SOA composite application
In the Application Navigator, right-click the VacationRequest project and select Deploy > VacationRequest > application_server_connection_name.
The SOA Deployment Configuration dialog appears.
Select the target server, and click OK.
The project is deployed.
To initiate the process instance:
See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for instructions on accessing the Test Web Service page for initiating the process instance.
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:
Double-click the VacationRequestProcess BPEL process.
Right-click the VacationRequestTask_1 human task activity in Oracle BPEL Designer.
Select Auto-Generate Task Form.
The Create Project dialog appears.
In the Project Name field, enter
VacationRequestTaskFlow, and click OK.
From the File main menu, select Save All.
To resolve the task in Oracle BPM Worklist:
Go to Oracle BPM Worklist:
Log in to Oracle BPM Worklist.
Resolve the task.
To deploy the task form:
In the Application Navigator, right-click the VacationRequestTaskFlow project and select Deploy > to > VacationRequestTaskFlow > application_server_connection_name.
The SOA Deployment Configuration dialog appears.
Select the target server, and click OK.
The task form is deployed.
Return to Oracle BPM Worklist.
Note that the task form now appears at the bottom of Oracle BPM Worklist.
Table 25-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 25-3 End-to-End Examples
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.
Help Desk Request
Provides a simple workflow sample using Oracle ADF task forms for task approval.
Sales Quote Request
Provides a complex workflow sample with chaining of multiple tasks.
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.
Provides a sample of approving a contract. This sample uses digital signatures for tasks.
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.
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.
Provides a sample in which Microsoft Excel attachments are enabled with workflow notifications.
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
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 25-22 shows the following workflow service components:
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.
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.
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.
The task metadata service exposes operations to retrieve metadata information related to a task.
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.
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 30.2, "Notifications from Human Workflow" for more information.
The user metadata service manages metadata related to workflow users, such as user work queues, preferences, vacations, and delegation rules.
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.
The evidence service supports storage and nonrepudiation of digitally-signed workflow tasks.
Figure 25-22 Workflow Services Components
Figure 25-23 shows the interactions between the services and the business process.
Figure 25-23 Workflow Services and Business Process Interactions
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.
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.