Using the process interface, a process definition of the provider model can be referenced in the consumer model. For the definition of the process interface, please refer to the chapter Glossary.
This chapter covers the following:
To define a process interface:
Open the property page of the process definition and click on Process Interface
Figure: Process Definition Properties - Process Interface
You can define the process interface using the following options:
Figure: Process Interface
So there are three valid states concerning declared and implemented process interfaces:
A model that wants to provide an alternate implementation of its process definition should opt for Implements Process Interface option. It provides an implementation for a process interface defined in a provider model file.
When you select the Implement Process Interface option, the processes available for implementation are listed.
Figure: Implements Process Interface
When you select the process to be implemented, its exposed parameters are listed under Process Interface.
Figure: Exposed Parameters
Select the parameter. Only Data attribute is editable.
Figure: Parameter - Data Attribute
You can define more than one process interface implementation per process model.
If the defined Implements relationship is no longer valid due to changed parameter types, an inconsistency warning is displayed.
A warning is displayed in the Problems View in the following cases:
Note
When implementing a process interface in a different model, make sure to import data that is used
in the process interface into the new model per reference. Creating data with the same Id is not
sufficient and data values passed by the process interface will not be passed into the
implementing process. Only data referenced from the model defining the process interface
can be accessed correctly.
No modeling validation is displayed to warn of this behavior.
Process attachments do not work in a scenario where a sub-process is invoked that is an implementation of a process interface and is defined in a different model fragment. In other words, documents uploaded to the root process should be visible in the sub-process and vice-versa. This works if the sub-process is defined in the same model as the root process and if the "Unique per root Process Instance" flag is set for the sub-process' Process Attachments. However, this won't work if the sub-process is in a different model. To achieve this, delete "Process Attachments" data from the consumer model and then copy (drag and drop) "Process Attachments" data from the provider model to consumer model. Then, deploy both the models.
This property defines the process interface. A model that wants to expose its process to other consumer model should choose this option. When a process interface property of a process definition is set to Provides Process Interface, it can be referenced from the consumer model.
Select the Provides Process Interface property and click on Add.
Figure: Provides Process Interface
Specify following parameters to be exposed as IN/OUT values for referring model.
IN - for read accessOUT - for write accessINOUT - for read and write access
Note
Primitive Enumeration types are not supported as formal parameters in case of
SOAP and REST external process invocation. Use a structured data type embedding
the required Enumeration type instead.

Figure: Process Interface Parameters
When the user defines a process interface, it is possible to specify how the interface is invokable:
For more information on REST and SOAP endpoints, please refer to the chapter Process Interface - External Invocation Mechanism of the Programming Guide.
To provide the remote invocation:
Figure: Invocation Type - WSDL
Figure: Generated WSDL
For more information, please refer to the WSDL/XSD mapping section.
When Web service endpoint (SOAP) is selected a read only text area shows the WSDL code corresponding to the defined parameters. For the selected Process Interface a WSDL for WS invocation is created in document literal style (request/response message pair). The specified input and output data are mapped to XSD structures according to the following rules:
In case if at least one of the formal parameters does not satisfy the requirements for the external invocation, a validation error is displayed in the Problems view. Further, the corresponding WSDL code cannot be generated as the Generate WSDL button is disabled.
The referenced process definition becomes the subprocess in the referencing model. For more information, please refer External Model Fragments section of the External Model Resources from the Developers Handbook. To define the subprocess implementation for referenced process definition:
Figure: Referenced Process - Subprocess
Figure: Subprocess Implementation
If the selected subprocess is a referenced process from a provider model then the following execution types are available:
By default, Synchronous / Separate Data is selected.
Note that in these cases invocation at runtime is always done via the process interface.
If the selected subprocess is a process from the same model
then the subprocess will be invoked directly at runtime as no process
interface exists. For more information on execution types of such
subprocess, please refer to chapter
Configuring Subprocess Activities
.
Figure: Display Imported Model Element as Groups
To create data mappings related to the process interface parameters, you can use processInterface context. Process Interface context in data mapping will only be available in the process which has references to other model. For example, the referenced subprocess of the consumer model will have the process interface context.
Figure: Process Interface Context
To define the process interface context:
Figure: Add Process Interface Context
Figure: Process Interface Context Parameters
Dynamic binding enables you to choose the implementation model at runtime. To enable the dynamic binding, you can mark the subprocess activity that invokes process interface, to be resolved at runtime.
Open the properties of the referenced process definition and click on Runtime Binding.
Figure: Subprocess Activity
Select the option Subprocess is resolved at runtime.
In the Data drop-down list, it is mandatory to provide the target model, implementation model ID or a qualified implementation process Id with type String. The implementation model ID is used to invoke the process definition that implements the selected process interface. Using a qualified implementation process Id allows to have multiple implementing processes in the same model and to select the intended process by the qualified process Id.
Figure: Subprocess Activity - Runtime Binding
Qualified ID should be specified in the following format:
Qualified ID = {Model ID}Implementation Process ID. For example, {Model13}ImplementerProProcess1
Note that the ID of the implementing process definition is fetched from the declared implements relationship to the process interface.