Flows — Concepts and terms |
A flow describes a business process. One representation of a flow is a network of shapes and connectors (directed arrows), each with associated parameters and values. Flows govern:
Flows are the fundamental rule instances that represent business processes, identifying who works on a work item in what sequence, what decisions and processing occur automatically, and many other aspects of the business process.
Some applications don't require users to interact with user forms. Flows that implement straight-through-processing operate without user input. External portals and systems can execute flows through Active Server Pages, JavaServer Pages, Service Portlet or Service JSR94 rules, or other means. Informally, these are known as "headless" BPM applications. A collection of standard activities, flows, and flow actions known as the Process API simplifies building such applications.
On the Diagram tab of a flow, you can interact with three alternative presentations of the flow diagram:
New in V6.2, Process Modeler allows more direct manipulation of shapes, connectors, and layouts directly in a browser window. Process Modeler is recommended for new flows developed in V6.2+. All runtime capabilities of Visio-based flows are also available in Process Modeler -based flows.
Application developers use Microsoft Visio to create, edit, and evolve a flow. PRPC uploads the resulting VSD
file, including the Shape Parameters details from the workstation. Both the diagram image (a JPG file) and the rule details are saved with the flow.
To start Visio on your workstation, click the Flow Edit toolbar button (). Create and evolve the flow in Visio as needed using familiar Windows techniques such as drag-and-drop. As you work, you can enter the names of utility shapes, decision shapes, assignment shapes, router shapes, flow actions and the rules that these shapes reference. If some of the activities and other rules for these shapes do not yet exist, you can leave the rule in draft mode.
As you exit from Visio, the system uploads the flow diagram (and the extensive data structure that Visio contains), and saves it in the flow.
You can't test a flow that has Availability set to No/Draft. You can test the flow if the Availability is set to Yes
, even if the Visio DRAFT mode () is in force, indicating that not all the activities, properties, or other rules are yet defined.
Runtime processing — The simple case
At runtime, a user can start the execution of a flow by entering a new work item. The system examines the property pyFlowName, in the data transform instance for the class, to determine which flow to start. The flow operates on the work item to advance it through the business process that the flow implements, performing automated steps automatically, or creating assignments for users as appropriate.
You can think of a work item as located "on" one shape or arrow of the flow at any one instant, until the work item becomes resolved or the flow ends. Alternatively, you can think of the flow operating on the data (properties) in the work item until the flow finishes or the work item becomes resolved. Both points of view are correct.
A flow may define many optional detours, side trips, and branches reflecting decisions reached along the way. The path that one work item follows through the flow depends on its own requirements, automatic decisions in rules (such as decision trees and map values) and on available resources. For example:
As a flow executes, the following processing often occurs:
The Process Explorer tool presents — for the currently selected application — starter flows and the subprocesses they call in a graphical form. See Process and Rules category — Processes page.
Parallel processing with Split Join
In some business processes, the order of certain steps is not important as long as all the steps get done. In other situations, a step can be considered complete when either of two other steps finishes.
The Split Join facility ( or ) supports such asynchronous operation, by allowing processing of two or more subprocesses to proceed in parallel. For example, a contract may need approval of both a legal reviewer and a purchasing department reviewer, but order is not important. In the 1980's era of paper forms and in-boxes, only one of these two has the paper — artificial sequencing. With a work-object and a flow that uses Split Join, each subprocess can create an assignment, and the two reviewers can proceed independently.
See Flow form — Editing in Process Modeler — Split Join shape properties and Flows — Editing in Visio — Split Join shape.
Split Join parallel processing occurs only when considered at the business process level. Although two assignments exist, they both belong to a single work item. During the minutes or seconds that either user performs the assignment (thus updating the work item), the system locks the work item and so the work item is not available to the other user.
Similarly, at a more atomic level, if the two users both access a single-node PRPC system that has a single JVM and single CPU chip, no parallel processing occurs at the Java thread level, even when the two users work on different work items.
Parallel processing with Split For Each
The Split For Each facility ( or ) causes multiple subprocesses to start, one for each page of a Page List
property. Processing can resume after any one, or all, of the subprocesses end.
See Flows — Editing in Visio — Split for Each shape and Flow form — Process Modeler — Editing the Split For Each shape.
Parallel processing with Spinoff
A Spinoff shape starts asynchronous execution of a different flow, on the same work item or a different work item. Processing of the current flow does not pause or wait for results from the other flow.
To create a spinoff when editing with Process Modeler, use a Subprocess shape ( ). Select the Spinoff Flow checkbox. See Flow form — Editing with Process Modeler — Editing the Subprocess shape properties.
To create a spinoff when editing with Visio, add the Spinoff shape (). See Flows — Editing in Visio — Spinoff shape.
Parallel processing with Start a NewProcess and flow actions
PRPC offers ways for a flow execution to be started for an existing (open) work item. These are alternatives to calling a subprocess, using a Split Join shape, or using a Split for Each shape:
Data structure for flow executions
Several system-maintained properties in a work item record the current state of flow executions in process. For example, the integer property @baseclass.pxFlowCount indicates how many flow executions are in process for the work item.
The Page Group
property @baseclass.pxFlow contains a page of facts about each execution: