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 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 three special states for exceptional situations:
interrupted if there is a temporary
problem in one of the activities waiting to be recovered.aborted after an administrator decided to
kill the process instance, abandoning any scheduled work for the
process instance.halting state,
and then in the halted state. It
resumes processing as soon as the newly started
process instance is complete. The halted state identifies that the process needs to be set to active
again after all newly started processes are complete.
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.