A business process consists of a network of activities performed to achieve a certain objective and execution rules for these activities. In short, it captures what is intended to happen. A formal representation of such a process for process automation purposes is called a process definition.
A process definition identifies the various process activities, procedural rules, control flow and data used to manage the process during process execution. Several different processes will usually be defined within one company (e.g. order processing, invoicing, complaint management), which will be collected in a workflow model as described above.
More formally, a process definition includes as a first level container the definitions of
As a model element a process definition has the following properties:
A sales management process, for instance, could be defined by a description of activities including cold calling, gaining a prospect, processing an order and changing the status of the prospect to customer, followed by the invoicing. Together with transitions between these activities describing the control flow, this results in a complete process definition.
If processes become too complex, parts of an elaborate process can be defined in individual process definitions, e.g. an invoicing process may be defined as a separate module then used as a sub-process of the sales management process.
A process definition in Stardust is visualized by a red and a blue gear.
When a process model is deployed to the Stardust Process Engine, the processes defined in the model can be instantiated. Multiple instances of a single process can be created and executed in the process engine. The execution of a process always follows the description provided in the corresponding process definition.
Process instances have a persistent representation in the audit trail. Refer to chapter Audit Trail Persistence for details on the different persistence modes provided by Stardust.
During its lifetime a process instance passes through several states. It is created in state created and turns to state active after it starts its work. When the process is regularly finished it turns to state completed. There are two special states for exceptional situations:
Figure: Possible Process Instance State Changes
Both, the completed state and the aborted state, are final states: the process instance can never show any subsequent activity after going to one of these states. Process instances, which are completed or aborted, are referred to as terminated process instances. Initialization of abort may result in aborting state (an intermediate state) if the process does not get aborted successfully or the time span is large before abort. If it gets aborted successfully then it achieves the aborted state else it remains in aborting state.