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.
For details on using process definitions in the Eclipse Modeler and the Modeling perspective, please refer to chapter Working with Process Definitions in the Eclipse Modeling Guide and chapter Working with Process Definitions in the Business Process Modeling Handbook respectively.
When a process model is deployed to the Infinity 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 Infinity.
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 three 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 the aborting state.
However, halting is an intermediate state. When the process is paused it may remain in halting state for a while before going to the halted state. Halting may appear if the JMS is processed or retried asynchronously. Once halting is successful, the process goes into the halted state.