BPM definition

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":"processReference",
  "name":"Process name",
  "properties": {
    "reference": value,
    ...
  },
  "steps": [
    {
      "reference":"stepReference",
      "name":"Step name",
      "role":"role",
      "stepType":"stepTypeReference",
      "properties": {
        "reference": value,
        ...
      },
      "flows": {
        {
          "flow": "flowReference",
          "target": "target",
          "role": "role",
          "name": "name",
          "state": "state",
          "status": "status",
          "action": "action",
          "reference": "value",
          ...
        }, ...
      }
    }
  ]
}

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. A reference of null indicates that this is a placeholder step. This can be used to generate status rules, and as a target to generate flow rules from other steps, but will not generate a process step.

This can also be set using the property stepType.

steps[].properties

Name:value pairs for the properties for the step.

steps[].flows

Flow properties.

Properties of flows that start at this step and end at the step identified by target.

Any properties are allowed, but some have specific meanings.

target	The reference of the target step, i.e. the end of the flow.
flow	Reference for the flow, which should be unique among the flows for a step, i.e. which flow it is. Defaults to the value of state or submit.
name	A name for the flow.
state	Indicates that a process flow execution rule should be generated to represent this flow, i.e. a "next" clause. Process flow execution rules control the execution of the process itself. They use an in-memory attribute "state" to indicate the outcome of a step, and then use a "next" rule to determine what to execute next.
status	Indicates that a status rule should be generated to represent this flow. Status rules control the options offered to the user, i.e. menus. They use an in-data "status" value to indicate the business status of a process, and then use a status rule to create a menu item offer the option of running the target step to the user. This must be the status reference, not a combination of status reference and name (e.g.. it shoud be "documentSubmitted", not "documentSubmitted/Document submitted".
role	When generating a status rule, the user role, which defaults to "user". Note that this is a very different propery from the "role" on the step type, which indicates the party involved (e.g. "owner", "supplier").
caption	When generating a status rule, the caption for the menu item. Defaults to the name.
action	Defaults for status rule action. This is useful for setting sets of properties in an independent property file, or setting status rules properties (such as target) which have a special meaning within the process compiler.

It is important not to confuse the state and status properties. State is about the automated system execution of the process, what steps the system will do next. Status is about the manual user execution of the process, what steps are offered to the user next. A flow with both state and status is possible - it is used to present the next step in the process immediately to the user, but in a way that allows them to cancel out of the step and return to it later.