The Enhancement Framework provides a technology for enhancing source code units without modifying them. The basic mechanism is to offer the so-called enhancement options in development objects. These enhancement options function like "hooks" where you can attach your enhancements. The enhancement options are part of the development objects which can be enhanced. When you assign an enhancement to an enhancement option, at runtime the enhancement is processed when the control flow reaches the option. At runtime the enhancement behaves as if it belongs to the development object it enhances, while the enhancement as a transport object does not belong to the enhanced object.
Enhancements result in far less work during an upgrade compared to modifications. Enhancements are transport objects in their own right that can be stored in packages of their own unlike modifications, which are part of the object they modify. Since during an upgrade all SAP objects are replaced by the new version of these objects, after the upgrade all modifications are gone. This results in customers having to adjust all modifications no matter whether the underlying object has changed or not.
In contrast, customer enhancements as transport objects are never overwritten during an upgrade because they are stored in customer packages in the customer namespace. It may happen that the new version of a development object is no longer compatible with an enhancement, if for example an enhanced object is deleted or a data type used in the enhancement does no longer exist. In these cases, the relevant tools of the Enhancement Framework provide the information which enhancements have to be adjusted and offer tool support to do so.
After an upgrade customers still have to adjust enhancement but these are only the enhancements that are no longer compatible with the new version of the object they enhance, but have to touch every single modification in a system. So enhancements are far more robust during upgrade.
The basic concepts in the Enhancement Framework are:
The enhancement options are divided into two classes:
The figure below shows an overview of enhancement spots and enhancement implementations. The left part shows the relevant terminology for enhancement spots and the relationships between them. It only applies to explicit enhancement options. No enhancement spots are required for implicit enhancement options.
The right part shows the relevant terminology for enhancement implementations and the relationships between them. This applies to enhancement implementations of both explicit and implicit enhancement options.
On the implementation side, all implementation elements, regardless of whether they enhance implicit or explicit enhancement options belong to other containers. The containers on the definition side and those on the implementation side are assigned to each other with a particular cardinality.
All explicit enhancement options and all enhancement implementation elements must be part of containers. This is enforced by the tools of the framework. Enhancement options and their implementations must not be grouped together as they belong to different stages of development.
In the Enhancement Framework there are containers for the enhancement options on the definition side and containers for the implementations on the implementation side:
These can only contain enhancement options or enhancement implementation elements. These containers cannot be nested. One basic container can only hold elements of one type. For example, a simple container cannot hold BAdIs and enhancement options at the same time.
To make room for a nested structure there are composite containers that can hold basic containers and other composite containers. These composite containers can contain basic containers for different enhancement types. Since these composite containers can be nested, you can build a structure that really fulfills the needs of your project. A simple structure looks like this:
When you create an enhancement from scratch, you always have to create the respective containers first. This is similar to creating a method. A method is always part of a class. In the same way, there is no standalone BAdI. Each BAdI is part of an enhancement spot and it is the spot that functions as a transport object. That is why you cannot build a new BAdI and just forget about the framework in the way you might be accustomed to with classic BAdIs. It is also not possible to build the BAdI first and take care of how it fits in the structure of containers later. When building a BAdI, you have to put the BAdI within the relevant structure from the very beginning. But it is only mandatory to have simple containers. Composite enhancements spots and composite enhancement implementations are not enforced by the tools.
Note that after creating an enhancement spot and a simple enhancement implementation, you have only the containers but you still you have to create an enhancement option or the respective implementation.
Enhancements can also be nested. An enhancement implementation can also provide (implicit or explicit) enhancements options. As a consequence, an enhancement spot can manage several enhancement options of an enhancement implementation object.
Due to the fact that an enhancement spot combines enhancement options of one single repository object, it is not possible to mix enhancement options of a main object (for example, an ABAP program) and an enhancement implementation in one single enhancement spot object. Similarly, an enhancement implementation can only contain implementation elements for options provided by one repository object, such as a main object or enhancement implementation object. For more information about nesting enhancements, see ABAP Source Code Enhancements .