Multiple Implementations

The implementing process definition to invoke at runtime can be defined either statically as an administrative action or determined from process data via Dynamic Sub-process Binding.

Primary Implementation

Per deployment of a provider model, for each defined Process Interface, a Primary Implementation can be specified. The Primary Implementation is identified by the model ID of the consumer model the Implementation is defined in. If not otherwise specified, the Default Implementation of the Process Interface is considered as Primary Implementation. Please refer to section Implementing Process Interfaces of chapter Creating Models With Cross References for details on process interfaces.

At runtime, if not otherwise specified (see below), whenever a Sub-process Activity associated with a Process Interface gets executed, the Primary Implementation of that Process Interface gets actually executed.

Primary Implementations can be freely redefined over time. If the uses link contributing a Primary Implementation ceases to exist, the Default Implementation associated with the Process Interface will be considered the Primary Implementation again.

Selecting Alternative Process Interface Implementations

If a runtime environment contains several implementations for a given process interface, it is possible to select the primary implementation to be invoked at runtime. The implementing process definition can be selected per process interface. Hence different implementations for the process interfaces defined in one model can be distributed over different models.

The following figure illustrates a model (Model I) having process interfaces defined with different implementations (using Model M), which are distributed over the different models (Model N, Model O, Model P).


Figure: Distributing Implementations.

Selecting an implementing process definition at runtime is not supported during model deployment, but can only be done in a subsequent administrative gesture.

Example

The following scenario describes this issue:
All models M1, M2 and M3 are already deployed in the system. Now an administrator configures process definition P' defined in model M2 as the primary implementation of interface I as shown in the following figure:


Figure: Selecting Alternative Process Interface Implementations

Dynamic Binding

Sub-process activities invoking a process with a Process Interface may be marked to be resolved at runtime. In this case a data path can be defined to pass the Id of model providing the implementation for the process interface to be invoked at runtime. Please refer to the section Dynamic Binding of Sub-process Implementation of the chapter Working with Process Interface in the Modeling Guide. for detailed information on marking a process interface to be resolved at runtime.

In case the process variable cannot be resolved properly or one of the requirements listed in section Requirements is not fulfilled, the process instance is put in interrupted state.

Using data-bound runtime binding allows scenarios like the following:

Requirements

Dynamic binding is only allowed if one of the following cases applies:

  1. The target model also implements the process interface to be used for dynamic binding.
  2. The target model is marked as an alternative implementation of the process interface that is dynamically bound, which means that the process interface could be rebound to the target model.