Process definition

The underlying Metrici Portal provides a process execution capability. This orchestrates multiple script-based steps into an overall process. The process allows configuration to be passed into the scripts, and for data and flow control to be passed between the steps.

The process is driven by a process definition which is encoded as JSON. The easiest way to create this for a complex process is to use a business process modelling tool to create a process diagram and then to import it, which is described The Business Process Model (BPM) interface. However, it is briefly worth describing the underlying capability and setting up a simple process flow using it.

Here is an example process, coded as JSON.

[
  {
    "name": "@init",
    "script": "set",
    "config": {
      "show": false,
      "status": "initial"
    },
    "next": false
  },
  {
    "name": "hello",
    "script": "form",
    "config": {
      "form": {
        "fields": [
          "<p>Hello, World!<\/p>"
        ]
      }
    },
    "next": {
      "submit": "done",
      "*": false
    }
  },
  {
    "name": "done",
    "script": "set",
    "config": {
      "show": false,
      "status": "done"
    },
    "next": false
  }
]

The process definition is a JSON array of objects. Each object represents one possible action that the process can carry out. Each action has:

• A name, which is used to invoke the action.

• A script, which defines the action to be run.

• A config object which passes configuration to the script.

• A next value or object which specifies what should happen when the script runs.

For worker processes, the script must reference one of a defined set of standard scripts which are considered safe to receive from a partner because they have no impact outside of the individual worker. You can get the up-to-date list of possible scripts from Standard Worker Step Types. The process definition script value can be the node reference of the script, or a reference which is resolved using the bindings list further down the page.

Different scripts have different config. In the example above:

• The @init step sets the status to "initial".

• The hello step shows the user a form with the message "Hello, World!" on it. The form will also have a submit button on it.

• The done step sets the status to "done".

The next property indicates what should happen when the script has run. It defaults to true, which means to run the next step. It is set to false to run no more steps. If the next propery is an object, it specifies what step should be run depending on the value of a special attribute called "state". After the hello step, if the state is "submit" (which means that the user has pressed the submit button on the form), the done step should be run. Otherwise (the * means "any other state"), the step should end.

To create a process in your library area, create a node of type library.process.ProcessType. On the first tab, call it Hello World Process, and on the Process tab, and paste the process definition JSON into the Process definition box.

Below the process definition, enter a binding for form to library.worker.FormStepType, and a binding for set to library.worker.SetStepType. (If these fields are greyed out, you will need to switch off session protection – see Portal settings for details.) The Process tab should look something like this:

Save the process definition.

As well as entering JSON directly, or using a business process model diagram, there are other ways of creating process definitions: a process builder which builds processes from configuration and flow rules entered on forms, and a process step type that allows individual steps and their configuration to be reused. For the process client, it generally makes sense to use a direct JSON definition for very simple processes and a business process model diagram for anything else.