Exposing Composite Objects

In some cases, objects that are to be exposed at package interfaces contain other objects, for example ABAP Dictionary structures whose individual fields are typed using data elements.

In order to put an object into a closed interface, its component objects also need to be exposed at the interface, either explicitly or implicitly:

An object that, in order to be usable, requires further objects that are relevant for package checking is referred to as a "composite object" in the following text. Those objects relevant for package checking that are required by a composite object are called "component objects".

When a composite object is exposed at a package interface for the first time,

• all its direct component objects, whether they come from the same package as the composite object or are propagated from other interfaces, need to be exposed explicitly at the same package interface with a link to the composite object, and
• those component objects that do not stem from the same package as the composite object, but from other usable packages' interfaces must have been exposed as propagatable at their original interface.

Component objects that are composite objects themselves

• need to expose their own component objects in the way described above if they are from the same package as the original component object.
• do not need to expose their component objects if they are from other interfaces. Instead, all objects that have been linked to it in its original interface will be implicitly propagated.

To link a component object to the composite object, there will be an appropriate attribute.

Any object in an interface can be linked to another object of the same interface.

However, all objects that are linked to another object and are not actually a component object of that object are implicitly marked as deprecated (see Chapter 3.6) and give syntax warnings at their clients (if those clients do not access the object through other interfaces).

Implicitly propagated component objects can be used by clients of the composite object independently of the composite object.

The link mechanism described above allows for a composite object to change its composition without invalidating its clients, which would have been the case if only actual component objects would have been implicitly propagated. Through the link mechanism, the former component object is still propagated, but causes syntax warnings at the clients because of its deprecation.

Clients shouldn't explicitly refer to implicitly propagated objects whenever possible to avoid such situations from the outset.

A composite object can only be exposed as propagatable if all of its component objects have also been exposed as propagatable. Marking objects as propagatable must be done

• for component objects of the same package in the interface exposing the composite object
• for component objects from other packages in any package interface usable from the composite object's interface.