Models can use the following model elements from other model files via reference:
The following figure illustrates a model (Model 1) using elements from another model (Model 2).
Figure: Model 1 using elements from Model 2.
The following sections describe
In a provider model, you can mark applications that should be available for usage in other models, as public. Thus, they can be used in the consumer models referencing this provider model.
Application activities can use application types from another model.
Structured Types can be marked visible and thus available for consumer models. Thus, consumer models referencing the provider model can use those Structured Types definitions.
For detailed information on how to mark a structured type visible for other models, please refer to the Composite Types section of the chapter Defining Structured Types in the Modeling Guide .
You should mark data of the provider model as public. Then only the consumer model can reference the data. All data are supported.
The participant marked as public can referenced in the consumer model.
In case a provider model has defined a process definition to expose its process to consumer models, the consumer model can implement this interface for sub-processes and applications.
A Process Interface can define Input and Output parameters to declare which data are public for reference by other models. Access points for these parameters will be provided on every sub-process activity using a process defining a Process Interface. Please refer to section Data Mappings in Process Interface Context of chapter Specifying Data Mappings in the in the Modeling Guide for details on defining Input and Output parameters for a Process Interface.
Process definitions in a consumer model can implement Process Interfaces defined on a process definition in a provider model. With this relationship, the process definition of the provider model can be used as an alternative implementation for the process definition of the consumer model at runtime. The implementing process definition to invoke at runtime can be defined either statically as an administrative action or determined from process data, as described in detail in section Dynamic Binding of chapter Multiple Implementations.