The process compiler generates an executable process definition and status rules from a BPM definition, BPM step types and BPM properties.
In the simplest case, a step in the BPM process is translated into an action in the output process definition, using properties to set config properties. However, the following may also happen:
- An input step may be translated to multiple steps, if sub-steps are permitted.
- Flow rules (next clauses) and status rules are defined to reflect the dependencies. Flow rules are used for non-user steps, and status rules for user steps. All user steps must be preceded by a step that sets a status. Immediate user steps have both flow rules and status.
- Where dependent steps are user steps, an additional step may be inserted to translate the runtime state into a status. The statuses are of the form action.state, so that each state from each step has a different status. Status names can be used to make this more understandable to the user.
- For dependencies that cross role boundaries, the boundary cross will be represented by a Send step which invokes the step in the other role. If the other role step is a user step, it will be preceded by a Set step that sets the status in the receiver role.
- A Send process step will be generated for the process of each partner.
- An @init step will be generated which will invoke the appropriate Send process steps and then the defined start step.
A step to set the status will be generated for a flow to a user task. A send step will be generated for a flow to a task for another role. Both will be generated for a flow to a user task on the other role.
Additional properties can be added to these tasks by adding properties to the flow. These can optionally be preceded by a prefix of "setStatus", "send" and "receive". For example, adding the property "createEvent" to a flow to a user task for another role will create an event for both the sender and receiver. Adding the property "send.createEvent" would add it only to the send.
The main use of these properties is to send data to flows to other roles (since the process client uses a data movement rather than data sharing), which can be achieved by setting the "dataReference" property to the reference of the data you want to send.
State and status handling
During process execution, each step records its outcome by setting a "state" variable, and flow rules (the "next" property in the process step) are used to pass execution to following steps.
This is used for all non-user tasks.
The state variable is a temporary in-memory variable. It cannot be used to control user tasks because the user may choose to perform the task later. Instead, statuses are written to the worker node and status rules defined to offer the task to the user. If a dependency to a user task is marked as immediate, flow rules are defined as well as setting status - the status is still needed just in case the user cancels out of the task, to allow them to go back to where they were.
The status clause on the preceding BPM step type controls how statuses are generated. If this is omitted, statuses are generated automatically when required. If this contains a lookup of state to status, then the specified statuses are set and used. If the step type will create the correct statuses, set the status clause is set to true (not just a true-like value), to indicate that no further status generation is necessary.