Object References
The Integration Repository differentiates between the following:
● Independent repository objects. These objects are visible in the navigation tree and are assigned to a namespace.
● Objects assigned beneath the independent repository objects, for example a connection in an integration scenario.
During the design phase you constantly need to reference existing repository objects, for example from a message mapping to message types. Note the following general restrictions:
● You can only reference independent repository objects (or parts of independent objects, for example, messages in an external definition).
● Whether you can reference or not depends on the software component that the referencing repository object is located in (see below)
You can set object references to objects of an underlying software component version (see: Underlying Software Component Versions).
● Whether referenced objects are copied when you copy an object depends on the type of object reference.
The reason behind these last two restrictions is that you must be able to ensure that all the repository objects of one product are delivered together.
You create each referencing object in the context of a software component version. It is identified by using the software component version, the namespace, and the technical name.
Software component versions are assigned to a product version. It is then possible to reference other objects in the same, or in other software component versions, regardless of the object type. This restriction is reflected in the value help in the Integration Builder.
Object Type |
Possible References |
Integration Scenario |
Since integration scenarios provide an overview of the communication between application components that are each assigned to a product, they can reference any product versions. |
Action |
An action can reference Interfaces of the software component version in which the action was created. |

It is also possible to reference non-independent objects within an integration scenario.
See also: Integration Scenario.
Message interfaces reference (fault) message types, message types reference data types, and data types can in turn reference other data types. You can only reference interface objects in the same software component version or in an underlying software component version. This ensures that objects for a message interface are always in one shipment unit.
Mappings map messages from different application components to each other. Therefore, referencing cannot be as restrictive as for interfaces. The additional restrictions for interface mappings ensure that mapping programs are shipped together with the interface mapping.
Object Type |
Possible References |
Interface Mapping |
● You can reference interfaces from any software component version. ● You can reference mapping programs (message mappings, XSLT or Java mappings) from the same namespace and the same software component version as the interface mapping. |
Message Mapping |
You can reference any message types or the request/response/fault part of an imported interface. It is also possible to reference non-independent objects. See: Message Mappings and References Between Mapping Programs. |
Imported Archives |
You can reference other mapping programs (see: References Between Mapping Programs) but not independent objects. |
Object References for Design Objects

Data types can reference other data types. Interface mappings can also point to programs in imported archives. RFCs and IDocs can reference context objects. These types of references are not shown in the graphic so that it does not become overcrowded.

An exampleof a reference to a subobject is the reference from one message interface to a part of an external definition (see External Definitions).

In imported archives you can reference objects in the program code. These references are triggered dynamically at runtime. However, these are not the same object references as those described here.