This section explains the object model of a process definition within ProcessMaker. The objects are defined according to the following legend:
- Main or parent object
- Child object
The Process object is located at the top of the object hierarchy. Any business case is always an instance of an existing process definition.
A process is composed of one or many tasks
A task corresponds to a rectangle in a Process Map. This object has a rich set of properties and dependant objects, as it defines the interaction of every object residing inside the business process definition, such as users, derivation rules, dynaforms, input and output documents.
A Task is composed of one or more Steps.
A step can be composed of a sequence of DynaForms, input documents and output documents. The Derivation Step is always executed upon task completion.
Derivation Rule Object
The derivation rule objects connect two or more tasks, and in this way they define the workflow thread. In this sense, the workflow thread can be sequential, or it can be defined through an evaluation. Likewise the thread can be selected according a decision. The thread can be forked in two or more sub-threads and later they can be joined together. Finally the workflow thread achieves the end of the process.
This object is a main component of the task user interface. It allows a direct human-workflow interaction by means of a distributed web application approach. A DynaForm definition reflects the data structure of the underlying database storage engine A dynaform has the following structure:
A Trigger is a piece of code. It is intended to add flexibility when dealing with complex business rules. Most business rules are far more than simple Boolean conditions. In such scenarios, Triggers provide the appropriate framework to perform complex calculations, to name a few.
Triggers have the following structure
PHP code can be injected directly by means of Custom Functions interface. This allows business architects to express the most complex business rules by means of a high level programming language.
A case variable can be the value stored inside a DynaForm field, or the result of a calculation inside a Trigger. Likewise there are system variables.
A case variable must have a unique name and can be overwritten as the business case moves forward. To reference a Case Variable within the process definition, it must always be prefixed with a double “at” sign (@@). To evaluate a Case Variable it is possible to use boolean expressions which will return either true or false.
Case variables can be used with different aims; among others they are useful to define conditions for derivation rules by evaluation, to customize output -documents or labels cases.