The alternative Process (library.process.ProcessBuilderType) type can be used to create a process and associated status rules from a set of nodes, rather than in JSON.
The process is built in edit mode, and presents a table of action nodes which can be created, maintained, linked and ordered.
The action page allows a reference to be entered for the action. This is the action parameter passed on the execute, and should be a simple reference without spaces or special characters.
Each action node presents a table of steps and a table of status rules.
Each step has a type, which acts as the "task script" within the process. The step type also defines fields that will be used to enter the config parameters for the step.
In the example below, there are three steps, using three different types.
Different step types will have different data requirements. All steps allow a name, step reference and description. The step reference is only required if this step needs to be referenced by other steps.
In this case, there is a tab to control the setting of a status, though different step types will have different, or no, additional parameters.. These values are written to the config property of the task.
There is only one built-in step type, the script step. This presents a script tab in which the logic of the script can be written.
The steps also define flow rules, which are used to form the next property for the process task.
Each flow rule equates a state produced by the step to an outcome, which can be to run the next step in the action, exit the action, or jump to another step. If the last of these is set, the reference of a step in this action or another action should be given.
Status rules are defined in a status rules table on each action.
Each status rule relates one or more statuses and one or more roles, and indicates that the action should be available under that combination of status and roles.
The action can be given a visibility and popup indicator also.
The available statuses and roles are looked up using the bindings statuses and roles respectively, which should identify a node of type Node List in which the Node List field lists the avaiable statuses or roles.
Roles should use the Reference type and provide a short reference for themselves. The visibilities similarly use the reference type and are identified within the status rules by a short reference.
The process provides documentation tabs for the process and status rules.
Within the process documentation, you will see that each action is represented by a task with no script. Also, steps with references are converted to action references made from combining their containing action reference and the step reference.
Creating new step types
The step type acts as the task script, and should have a Script to that end.
The step type must also derive a JSON version of the task in the Data field. A standard script, the Process Step Builder Script, is available to build this, which can be used within a Type Derivation Script. An example is given below.
* Create a node data structure that represents the process task
var context = application.getContext();
var mtStatus = application.getBinding('mtStatus');
var mtInstructions = application.getBinding('mtInstructions');
var mtTypeOfEvent = application.getBinding('mtTypeOfEvent');
var mtPermission = application.getBinding('mtPermission');
var psb = new ProcessStepBuilder();
psb.config('typeOfEvent',context.getTarget(mtTypeOfEvent) || context);
A Sample Step type is available as the basis for creating new step types. It includes an outline script for a step that shows a dialog to the user.