Processes

In MDW, a process is used to model a business process, which consists of a number of (automated or manual) work items or steps, called activities and they are performed in a designated sequence. A process is a collection of activities and transitions between those activities and is mathematically and graphically represented as a (typically acyclic) directed graph.

The process flows through one or more out-bound transitions to start other activities that depend on the completion of the first. A process can invoke another process through a subprocess activity.

One of the benefits of a defined business process is that it can be applied repeatedly to many data instances. We use the terms process definition vs. process instance to differentiate between the template that describes the process and a particular execution of that process. As an example:

Transition with no Label: This describes how transitions without a label is used.
- Acts as Default: if the completion code does not match labels of any outgoing transitions, the transitions without labels are then traversed. The transitions are also traversed when the completion code is null.
- Matches Null Return Code: with this option, transitions without labels are only traversed when the completion code is null. If a transition should be used as default, the special label DEFAULT must be specified.
Process Type: Regular or Service. See below for description of service processes.
Transition Retry Count Default: the value can be either "Retry unlimited" (allowing unlimited retries), or "Retry not allowed" (allowing no retries). Note that this attribute only sets the default for newly created transitions. You can always set individually the transition retry count after the transitions are created. Also note that if you change the value of this attribute, it will not change the existing transitions.
Performance Level: It specifies a performance level for running this processes. See the section on performance level below for details.

Service Processes

Typically, a process is started asynchronously (fire-and-forget), which means the originator does not wait for the completion of the process. However, it is often desired for applications to create a workflow process to provide services, which return a synchronous response to the requester in real-time. To allow a synchronous process, MDW uses the term Service Process.

The service process is executed in a single thread without using the internal JMS messages. This is to allow the response be captured and sent back to the invoker. A service process is defined and handled pretty much the same way as a regular process, with some limitations incurred by the requirement that they are executed in a single thread.

In MDW, the service process provides the following:

Parallel branching, namely all transitions out of an activity must be mutually exclusive.
Activities can suspend (wait for timer, external event, manual response, etc). This means that the timer wait, event wait, sub process invocation, manual tasks are not allowed. Adaptor activities are allowed, but you cannot get responses from asynchronous adaptors, as that will require event wait activities. As a result, fall-out subprocesses and fall-out tasks are not allowed.
The process should define an output (or input/output) variable named "response" and set its value, which is used to return as a response. The variable is typically a document of XML Bean type, although any other type can be used and the return message as a String will be translated by the variable translator.

Service process has two exception rules:

For main service process that is started from event handlers using API call to the method ProcessEngineDriver.invokeService(), if the performance_level argument is passed in with a non-zero value, then this performance level is used.
For a service process started as a subprocess of another service process, its performance level is inherited from the parent process.

Performance Level

The following table describes each of the performance level used in MDW:

Performance Level	Description
0	To be determined by a property or process attribute, which will set the level to one of the following (1, 3, 5, 9).
1	All process, activity, transition and variable instances as well as documents are persisted in a database. No in-memory cache is used.
3	All process, activity, transition and variable instances as well as documents are persisted in a database, but variable instances and documents are cached for each engine processing session to speed up the read access.
5	This is for service processes only. All processes, activities and transition instances are persisted in a database; variable instances and documents are created in memory cache only and it's not persisted in a database.
9	All process, activity, transition and variable instances as well as documents are stored in memory cache only. No database persistence is used. For service processes, one memory cache is used for each top level invocation to a service process; for regular processes, a shared memory cache is used for all executions at this performance level.

The performance level of a process instance is typically determined by the performance level attribute configured for its process definition, and when the attribute is not configured (is blank, 0, or null), the default performance levels are used. The following two properties are used to specify default performance levels:

mdw.performance.level.service: defines the default performance level for service processes. When the property is not defined, the hard coded default of 3 is used.
mdw.performance.level.regular: defines the default performance level for regular processes. When the property is not defined, the hard coded default of 3 is used.

Request Path Registration

A REST request path can be registered to automatically invoke a service process and bind request and response variables. Use the Request configurator tab in MDW Studio or MDWHub to do this.