Introduction

The basic idea of Enhancement Framework is to make modification-free enhancements of development objects such as
programs, function modules, global classes, and Web Dynpro components.

All these technologies and the new kernel-based BAdI are now integrated in one Framework that has the following features:

o Enhancements of existing development objects on different levels - for example, in an industry solution, in the IT
department of the customer, and finally in a customer's company.
o Better upgrade support
o Switching of enhancements with the Switch Framework
o Support for grouping enhancements and appropriate tool support for documentation.
Enhancement Options For Modification-Free Enhancements
The basic concept is the enhancement option. Think of an enhancement option as a hook where you can attach the
enhancement implementation elements to. If an SAP system provides these hooks, you can add an implementation element
there at later stages of development in other system, without modifying the original SAP code.

This is possible because enhancement implementation elements are in a package of their own and transport objects in their
own right. This way, you avoid all the trouble with modifications that stems from the fact that modifications are, from a
technical point of view, part of the compilation unit they modify.

Explicit and Implicit Enhancement Options

Principally, there are two types of enhancement options:

o The developer of the corresponding development object must insert the options of one kind into the coding so that
enhancements can be done there at a later time. These preconceived enhancement possibilities are called explicit
enhancement options.
o You can perform enhancements on implicit enhancement options without the developer of the appropriate compilation unit
having to do anything. Enhancement options are always available in programs, global classes, function modules, and
includes.

In other words, the implicit enhancement options are for free, provided by the framework, while the explicit ones need to
be inserted explicitly, as the name indicates.

Explicit Enhancement Technologies

There are two types of explicit enhancement options:

o Enhancement points allow you to insert source code plug-ins. These are additional code lines that, if they exist, are
executed there additionally. Explicit enhancement options of the type Enhancement Section behave in the same way - the
only difference being that the source code plug-in replaces the section in the original code.
o Business Add-Ins (BAdIs) are "hooks" for object plug-ins. A BAdI definition comprises an interface with methods. BAdIs are
enhanced by classes that implement the BAdI interface. If you instantiate a BAdI and then call its methods, you can, among
other things, specify which method implementations are to be carried out on the basis of filter values. In other words, a
BAdI method call is a dynamic method call with a specified interface, for which it is not determined until runtime which
method implementations are to take place.
Implicit Enhancement Technologies
Implicit enhancement options are fixed points in compilation units - that is, points that remain intact even if the code is
changed:
o You can always insert source code plug-ins before the first and after the last line of includes, methods, reports, and function
modules.
o You can always add further optional parameters to function modules.
o For global classes, there are different permanent, implicit options for enhancements: You can insert additional attributes or
methods, and you can add optional parameters to existing methods.
Container and their Structure in the Enhancement Framework
The Enhancement Framework enforces some structure on both the enhancement options and the enhancement
implementation elements. An enhancement option has to be part of an enhancement spot, while an enhancement
implementation element has to be part of an (simple) enhancement implementation. Enhancement spots and
implementations serve as containers that can themselves be part of composite enhancement spots and composite
enhancement implementations respectively. Those composite containers can be nested, and, this way, developers can build
a complex structure that mirrors enhancement projects, organizational aspects, topic structure of the content etc.

Links to Further Material

An enhancement option can never live alone. It is always part of an enhancement spot in the way as there is no such thing
as a method that does not belong to a class. For developers, this means that when developing a BAdI they need a spot that
the BAdI is part of. On the one hand this assures that each enhancement option can profit from the benefits of the
Enhancement Framework. On the other hand, this means that a developer cannot just create a BAdI, but has to be familiar
with the container structure of the Enhancement Framework. Working with the Enhancement Framework presupposes good
knowledge of its structure. A more detailed introduction can be found in a weblog series on this framework. This series
focuses on the technology of the Enhancement Framework, while the series on the use cases gives an outline of the way
the Enhancement- and Switch-Framework is used. You should read the first series, if you want to use the Enhancement
Framework, maybe implement or define a BAdI or work in a context with a lot of enhancements. The second series is the
right one for you if you want to get to know the basic ideas of the Enhancement- and Switch-Framework, understand more
about the motivation behind it and what switching is good for, if you have heard about the re-integration of the SAP
Industry Solution into the ERP core or the Enhancement Package Strategy of SAP ERP and do not know what this really
means. If are really interested in the whole topic start with the second series and the go on with the first one. This way, you
work your way outside in.