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 it matched with a BPM step type, and this is used to create an executable process step.
Other things may happen:
- Properties from the BPM process and step type will be used to create executable process properties.
- Flows with a state property will be used to create the next clause on the executable process step.
- Flows with a status property will be used to create status rules for the target step.
- Step types with sub step types will be used to create multiple executable process steps.
Additional steps will be generated:
- A Send process step will be generated for the process of each partner. The path will be read from the global properties "role.path", where role is the role of the partner. You can set this using the path property of the appropriate process flow.
- An @init step will be generated which will invoke the appropriate Send process steps and then the defined start step.
Properties
The BPM properties describes the general idea of properties, placeholders, and precedence rules.
Properties can be defined on BPM steps and flows. The flow properties are copied to both the source and target step types.
For each BPM step, two properties are generated:
- step - reference of the step itself
- step.name - name of the step
On the source, If a flow property exists with value flow, the generated properties are:
- target.flow - reference of the target step
- target.flow.target.name - name of the target step
- target.flow.target.role - role of the target step
- target.flow.ref - the value of the flow property ref
A set of properties with a flow of * will also be generated. If there is more than one flow, this could point to any of them. However, in situations where a single flow is expected, then this can be used. In particular, in something like a send process, which has only a single output flow, the property "target.*.target.role" can be used to identify the role to which the data should be sent.
A corresponding set of properties is added to the target, but prefixed with "source.".
Note that these are property names with dots in them, not nested objects, i.e. the generated property will be like:
{
"target.submit": "sendResponse"
}NOT
{
"target": {
"submit": "sendResponse"
}
}State
A next clause will be generated for each flow with a state property. For example, a flow with
{
"state": "submit",
"target": "sendResponse"
}will generate a flow rule
{
"next": {
"*": false,
"submit": "sendResponse"
}
} A default "*" rule will always be generated unless one of the flows has a state of *.
Status rules
A status rule will be generated for each flow with a status property. The status rule will use the status property as the status. This should be just the status, not the "statusReference/Status name" form. It will default the caption to name of the target step, though this can be overridden using the caption property. It will default the role to "user", though this can be overridden by the role property. Other flow properties will be copied to the status rule as is.
Sub steps
If the step type has sub steps, executable process steps will be generated for each sub step (not for the containing step). Sub steps may not be nested.
Sub steps may contain objects with reference, suffix, when, name and flows. See BPM step types for details.
Additional process and status rules definition
The role properties object can contain additional processDefinition and statusRulesDefinition arrays, which will add additional process definition items or status rules definition items to those generated.
This is commonly used to add an @display action. For example, if you want to direct the @display action to the view aciton for the owner role, you could add.
{
"owner": {
"processDefinition": [
{
"name": "@display",
"script": null,
"next": "view"
}
]
}
}