The BPM definition describes a process in simple terms, in a way that is convenient for bridging between a BPM tool and process execution. It is different from the process definition, which is an executable version of the process, and which has more detail on it.
The BPM definition has the following structure.
|reference||Reference for the process. Use a reference of 'start' for the first step in the process.|
|name||Name of the process.|
|properties||Properties for the process.|
|steps||Array of steps.|
|steps.reference||Reference of a step.|
|steps.name||Name for the step.|
|steps.role||role that perform the step. The default is "owner", which means that the step is performed by the process owner.|
|steps.stepType||Reference to step type.|
|steps.properties||Name:value pairs for the properties for the step.|
Flow rules. This is a lookup on state that describes the next steps that should be available. Each step can be labelled as immediate, which means that for user tasks the user will be taken to the task immediately, and for non-user tasks the step will be run synchronously. For non-immediate user tasks, the task will be available in the user's task list, and for non-user tasks the step may be run asynchronously.
Use a state of "*" if there is only one flow rule.
As well as the mandatory step property and optional immediate property, the flow step can contain other properties. These are used to further parameterise any additional steps that are generated to support the flow, particularly flows between roles that have a send step and a receive step. In particular, the dataReference property can be used to identify a data store that should be copied from the sender to the receiver as part of the flow.