Having learnt about human workflow, you are now aware of how to create user interfaces for those tasks. You have tested flows and witnessed the usage of human interaction. This chapter will focus on the advanced concepts of human workflow. In this chapter, you will look at advanced Human Task concepts like routing, defining sequential and parallel stages, skipping rules, run time AdHoc task assignments, approval groups, RL functions usage, task assignments and routing, participant types - single, serial, parallel, and FYI , participant assignments, outcome-based completion of routing flow, static, dynamic, and rule-based task assignment, task deadlines like escalation policy, and much more.
This chapter will focus on the implementation tasks, such as:
- Creating Human Task Service Components
- Creating task definition and the task payload
- Defining Assignments—stage and single participant
- Defining Assignments—sequential stage and serial participant
- Defining Assignments—management chain participant
- Defining Assignments—parallel participant type
- Testing the process
Human Workflow is required for human interactions in processes such as approvals, assignments, routing of tasks, and so on. It is also required for performing certain activities to go forward with the process. Deadlines, notifications, and escalations can be achieved through Human Tasks, which ensure the timely performance of tasks. Human tasks even presents the tasks to end users through a variety of mechanisms such as work list applications. Reports, reassignments, and load balancing empower business owners to manage the performance of tasks.
A BPM process invokes a Human Task. It creates a task in the Human Task Service Component. The BPM process will wait for the task to complete. The process will also watch out for any call-backs from the task and react to them. There is metadata associated with the task that is required by the Human Task Service Component to manage the lifecycle of the task, which includes information such as who performs the task, who are the stakeholders, task information, task actions, and so on.
The Human Task Service Component will use an Identity Directory such as an LDAP or an Embedded Realm to determine roles and privileges.
Human Task Service Component presents tasks to users via BPM Worklist applications, work list portlets in the form of enterprise portals, or as notifications via e-mail, phone, SMS, and other channels. Users can even perform actions on tasks from the e-mail client without connecting to Oracle BPM Worklist applications.
Starting with the release 11g that you are working on, all the Human Task metadata is stored and managed in the Metadata Service (MDS) repository. The workflow service itself consists of many services that handle various aspects of human interaction with a business process:
- Task Service: This has operations that can update a task, complete a task, escalate and reassign a task, and so on. A Task Service is used by Oracle BPM Worklist to retrieve tasks assigned to users. A Task Service itself consists of many services such as:
- Task Routing Service to route, escalate, and reassign the tasks
- Task Query Service to query a service
- Task Metadata Service to expose operations to retrieve metadata information related to a task.
- Identity Service: This is a thin Web Service layer on top of WLS 11g Security infrastructure or any customer user repository to enable authentication and authorization of users.
- Notification Service: This is used to deliver notifications through channels such as e-mail, IM, SMS, and so on.
- User Metadata Service: This is used to manage metadata related to workflow users such as preferences, vacations, delegation rules, and so on.
- Runtime Config Service: This service supports management of task payload-mapped attribute-mappings and also provides methods for managing metadata used in the task service runtime environment.
- Evidence Service: This service supports storage and non-repudiation of digitally-signed workflow tasks.
During runtime, the business logic and processing rules of the Human Task Service Component are executed by the human workflow service engine. The Human Workflow Service Component 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 of, are executed in this single Human Task service engine.