Once the actual owner starts working on the task, it transitions into the In Progress state. Upon successful completion, it transitions into the Completed state.
A task in the Reserved or In Progress state can be released by the owners, moving it back to the Ready state, where it waits for another potential owner to claim it. A task in the In Progress state can be stopped by the owner, which moves it back into the Reserved state.
Tasks in an active state - Ready, Reserved, or In Progress - can also be delegated and forwarded by actual owners, potential owners, and business administrators. This transitions the task to the Ready or Reserved state, as appropriate. Business data associated with the task is maintained, including any updates.
The BPEL4People specifications allow some tasks to be skipped. A task, if skipped, moves into the Obsolete end state. Tasks can also be terminated, usually by the surrounding business process; terminated tasks also move to the Obsolete state. The BPEL4People specifications also allow any active task to be suspended and resumed. Suspended tasks resume to the state in which they were suspended.
Task Presentation and User Interaction
While the presentation of tasks via a client application or other mechanisms such as e-mail is outside the scope of the BPEL4People specifications, the specifications do include enough definition that enables a standard interface for task presentation.
Presentation elements in a task define how information about tasks is made available in a human-readable way. They include a name (a short title of a task), a subject (a longer text describing the task, and a description (a long description of the task, which can be in HTML). Both the subject and the description can be parameterized. Values for the presentation elements can be specified for multiple languages. Listing 1 illustrates the concept of presentation elements with an example.
A task definition can include rendering elements, which provide an extensible mechanism for specifying UI renderings for tasks.
The BPEL4People specifications also support attachments and comments, which are stored in the task operation data along with information on when they were added and by whom. Attachments and comments can also be shared between tasks and enclosing BPEL processes, as well as between different tasks.
The BPEL4People specifications also define standard programming interfaces that a task list client application can use to work against any WS-HumanTask-compliant implementation.
An Example: Help Desk
Listings 2 and 3 illustrate the concepts discussed in this article using a help desk scenario. The Help Desk BPEL process invokes three human activities: Resolve Ticket (task), Approve Resolution (task), and Notify User (notification).
The use of logical personnel groups to perform skill-based assignments is illustrated in Resolve Ticket task, which also illustrates the concept of potential owners (all service agents with matching skills) and business owner (the service center manager). The 4-eyes principle is illustrated in the invocation of the Approve Resolution task in which we exclude the performer of the Resolve Ticket from potential owners. The Resolve Ticket task also illustrates the use of deadlines and presentation elements.
What's Next
People often ask whether the BPEL4People specifications will cause changes to the BPEL specification itself. We do not anticipate such an impact. BPEL was designed with extensibility in mind, and the BPEL4People specifications comply with BPEL's extensibility mechanisms.
According to the OASIS BPEL4People Technical Committee charter, the standardization should take about 18 months. During this period, it's reasonable to expect that the standard will not only become more rigorous but also include more functionality. Two enhancements that we hope will make it to the final standard are patterns and policies. We'd like to see support for common routing patterns (such as management chain approvals and group votes) in a simple, intuitive, and declarative fashion. Likewise, support for policies such as automatic skip and exception handling would be a welcome addition.
While it's reasonable to expect that meaningful implementations of BPEL4People will be available only when the specification approaches the finish line, there are vendors, including Oracle, that essentially implement very similar concepts in a very similar architecture. In fact, the BPEL4People specifications were created by leveraging customer scenarios and requirements learned from support of such implementations.
Also, within the broader umbrella of related standards in the business process management (BPM) area, the next frontier is standardization of notation and its alignment with BPEL and BPEL4People. Significant efforts are underway at the Object Management Group to define a Business Process Modeling Notation (BPMN) 2.0 specification.
Summary
The field of Business Process Management (BPM) is experiencing renewed effort, propelled by the success of BPEL as a standard and its adoption by mainstream vendors and enterprises. BPEL skills, training, and resources are now widely available and the move away from proprietary skills and technologies is driving a lower total cost of ownership (TCO).
The BPEL4People specifications address BPEL's lack of explicit support for human interactions and remove one of the very few objections to BPEL. The BPEL4People architecture, which separates the task engine from the process engine, also significantly reduces customer risk, because many customers can have multiple process engines but prefer to have a unified task list application.
BPEL4People, along with BPMN, will complete the BPEL story for process management. We believe it will significantly increase the market adoption of BPM by mainstream enterprises.
References
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
