(For more resources on BPEL, SOA and Oracle see here.)
Human interactions in business processes
The main objective of BPEL has been to standardize the process automation. BPEL business processes make use of services and externalize their functionality as services. BPEL processes are defined as a collection of activities through which services are invoked. BPEL does not make a distinction between services provided by applications and other interactions, such as human interactions, which are particularly important. Real-world business processes namely often integrate not only systems and services, but also humans.
Human interactions in business processes can be very simple, such as approval of certain tasks or decisions, or complex, such as delegation, renewal, escalation, nomination, chained execution, and so on. Human interactions are not limited to approvals and can include data entries, process monitoring and management, process initiation, exception handling, and so on.
Task approval is the simplest and probably the most common human interaction. In a business process for opening a new account, a human interaction might be required to decide whether the user is allowed to open the account. In a travel approval process, a human might approve the decision from which airline to buy the ticket (as shown in the following figure).
If the situation is more complex, a business process might require several users to make approvals, either in sequence or in parallel. In sequential scenarios, the next user often wants to see the decision made by the previous user. Sometimes, particularly in parallel human interactions, users are not allowed to see the decisions taken by other users. This improves the decision potential. Sometimes one user does not even know which other users are involved, or whether any other users are involved at all.
A common scenario for involving more than one user is workflow with escalation. Escalation is typically used in situations where an activity does not fulfill a time constraint. In such a case, a notification is sent to one or more users. Escalations can be chained, going first to the first-line employees and advancing to senior staff if the activity is not fulfilled.
Sometimes it is difficult or impossible to define in advance which user should perform an interaction. In this case, a supervisor might manually nominate the task to other employees; the nomination can also be made by a group of users or by a decision-support system.
In other scenarios, a business process may require a single user to perform several steps that can be defined in advance or during the execution of the process instance. Even more complex processes might require that one workflow is continued with another workflow.
Human interactions are not limited to only approvals; they may also include data entries or process management issues, such as process initiation, suspension, and exception management. This is particularly true for long-running business processes, where, for example, user exception handling can prevent costly process termination and related compensation for those activities that have already been successfully completed.
As a best practice for human workflows, it is usually not wise to associate human interactions directly to specific users; it is better to connect tasks to roles and then associate those roles with individual users. This gives business processes greater flexibility, allowing any user with a certain role to interact with the process and enabling changes to users and roles to be made dynamically. To achieve this, the process has to gain access to users and roles, stored in the enterprise directory, such as LDAP (Lightweight Directory Access Protocol).
Workflow theory has defined several workflow patterns, which specify the abovedescribed scenarios in detail. Examples of workflow patterns include sequential workflow, parallel workflow, workflow with escalation, workflow with nomination, ad-hoc workflow, workflow continuation, and so on.
Human Tasks in BPEL
So far we have seen that human interaction in business processes can get quite complex. Although BPEL specification does not specifically cover human interactions, BPEL is appropriate for human workflows. BPEL business processes are defined as collections of activities that invoke services. BPEL does not make a distinction between services provided by applications and other interactions, such as human interactions.
There are mainly two approaches to support human interactions in BPEL. The first approach is to use a human workflow service. Several vendors today have created workflow services that leverage the rich BPEL support for asynchronous services. In this fashion, people and manual tasks become just another asynchronous service from the perspective of the orchestrating process and the BPEL processes stay 100% standard.
The other approach has been to standardize the human interactions and go beyond the service invocations. This approach resulted in the workflow specifications emerging around BPEL with the objective to standardize the explicit inclusion of human tasks in BPEL processes. The BPEL4People specification has emerged, which was originally put forth by IBM and SAP in July 2005. Other companies, such as Oracle, Active Endpoints, and Adobe joined later. Finally, this specification is now being advanced within the OASIS BPEL4People Technical Committee. The BPEL4People specification contains two parts:
- BPEL4People version 1.0, which introduces BPEL extensions to address human interactions in BPEL as a first-class citizen. It defines a new type of basic activity, which uses human tasks as an implementation, and allows specifying tasks local to a process or use tasks defined outside of the process definition. BPEL4People is based on the WS-HumanTask specification that it uses for the actual specification of human tasks.
- Web Services Human Task (WS-HumanTask) version 1.0 introduces the definition of human tasks, including their properties, behavior, and a set of operations used to manipulate human tasks. It also introduces a coordination protocol in order to control autonomy and lifecycle of service-enabled human tasks in an interoperable manner.
The most important extensions introduced in BPEL4People are people activities and people links. People activity is a new BPEL activity used to define user interactions; in other words, tasks that a user has to perform. For each people activity, the BPEL server must create work items and distribute them to users eligible to execute them. People activities can have input and output variables and can specify deadlines.
To specify the implementation of people activities, BPEL4People introduced tasks. Tasks specify actions that users must perform. Tasks can have descriptions, priorities, deadlines, and other properties. To represent tasks to users, we need a client application that provides a user interface and interacts with tasks. It can query available tasks, claim and revoke them, and complete or fail them.
To associate people activities and the related tasks with users or groups of users, BPEL4People introduced people links. People links are somewhat similar to partner links; they associate users with one or more people activities. People links are usually associated with generic human roles, such as process initiator, process stakeholders, owners, and administrators.
The actual users that are associated with people activities can be determined at design time, deployment time, or runtime. BPEL4People anticipates the use of directories such as LDAP to select users. However, it doesn't define the query language used to select users. Rather, it foresees the use of LDAP filters, SQL, XQuery, or other methods.
BPEL4People proposes complex extensions to the BPEL specification. However, so far it is still quite high level and doesn't yet specify the exact syntax of the new activities mentioned above. Until the specification becomes more concrete, we don't expect vendors to implement the proposed extensions. But while BPEL4People is early in the standardization process, it shows a great deal of promise.
The BPEL4People proposal raises an important question: Is it necessary to introduce such complex extensions to BPEL to cover user interactions? Some vendor solutions model user interactions as just another web service, with well-defined interfaces for both BPEL processes and client applications. This approach does not require any changes to BPEL. To become portable, it would only need an industry-wide agreement on the two interfaces. And, of course, both interfaces can be specified with WSDL, which gives developers great flexibility and lets them use practically any environment, language, or platform that supports Web Services.
Clearly, a single standard approach has not yet been adopted for extending BPEL to include Human Tasks and workflow services. However, this does not mean that developers cannot use BPEL to develop business processes with user interactions.
Human Task integration with BPEL
To interleave user interactions with service invocations in BPEL processes we can use a workflow service, which interacts with BPEL using standard WSDL interfaces. This way, the BPEL process can assign user tasks and wait for responses by invoking the workflow service using the same syntax as for any other service. The BPEL process can also perform more complex operations such as updating, completing, renewing, routing, and escalating tasks.
After the BPEL process has assigned tasks to users, users can act on the tasks by using the appropriate applications. The applications communicate with the workflow service by using WSDL interfaces or another API (such as Java) to acquire the list of tasks for selected users, render appropriate user interfaces, and return results to the workflow service, which forwards them to the BPEL process. User applications can also perform other tasks such as reassign, escalate, route, suspend, resume, and withdraw. Finally, the workflow service may allow other communication channels, such as e-mail and SMS, as shown in the following figure:
Oracle Human Workflow concepts
Oracle SOA Suite 11g provides the Human Workflow component, which enables including human interaction in BPEL processes in a relatively easy way. The Human Workflow component consists of different services that handle various aspects of human interaction with business process and expose their interfaces through WSDL; therefore, BPEL processes invoke them just like any other service. The following figure shows the overall architecture of the Oracle Workflow services:
As we can see in the previous figure, the Workflow consists of the following services:
- Task Service exposes operations for task state management, such as operations to update a task, complete a task, escalate a task, reassign a task, and so on. When we add a human task to the BPEL process, the corresponding partner link for the Task Service is automatically created.
- Task Assignment Service provides functionality to route, escalate, reassign tasks, and more.
- Task Query Service enables retrieving the task list for a user based on a search criterion.
- Task Metadata Service enables retrieving the task metadata.
- Identity Service provides authentication and authorization of users and lookup of user properties and privileges.
- Notification Service enables sending of notifications to users using various channels (e-mail, voice message, IM, SMS, and so on).
- User Metadata Service manages metadata, related to workflow users, such as user work queues, preferences, and so on.
- Runtime Configuration Service provides functionality for managing metadata used in the task service runtime environment.
- Evidence Store Service supports management of digitally-signed workflow tasks.
BPEL processes use the Task Service to assign tasks to users. More specifically, tasks can be assigned to:
- Users: Users are defined in an identity store configured with the SOA infrastructure.
- Groups: Groups contain individual users, which can claim a task and act upon it.
- Application roles: Used to logically group users and other roles. These roles are application specific and are not stored in the identity store.
Assigning tasks to groups or roles is more flexible, as every user in a certain group (role) can review the task to complete it. Oracle SOA Suite 11g provides three methods for assigning users, groups, and application roles to tasks:
- Static assignment: Static users, groups, or application roles can be assigned at design time.
- Dynamic assignment: We can define an XPath expression to determine the task participant at runtime.
- Rule-based assignment: We can create a list of participants with complex expressions.
Once the user has completed the task, the BPEL process receives a callback from the Task Service with the result of the user action. The BPEL process continues to execute.
The Oracle Workflow component provides several possibilities regarding how users can review the tasks that have been assigned to them, and take the corresponding actions. The most straightforward approach is to use the Oracle BPM Worklist application. This application comes with Oracle SOA Suite 11g and allows users to review the tasks, to see the task details, and to select the decision to complete the task.
If the Oracle BPM Worklist application is not appropriate, we can develop our own user interface in Java (using JSP, JSF, Swing, and so on) or almost any other environment that supports Web Services (such as .NET for example). In this respect, the Workflow service is very flexible and we can use a portal, such as Oracle Portal, a web application, or almost any other application to review the tasks.
The third possibility is to use e-mail for task reviews. We use e-mails over the Notification service.
To simplify the development of workflows, Oracle SOA Suite 11g provides a library of workflow patterns (participant types). Workflow patterns define typical scenarios of human interactions with BPEL processes. The following participant types are supported:
- Single approver: Used when a participant maps to a user, group, or role.
- Parallel: Used if multiple users have to act in parallel (for example, if multiple users have to provide their opinion or vote). The percentage of required user responses can be specified.
- Serial: Used if multiple users have to act in a sequence. A management chain or a list of users can be specified.
- FYI (For Your Information): Used if a user only needs to be notified about a task, but a user response is not required.
With these, we can realize various workflow patterns, such as:
- Simple workflow: Used if a single user action is required, such as confirmation, decision, and so on. A timeout can also be specified. Simple workflow has two extension patterns:
- Escalation: Provides the ability to escalate the task to another user or role if the original user does not complete the task in the specified amount of time.
- Renewal: Provides the ability to extend the timeout if the user does not complete the task in the specified time.
- Sequential workflow: Used if multiple users have to act in a sequence. A management chain or a list of users can be specified. Sequential workflow has one extension pattern:
- Escalation: Same functionality as above.
- Parallel workflow: Used if multiple users have to act in parallel (for example, if multiple users have to provide their opinion or vote). The percentage of required user responses can be specified. This pattern has an extension pattern:
- Final reviewer: Is used when the final review has to act after parallel users have provided feedback.
- Ad-hoc (dynamic) workflow: Used to assign the task to one user, who can then route the task to other user. The task is completed when the user does not route it forward.
- FYI workflow: Used if a user only needs to be notified about a task, but a user response is not required.
- Task continuation: Used to build complex workflow patterns as a chain of simple patterns (those described above).
(For more resources on BPEL, SOA and Oracle see here.)
Creating Human Task definitions
In order to create new human task definition, we drag-and-drop the Human Task service component from the Component Palette to the composite application. The Create Human Task window opens. We set the name of the human task to FlightTicketApproval and leave the default namespace. We do not select the Create Composite Service with SOAP Bindings, as the human task does not have to be exposed through the web service interface, as we will use it from the BPEL process. If we would use the human task from an external client, we would expose it through the web service interface.
Then we wire the created human task and the BPEL process.
By wiring the human task and the BPEL process, a partner link for the TaskService is automatically created in the BPEL process.
Configuring a Human Task title and outcomes
We then double-click the FlightTicketApproval Human Task to open the Task Definition Editor. We enter Flight ticket approval as the Task Title (the Task Title displays on the BPM Worklist).
We can also optionally add a Description to the Human Task. We leave the default Outcomes (APPROVE and REJECT). When we want to define custom outcomes, we have to click on the magnifying glass icon to open the Outcomes Dialog, as shown in the following screenshot:
Here we can add new outcomes by clicking the green plus icon. We will not do this; therefore, we close the dialog by clicking OK. Back in the Task Definition Editor we could also set task Priority and Category. This can be useful for users of the BPM Worklist application, as they can easily group or filter their tasks based on the priority or category. However, we will not change these values.
We also select the task Owner (a person that has administrative privileges on the task). To select a person we click on the magnifying glass icon. The Identity Lookup dialog opens. Here we can browse users and select them. In our example, we select the weblogic user and click OK to close the dialog.
In order to be able to browse for users, we first have to create a connection to the SOA-managed server.
Configuring Human Task payload
Back in the Task Definition Editor, we click on the Data tab to set the task payload, as the approval manager will need data about an employee and the selected flight to decide whether to approve the flight ticket or not. Under the Data section we click on the plus icon and select Add other payload.
The Add Task Parameter dialog opens. We select Element and browse for the employee element, which is defined in the EmployeeType.xsd schema.
We leave the Editable via worklist unchecked, as the approval manager will not need to change the payload. We click OK to close the dialog. Then we add another element, which will contain information about the selected flight ticket (confirmationData).
Now we set the Human Task payload type. In the BPEL process, we will have to assign the actual data from BPEL variables to the payload. Configuring Human Task assignments
Next, we open the Assignment tab, where we can assign the Human Task to a user, group, or an application role. We click on the
We click OK to close the dialog. Back in the Task Definition Editor we click on the edit icon in the upper-right corner. The Configure Assignment dialog opens. We switch to the Assignment tab and select the weblogic user to be an error assignee. The error assignee is responsible for performing corrective actions in case an error occurs.
Configuring Human Task deadlines
Next, we switch to the Deadlines tab to set the task expiration. From the Task Duration Settings drop-down, we select Expire after and set the expiration time to 5 minutes (for testing purposes).
Configuring Human Task notifications
We then click on the Notification tab. We configure notifications, so that in case of task expiration or an error, a notification will be automatically send to task owner.
By clicking on the edit icon in the Notification Header column, we set the text of a notification message.
We click OK twice to close both dialogs and save the project.
In the above article we have covered:
- Human interactions in business processes
- Human Tasks in BPEL
- Oracle Human Workflow concepts, features, and architecture
- Creating Human Task definitions
- Business Processes with BPEL [Article]
- Web Services, SOA, and WS-BPEL Technologies [Article]
- SOA—Service Oriented Architecture [Article]
- Oracle Web Services Manager: Authentication and Authorization [Article]