BPM properties

The BPM properties structure contains properties that can override or default properties in a process. They are termed "independent" because it is independent both of the BPM process and the BPM step types.

Independent properties can be used to:

  • Provide implementation detail that is difficult to express within a BPM tool.
  • Parameterise processes, allowing the same BPM definition to be used for more than one executable process. For example, an "authorize document" BPM could be parameterised to be used with different documents.

Properties are ultimately used to set the configuration properties associated with executable process steps. Properties can provide defaults or overrides to other properties.

Properties can apply to a single step or globally. Global properties can provide defaults to step properties.

Step properties can be defined in three places:

  1. The BPM definition (including steps and flows)
  2. The step type definition (including sub step types)
  3. The independent properties

Global properties can be defined in two places:

  1. The BPM definition
  2. The independent properties

For a step in the executable process, the list of properties is defined in the step type definition, or, if there are sub steps, on the sub step type definition. Without any placeholders in effect, the value of a property is looked up from:

  • The value of the BPM step property.
  • The value of the BPM global property.
  • The value of the independent process step property.
  • The value of the independent global property.
  • The value of the step type property default.
  • The value of the sub step type property default.

This requires some explanation:

  • The model takes precedence, and step properties have higher precedence than global properties.
  • The independent properties come next, and step properties also have a higher precedence than global properties.
  • Property defaults come last. Sub steps come after their containing steps (even through it is the sub step that defines the list of properties) because super-steps may be used to further configure the sub steps. For example, you might have a confirm sub step which has "OK" and "Cancel" buttons, and then use a super step to further configure this to have "Accept" and "Cancel" buttons.

Placeholders can be used to force the selection of a value from a source with lower precedence. Placeholders can have defaults, using the form ${placeholder,default}. So, for example, in the BPM step, you might have a placeholder for a confirmation content property.

"properties": {
  "content":"${content,<p>Are you sure?</p>}"
}

This will look for content in an area with lower precedence, but if it cannot, will return "<p>Are you sure?</p>".

If the placeholder has the same name as the property, then it will search for the property starting at the next level down in precedence. If it has a different name, then it will search for the property starting again at the highest level of precedence. This allows like-named configuration properties within sub step types to be given aliases. For example, if a step type broke down to two "set" sub steps both with content, you could define them to look for a property with a different name. In the step type JSON, this would look something like:

"properties": [
  {
    "reference":"content",
    "dataType":"string",
    "value":"${confirmationContent,<p>Are you sure?</p>}"
  }
]

This will look for the confirmationContent property, and then set the value of the content property on the sub step to that.

If you have two sub step types with the same-named property that need to contain different values, you need to alias each one of them as in the example above, to enable them to be set independently. If you alias just one of them, then the aliased one will always pick up the non-aliased value.

The independent properties is a block of JSON with the following structure.

{
  "global": {
    "name": value,
    ...
  },
  "stepReference": {
    "name": value,
    ...
  }
}

Each step can have a set of named properties. The special value of "global" is for properties that apply to the entire process or to all steps.

The independent properties can also have objects for each of the roles. These can be used to provide additional process definition, status rule definition arrays or paths, as in the following example which adds to the status rules for the respondent role a download report action for all statuses other than null and initial.

{
  "respondent": {
    "statusRulesDefinition": [
      "role": "user",
      "status": [
        "!null",
        "!startProcess.initial"
      ],
      "action": {
        "action":"respondent.downloadReport",
        "caption":"Download report"
      }
    ]
  }
}

Process definitions and paths are added in the same way, using the property name "processDefinition" and "path".

The process definitions and status rules are not touched by the compiler, and are simply appended to the generated output. Some care will be required to make sure status and action names match those in the generated output.

use the Node Options Extend to hold independent properties. This allows multiple sets of properties to be combined.