Pool and Lanes
Introduction
BPMN provides features to model who is performing activities and tasks in a modeled business process.
Current Support
Flows for APEX supports a process running in a pool of 1 or more lanes. Within a pool, process progression occurs using sequence flows. A well-formed BPMN diagram will contain named lanes showing who performs the process activities.
In this example, the process occurs in one pool (“MyBigExportCo”), and has three process lanes - Sales, Finance, and Shipping.
When this example is run, the lane information of the current tasks on each running subflow are available to the application, and could be used to make next task inboxes for users servicing that pool.
Lanes and Call Activities
A Call Activity is used whe one diagram calls another as part of a single process.
With a Call Activity, the Calling Diagram may, or may not, have lanes. Similarly, the Called Diagram may, or may not, have lanes. There are no restrictions imposed by Lanes. If no lanes are present in the current diagram, lane information is inhereted from the calling task (if available).
| Lane Behavior | Called Diagram Has Lanes | Called Diagram Has No Lanes |
|---|---|---|
| Calling Diagram Has Lanes | Lanes are used from the Called Diagram | All activities in the Called Diagram occur in the Calling Task’s lane in the Calling Diagram |
| Calling Diagram Has No Lanes | Lanes are used from the Called Diagram | No Lanes Are Used |
Cross Pool Processes
Processes which are defined with multiple pools use message flows and signal flows to define communication between process objects in different pools, rather than sequence flows which are used inside a pool.
Flows for APEX does not currently support processes using message flows and signal flows, and so multi-pool diagrams cannot currently be run.
This example models (correctly, in BPMN terms!) the customer and company in separate pools. However, Flows for APEX cannot currently handle messageflow across pool boundaries. sequenceFlow has to be contained inside a pool.
Multi User Pools and Task Reservation
If you are using Flows for APEX for task orchestration or have an application where users are provided with a task inbox, all users who are serving a lane will see all of the current tasks in that lane. Task Reservation provides a mechanism for users who are sharing a lane to record that they are working on a task, or intend to work on a task, so that other users don’t also work on the same task.
User Tasks can be reserved , or claimed, by a user by calling the flow_api_pkg.flow_reserve_step procedure. When you reserve a step, you supply a reservation as the p_reservation argument. This would usually be set to the username of the user making the reservation - although an application might want to have some other scheme for reservation value.
A reserved / claimed task reservation can also be explicitly released by calling flow_api_pkg.flow_release_step procedure.
Reservation only applies to the current step on a subflow, and is implicitly released when the step is completed and the process continues to the next step, i.e., when flow_api_pkg.flow_complete_step is called.
The Flows For APEX Task Reservation is a light weight mechanism to signal to others that this task is reserved and will be worked on by the reserving user. Out of the box, it is not a security mechanism to prevent unauthorized users from working on a task. You should not solely rely on this mechanism to control task authorization or other access control objectives.
As part of your application design, you might want to wrap these procedures with your own application-specific controls to implement control on who can reserve (and for whom), and who can release reservations.