BPM step types

The step types JSON describes the step types that can be involved a process. Generally a project will use the standard Core BPM step types, augmented with some solution-specific step types, and reuse this for all processes. See BPM step type reference for a quick reference to the Core BPM step types.

The JSON is an array, each item of which specifies one step type.

[
{
"reference": "stepTypeReference",
"name": "stepTypeName",
"script": "stepTypeScript",
"userTask": true|false,
"properties": [
{
"reference": "propertyReference",
"dataType": "string|number|boolean|object|array|any",
"value": defaultValue
}, ...
],
"status": {
"state": "status",
...
},
"subStepTypes": ["subStep1", "subStep2", ...]
}, ...
]
reference Reference used to refer to the step type in the process JSON.
name Name for the step type
script Node reference of the step type script.
userTask Set to true for a task requiring user input, false if user input is not required. (If user input is optional - such as the Set step type, define two step type entries for it.)
properties A list of properties required by steps of these types (these form the config properties in the process definition).
properties[].reference Reference for the property, i.e. config property name.
properties[].dataType Data type, used to validate/convert incoming properties. A data type of "any", which is the default, means that data type can be anything (though it may be validated later).
properties[].value Default value for the property. This can be overridden in the BPM definition or the independent properties.
status

A status needs to be generated for every state that precedes a user step.

This status will have a reference of actionName.state

The status configuration allows different statuses to be used, to make statuses more user friendly. This is required because statuses are not user friendly, for example:

{
"submit": "open/Open"
}

This means "when the submit state is encountered, create a status of actionName.open/Open

If there is no status clause and statuses are required, a status of actionName.state will be generated.

A status value of true (not just a true-like value) means that the step will already have created its own status of actionName.state, and no status generation is required.

subStepTypes

This allows a number of step types to be represented by a single step type. For example, the Form step type may require a Set to create the form in the first place. This could be represented by a step type for "openForm", something like this:

[
{
"reference": "openForm",
"name": "Create and open a form",
"attributes": [
{
"reference": "dataReference",
"type": "string",
"defaultValue": "data"
},
{
"reference": "form",
"type": "object"
}
],
"subStepTypes": [
"createForm",
"openForm"
]
},
{
"reference": "createForm",
"name": "Create a form",
"script": "library.worker.SetStepType",
"properties": [
{
"reference": "dataReference",
"type": "string"
},
{
"reference": "data",
"type": "object",
"value":"${form}"
}
]
},
{
"reference": "openForm",
"name": "Open the form",
"script": "library.worker.FormStepType",
"userTask": true,
"properties": [
{
"reference": "dataReference",
"type": "string"
}
],
"status": {
"submit":"complete/Form complete"
}
}
]

The userTask and status properties are set on individual sub steps, not the main task.

The properties are defined at the group level and the sub level. This allows all the properties for all the sub-steps to be set in one place.

properties can use placeholders which refer to properties defined at a higher level. For example ${form} is used to set the data to the form property defined at a higher level.

Use the Object List Merge type to hold BPM step types. This allows different lists of step types to be merged, and allows solution-specific step types to be merged with the Core BPM step types.