You must not modify SOA Human Task database tables directly. Oracle does not guarantee backward compatibility for the column names and data in these tables.
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 BPEL Worklist Application)
Organization, filtering, prioritization, and other features required for end users to productively perform their tasks
Reports, reassignments, load balancing, and other features required by supervisors and business owners to manage the performance of tasks
Figure 27-1 provides an overview of human workflow.
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 to determine people's roles and privileges.
You can configure the identity store to use the embedded WebLogic LDAP, Oracle Virtual Directory, third-party LDAPs and Active Directory RDBMS. For more information, see Securing Applications with Oracle Platform Security Services.
The human task service component presents tasks to users through a variety of channels, including the following:
Oracle BPEL Worklist Application, a role-based application that supports the concept of supervisors and process owners, and provides functionality for finding, organizing, managing, and performing tasks.
Worklist functionality is also available as portlets that can be exposed in an enterprise portal.
Notifications can be sent by email, phone, SMS, and other channels. Email notifications can be actionable, enabling users to perform actions on the task from within the email client without connecting to Oracle BPEL Worklist Application or Oracle WebLogic Server.
Get an overview of key human workflow design time and runtime concepts 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.
Human workflow design-time tasks are performed in a graphical editor known as the Human Task Editor. The tutorial in Human Workflow Tutorial 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 27-2). Human workflow provides declarative, pattern-based support for such scenarios.
Figure 27-2 Participants in a Task
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.
In simple cases, a participant maps to a user, group, or role. However, as discussed in 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.
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 Assigning 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 BPEL Worklist Application, 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 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 BPEL Worklist Application, see 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 Allow All Participants to Invite Other Participants or Edit New Participants.
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 Stopping Routing of a Task to Further Participants.
There are different methods for assigning users, groups, and application roles to tasks.
Static Task Assignment
Dynamic Task Assignment
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,
You can assign users, groups, and application roles dynamically in the following ways:
By using a task-assignment pattern. This pattern enables you to do the following:
Simply enable participants to claim the task manually. This is the default behavior. No task-assignment pattern is applied.
If the participant type is either Single or FYI, then apply a task-assignment pattern to select a single assignee of a requested type from all potential assignees in the participant.
For example, suppose that the potential assignees comprise the user
jcooper, the group
LoanAgent, and the application role
Developers. Suppose further that the requested type is
user. Applying this task-assignment pattern selects a single user from the user
jcooper, and from all members of the group
LoanAgent, and from all users with the application role
If the particulates type is Parallel or Serial, then apply a task-assignment pattern to select a single assignee of a requested type from each of the potential assignees in the participant.
For example, suppose that the potential assignees comprise the user
jcooper, the group
LoanAgent, and the application role
Developers. Suppose further that the requested type is
user. Applying this task-assignment pattern selects the user
jcooper, and one user from the group
LoanAgent, and one user with the application role
By using XPath expressions. These expressions enable you to dynamically determine assignment to users not included in the participant type. Here you create a list of potential assignees, one of whom must then claim the task.
For example, you may have a business requirement to create a dynamic list of task approvers specified in a payload variable. The XPath expression can resolve to zero or more XML nodes. Each node value can be either a single user, group, or application role or 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
You can use both options simultaneously—for example, you can use an XPath expression to dynamically select a group, and then apply a task-assignment pattern to dynamically select a user from that group.
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.
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 Specifying the Task Initiator and Task Priority.
This participant can review the status of the task and add comments and attachments. You can grant the reviewer role to a participant at runtime using the process instance attributes reviewer and reviewerType. The reviewer process attribute stores the name of the reviewer, the default value is "ProcessReviewer" or the value assigned in the Human Task configuration. The reviewerType process attribute stores the type of reviewer which can be: user, role or group. You can set these attributes dynamically to modify the effective reviewer.
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 BPEL Worklist Application, the task form in which you perform task actions during runtime.
For more information, see How to Configure the Error Assignee and Reviewers.
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 Escalating_ Renewing_ or Ending 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 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, 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 message shown below by email when a task assignee requests additional information before they can act upon a task:
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 added to 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 BPEL Worklist Application displays all worklist tasks that are assigned to task assignees in the task form. When you navigate 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.
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 How to Specify Advanced Task Routing Using Business Rules.
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 Assigning 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 Assigning 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 Introduction to Access Rules.
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 Specifying Java Callbacks.
Oracle BPEL Worklist Application 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 Using .
Human workflow modeling consists of three stages of modeling:
Stage 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. For more information, see Introduction to Creating a Human Task Definition.
Stage 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. For more information, see Introduction to Associating the Human Task Definition with a BPEL Process.
Stage 3: You create a task form. This form displays the task details on which you act at runtime in Oracle BPEL Worklist Application. For more information, see Introduction to Generating the Task Form.
Get an overview of use cases for human workflow and services. After that, a tutorial guides you through the design of a human task from start to finish.
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
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
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 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
A user may decide to have another user perform tasks on their behalf. Tasks can be explicitly delegated from the Oracle BPEL Worklist Application 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.
An overview of human workflow architecture.
The services that perform a variety of operations in the lifecycle of a task, such as querying tasks for a user, retrieving metadata information related to a task, and so on.
The two ways to use a human task:
Associated with a BPEL process service component
Used in standalone mode
The role of the service engine in the life of a human task
Starting with release 11g, all human task metadata is stored and managed in the Metadata Service (MDS) repository. The workflow service consists of many services that handle various aspects of human interaction with a business process.
Figure 27-6 shows the following workflow service components:
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 BPEL Worklist Application 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.
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 through any of the following channels: email, telephone voice message, IM, and SMS. See 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.
The evidence service supports storage and nonrepudiation of digitally-signed workflow tasks.
Figure 27-6 Workflow Services Components
Figure 27-7 shows the interactions between the services and the business process.
Figure 27-7 Workflow Services and Business Process Interactions
You can use a human task in the following ways:
Human task associated with a BPEL process
You can 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.
Human task associated with a BPMN process
You can associate your human task with a BPMN process. The BPMN process may contain other types of BPMN flow objects as part of the flow of the process. The human task is the implementation of a BPMN user task.
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 Administering Oracle SOA Suite and Oracle Business Process Management Suite.
Oracle SOA Suite and Oracle Business Process Management (BPM) Suite both provide support for business rules and human workflow. However, Oracle BPM Suite provides additional business rules and human workflow features that are not available in Oracle SOA Suite.
Table 27-1 identifies which business rule and human workflow features are supported in each suite.
Table 27-1 Business Rule and Human Workflow Features in Oracle SOA Suite and Oracle BPM Suite
|Feature||Supported in Oracle BPM Suite?||Supported in Oracle SOA Suite?|
Workspaces, process tracking, standard dashboards, case management, and applications menu
Approval groups (participant list)
Human workflow and business rules (participant list, routing rules)
Rules business phrases
Oracle BPM Composer - design time rules editing
Process asset catalog (PAM) for source management between Oracle BPM Studio and Oracle BPM Composer
Rules testing in both Oracle JDeveloper and SOA Composer with usability enhancements
Microsoft Excel import/export for rules decision tables
For more information about Oracle BPM Suite, see Developing Business Processes with Oracle Business Process Management Studio.