How to search & Impliment for BADIs

How to search for BAdIs?

Following information has been collected from various authors,Especially
Thomas Weiss
Business Card
Company: SAP AG

Alwin van de Put

Business Card

Company: NL for Business

(NL4B)

Introduction
There are multiple ways of searching for BAdIs. My favorite one is using the
Performance Trace (formerly known as SQL trace) transaction code ST05.
This analyzing technique is based on the fact that all BAdIs are registrated in SAP
database tables. So for each BAdI call these database tables will be accessed. The
BAdI database tables are SXS_INTER, SXC_EXIT, SXC_CLASS and SXC_ATTR. These
tables are always accessed by the views V_EXT_IMP and V_EXT_ACT. So these two
ABAP views (T: SE11) will be the basis for the trace.
The procedure to discover BAdIs by a Performance Trace will be explained by using
the example used below.

Example case
I want to know which BAdIs are called in the transaction "Maintain Business Partners"
transaction code BP.

Pre checks

Check if no other users (T:SM04) or batch jobs (T: SM50) are using the same
user as you do.

Trace Actions
Start the Performance trace
Start transaction ST05 (Performance Analysis)
Set flag field "Buffer trace"
Remark: We need to trace also the buffer calls, because BAdI database tables are
buffered. (especially view V_EXT_IMP and V_EXT_ACT)

Push button "Activate Trace"

Execute the Business transaction

Start transaction BP in a new GUI session

Push button "Organization"

Fill in your test data

Name
Street
House
number
Postal code
City
Country

NL4B
Olympia
1a/1b
1213 NS
Hilversu
m
NL

Push button Save

Performance trace

Go back to the Performance trace session

Push button "Deactivate Trace"

Analyzing the Trace List

Showing the Trace List
Push button "Display Trace"
The popup screen "Set Restrictions for Displaying Trace" appears
Now we are going to filter the trace on Objects: V_EXT_IMP and V_EXT_ACT.

Push button "Multiple selections" button behind field Objects

Fill: V_EXT_IMP and V_EXT_ACT

Push button "Copy (F8)"

Fill Operations: OPEN

Push button Enter

See the result:

Interpreting the Trace list

All the interface class names of view V_EXT_IMP start with IF_EX_. This is the
standard SAP prefix for BAdI class interfaces. The BAdI name is after the IF_EX_.
So the BAdI name of IF_EX_ADDR_LANGU_TO_VERS is ADDR_LANGU_TO_VERS.
In transaction SE18 you can see the BAdI definition.

(If you cant find the BAdI definition name, search in table SXS_INTER.)

Exporting the Trace list

If youd like to keep your analysis, you can export it to Excel file format.
Actually the file will be saved in tab separated file format, but giving the file the
extension .xls it will automatically be opened by Excel.

Start menu: List > Save > Local File

Select Spreadsheet
Push Enter
Fill your preferred file location and file name

Push button "Generate"

Open the file (in Excel)

Delete the columns and rows you dont need and the result looks like:

View V_EXT_IMP and V_EXT_ACT

The reason for filtering the result not only on the view V_EXT_IMP but also on
V_EXT_ACT is necessary, because not all BAdIs are implemented in the same way.
For example:
V_EXT_IMP catches BAdI BPTIME_BP001.
V_EXT_ACT catches BAdI ADDRESS_SEARCH

Tips

Make a full test entry in the Business transaction before starting the
Performance analysis.
So during the Performance trace you wont make mistakes. Making mistakes
during the recording will cause extra trace lines in your trace list.
Try to start with an empty Business transaction screen.
This tip is best explained by an example.
When I restart transaction BP after I have created, displayed or changed a
business partner, the last opened business partner will be displayed
automatically. This means also I will get extra trace lines in my trace list.
To start again with an empty business partner screen you have to close all GUI
sessions and login again.
In the Business transaction you need to fill all required fields so all BAdIs will
be called.

Appendix BP analysis
View
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P
V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_AC
T
V_EXT_AC
T
V_EXT_AC
T

Call
R 20 ADDR_LANGU_TO_VERS

BadI
ADDR_LANGU_TO_VERS

R 30
IF_EX_ADDR_LANGU_TO_VERS
R 20 BUPR_FILTER_RELTYP

ADDR_LANGU_TO_VERS

R 30 IF_EX_BUPR_FILTER_RELTYP

BUPR_FILTER_RELTYP

R 20 BUPR_FILTER_RELTYP

BUPR_FILTER_RELTYP

R 30 IF_EX_BUPR_FILTER_RELTYP

BUPR_FILTER_RELTYP

R 20 BUPR_FILTER_RELSHP

BUPR_FILTER_RELSHP

R 20 BUPA_AUGRP

BUPA_AUGRP

R 30 IF_EX_BUPA_AUGRP

BUPA_AUGRP

R 30 IF_EX_BPTIME_BP001

BPTIME_BP001

R 20 ADDRESS_SUBSCREEN

ADDRESS_SUBSCREEN

R 20 ADDRESS_SEARCH

ADDRESS_SEARCH

R 30
IF_EX_ADDRESS_SUBSCREEN
R 30
IF_EX_ADDRESS_SUBSCREEN
R 30
IF_EX_ADDRESS_SUBSCREEN
R 30
IF_EX_ADDRESS_SUBSCREEN
R 20 ADDRESS_SEARCH

ADDRESS_SUBSCREEN

R 20 ADDRESS_CHECK

ADDRESS_CHECK

R 20 ADDRESS_CHECK

ADDRESS_CHECK

R 20 ADDR_TXJCD_CHECK

ADDR_TXJCD_CHECK

BUPR_FILTER_RELTYP

ADDRESS_SUBSCREEN
ADDRESS_SUBSCREEN
ADDRESS_SUBSCREEN
ADDRESS_SEARCH

V_EXT_AC
T
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P

R 20 ADDRESS_CHECK

ADDRESS_CHECK

R 20 ADDR_PRINTFORM_SHORT
R 30
IF_EX_ADDR_PRINTFORM_SHORT
R 20 BUPA_ROLE_EXPORT

ADDR_PRINTFORM_SHO
RT
ADDR_PRINTFORM_SHO
RT
BUPA_ROLE_EXPORT

R 30 IF_EX_BUPA_ROLE_EXPORT

BUPA_ROLE_EXPORT

R 20 BUPA_BANK_EXPORT

BUPA_BANK_EXPORT

R 30 IF_EX_BUPA_BANK_EXPORT

BUPA_BANK_EXPORT

R 20 BUPA_CCARD_EXPORT

BUPA_CCARD_EXPORT

R 30
IF_EX_BUPA_CCARD_EXPORT
R 20 BUPA_INDSEC_EXPORT

BUPA_CCARD_EXPORT

R 30
IF_EX_BUPA_INDSEC_EXPORT
R 20 BUPA_ADDR_EXPORT

BUPA_INDSEC_EXPORT

R 30 IF_EX_BUPA_ADDR_EXPORT

BUPA_ADDR_EXPORT

R 20 BUPA_GENERAL_EXPORT

BUPA_GENERAL_EXPORT

R 30
IF_EX_BUPA_GENERAL_EXPORT
R 20 BUPA_GENERAL_UPDATE

BUPA_GENERAL_EXPORT

R 110
IF_EX_BUPA_GENERAL_UPDATE
R 20 BUPA_BANK_UPDATE

BUPA_GENERAL_UPDATE

R 110
IF_EX_BUPA_BANK_UPDATE
R 20 BUPA_CARDS_UPDATE

BUPA_BANK_UPDATE

R 30
IF_EX_BUPA_CARDS_UPDATE
R 20 BUPA_ROLES_UPDATE

BUPA_CARDS_UPDATE

R 30 IF_EX_BUPA_ROLES_UPDATE

BUPA_ROLES_UPDATE

BUPA_INDSEC_EXPORT

BUPA_ADDR_EXPORT

BUPA_GENERAL_UPDATE

BUPA_BANK_UPDATE

BUPA_CARDS_UPDATE

BUPA_ROLES_UPDATE

V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T
V_EXT_AC
T
V_EXT_IM
P
V_EXT_IM
P

R 20 BUPA_INDSEC_UPDATE

BUPA_INDSEC_UPDATE

R 30
IF_EX_BUPA_INDSEC_UPDATE
R 20 BUPA_IDENT_UPDATE

BUPA_INDSEC_UPDATE

R 30 IF_EX_BUPA_IDENT_UPDATE

BUPA_IDENT_UPDATE

R 20 ADDRESS_UPDATE

ADDRESS_UPDATE

R 30 IF_EX_ADDRESS_UPDATE

ADDRESS_UPDATE

R 30 IF_EX_ADDRESS_UPDATE

ADDRESS_UPDATE

R 20 BUPA_ADDR_UPDATE

BUPA_ADDR_UPDATE

R 110
IF_EX_BUPA_ADDR_UPDATE
R 20 BUPA_TAX_UPDATE

BUPA_ADDR_UPDATE

R 110 IF_EX_BUPA_TAX_UPDATE

BUPA_TAX_UPDATE

R 20 FSBP_BPID_UPDATE

FSBP_BPID_UPDATE

R 30 IF_EX_FSBP_BPID_UPDATE

FSBP_BPID_UPDATE

R 30 IF_EX_BPTIME_BP001

BPTIME_BP001

R 20 FSBP_BP001_UPDATE

FSBP_BP001_UPDATE

R 30 IF_EX_FSBP_BP001_UPDATE

FSBP_BP001_UPDATE

R 30 IF_EX_BPTIME_BUT021_FS

BPTIME_BUT021_FS

R 20 FSBP_BUT021_UPDATE

FSBP_BUT021_UPDATE

R 30
IF_EX_FSBP_BUT021_UPDATE
R 20 ADDRESS_SEARCH

FSBP_BUT021_UPDATE

R 20 PARTNER_UPDATE

PARTNER_UPDATE

R 30 IF_EX_PARTNER_UPDATE

PARTNER_UPDATE

R 30 IF_EX_PARTNER_UPDATE

PARTNER_UPDATE

BUPA_IDENT_UPDATE

BUPA_TAX_UPDATE

ADDRESS_SEARCH

V_EXT_IM
P
V_EXT_IM
P
V_EXT_AC
T
V_EXT_IM
P
V_EXT_AC
T

R 30 IF_EX_BPTIME_BP001

BPTIME_BP001

R 30 IF_EX_BPTIME_BUT021_FS

BPTIME_BUT021_FS

R 20 GOS_SRV_SELECT

GOS_SRV_SELECT

R 30 IF_EX_GOS_SRV_SELECT

GOS_SRV_SELECT

R 20 ADDRESS_SEARCH

ADDRESS_SEARCH

What the New Enhancement Framework Is For Its

Basic Structure and Elements For Beginners - One
Introduction
Has it ever occurred to you while looking at some complex technology, that you are
lost as to what the technology is actually for? Have you ever had doubts as to
whether the complex technology was created exclusively for the entertainment of the
developers? I confess that this thought crossed my mind when I first faced the huge
complexity of the new Enhancement Framework.
But after a second look I found that nothing could have been further from the truth.
The "complexity" of this framework has a clear function, and the basic structure that
serves to accomplish this function is actually pretty simple. In this , I want to explain
what it is exactly that the new Enhancement Framework, packaged with NetWeaver
7.0, provides the software developer. The Enhancement Framework is about resolving
an old conflict in software development: standard software solutions versus
proprietary solutions. What the Enhancement Framework does is to combine the
advantages of both the standard (easily maintainable) with the proprietary solutions
(more flexible) while avoiding the drawbacks of both standard software (lack of
flexibility) and customized software (upgrade issues).
At the core of this framework is a simple structure consisting of a hook or an
enhancement option and an implementation element you can attach there. You may
already understand that enhancements are preferable to modifications. To take full
advantage of what enhancements over modifications offer, you will need the new
Enhancement Framework. Its purpose: to offer you the ability to enhance the SAP
standard software and to organize these enhancement options and their respective
implementation elements as effectively as possible. Don't expect to learn about all
the technical details of the Enhancement Framework in this particular , though. This ,
will solely cover the basics of the framework. Once you have a clearer concept of the
basics, you will see that the complex structures of the whole framework serve a lot of
different functions and still not feel lost within these structures.

What SAP Does to Bridge the Gap between Standard

Software and Proprietary Solutions
So much for the aim of this ; now let's start to understand the basic gap between
standard software and customized software and how the Enhancement Framework
brings you the best of both worlds.
Standard software can have many advantages over proprietary solutions in terms of
cost, ease and effort. But standard software is much like off-the-rack clothing. It
doesn't always fit perfectly. There will probably be some aspects in which standard
software does not optimally meet the specific requirements of a process as it is
realized in a particular customer company.
On the other hand, proprietary software is usually better suited to meet your specific
requirements. Unfortunately having a non-standard solution also means a lot of
drawbacks. Surely, your company prefers to concentrate on the things it does best,
be it building cars, selling food or whatever other core business and competences it
has. So it isn't really a very attractive option to resolve standard solution limitations
by maintenance and further development of a proprietary IT solution.
Of course, it would be great to have the best of both approaches: to have all the
advantages of a standardized software solution while having the flexibility of a highly
customized solution. One way to accomplish this (at least to a certain extent) is to
have a standard solution that can be adapted to the individual needs of your
company. SAP has gone quite a long way in this direction.
Since SAP exposes and delivers the source code of all ABAP-based solutions, a
customer theoretically could directly modify SAP coding. But, of course, this should
happen only in a controlled way. It would do no good to change the source code in a
totally ungoverned way. For this reason SAP offered so far two different technological
approaches to enable the customer to adapt SAP source code:

Modifications are changes of a SAP development object. These are supported

and tracked by the Modification Assistant.

Enhancements, on the other hand, do not change the SAP development

object, but rather add something to it or enhance it. Up to now, there were so-called
User Exits and Customer Exits where you could put in additional source code. Since
release 4.6 there were also BADIs (Business Add-Ins). A BADI specifies an objectoriented interface that can be implemented by a customer.
The new Enhancement Framework, packaged with NetWeaver 2004s, is intended to
unify these two approaches: the modifications and the classic enhancement
technology. Up to now it integrates all the new enhancement technologies such as
the new BAdI, source code plug-ins, class enhancements, and function group
enhancements. The framework brings with it flexibility so that you have the freedom
to adapt a solution to your own needs while keeping all the advantages of a standard
solution.
Simply stated, the new Enhancement Framework is an evolution of classic
enhancement technologies. The concept of enhancing a development object has
some important advantages over modifying it. SAP has decided to optimize the
enhancement technology in such a way that you can now use enhancements in many
of the situations where you formally needed to modify the source code.

The Limits of Modifications and Why Enhancements Are

More Powerful
Modification has limits almost inherent in this very concept. You face these limits
when upgrading or transporting a modified object. Imagine you have a modified
program in your system and your system is upgraded. What happens to your
modifications? First, your modifications are gone, although you can re-insert them
using the Modification Assistant. But reinsertion means a lot of work for you. You have
to go through your whole program and look at all the modifications to see where they
fit in the upgraded version of your program. Taking into account the fact that you
often have many modified programs spread over one or many solutions,
modifications generate a lot of work after an upgrade. Further limitations surface
when you consider different modifications of the same development object from
parallel or subsequent development systems. All of these problems stem from the
fact that modifications are technically a part of the source code unit they modify. And
one source unit exists only once in a system. After an upgrade, a modified
development object is first substituted by the unmodified one that comes with the
upgrade. In order to keep the modifications, you have to reinstate them in the new
object.
Though the transaction SPAU offers you good support for this task, it is not at all a
trivial task. If relevant parts of a development object have changed, you need expert
knowledge of this object to reinsert the modifications. The administrator who runs the
upgrade is most probably not able to merge the modifications properly. Instead of
using your systems at once after the upgrade you need some developers with expert
knowledge of the relevant solutions to attend to the modifications. So you pay for the
high flexibility modifications offer with a lot of additional work during upgrades.
When you have many modifications you surely want to organize them in some way.
Unfortunately, as they technically belong to the program they enhance, there is no
possibility to group modifications. You cannot even organize them at all in a structure
of their own. Changes to a development object should, of course, be documented.
Modifications can have no documentation attached to them in the system. It is also
not possible to track who modified which parts of a development object.
Obviously all the limits of modifications originate from the fact that they are part of
the object they modify. In contrast to modifications, enhancements are objects in
their own right. If you enhance SAP code these enhancements are in your
namespace, not in that of SAP. They are your objects.
Most of the advantages the Enhancement Framework offers are based on the fact
that enhancements are objects in their own right. You can organize enhancements in
a structure of their own and document them in the system. You can transport them in
units of their own. As far as upgrades and transports are concerned, you can
transport enhancements from different systems into one system and keep all these
enhancements, plus the ones that exist in your target system. No enhancement gets
lost.
This is the basic conceptual advantage that enhancements have over modifications.
A major advantage of the new Enhancement Framework is that it unifies all the new
enhancement technologies in one framework. It is this framework that realizes the
advantages that are possible because enhancements are objects in their own right:
The enhancement framework enables management of different types of
enhancements from different systems. They survive an upgrade without a lot of
additional work. You can organize them in a structure of their own and document all
the enhancements in the system.

Why and When to Change SAP Software

At this point you might ask yourself: Why should I change an SAP software solution at
all? You should change a SAP solution only if you have come to the conclusion that
none of the possibilities of customizing meet your specific requirements. First try out
everything that is possible by means of customizing. If you are still in need of
adjustments of the standard you should consider enhancements as the means of
your choice. As enhancements are objects of their own they are quite robust in an
upgrade. They will cause you far less work than modifications. In addition to this
advantage concerning the work necessary for an upgrade, the new Enhancement
Framework offers you a variety of useful features to manage, organize and document
your enhancements. Just as enhancements have advantages over modifications, not
all enhancement technologies within the new framework are equally suitable if you
want to write highly structured code that causes as little work as possible during
update. But this will be explained in detail in another , in which you learn more about
the details of the Enhancement Framework.
Understood in this way, the new Enhancement Framework isn't an open invitation to
freely enhance your SAP solution in as many ways and means as are possible. The
Enhancement framework can be compared to a powerful tool. Think of it like a highend precision drill which will probably not tempt you to sprinkle holes all over your
walls and furniture. It is merely a comfortable professional means by which you drill a
hole whenever you absolutely need to drill a hole. It is this attitude that you should
have towards the Enhancement Framework. With standard software there may be a
necessity to adapt to your needs. Whenever there is a necessity, use enhancements
within the new Enhancement Framework.

The Basic Idea of the Enhancement Framework: How Do

Modification- Free Enhancements Work?
Before going into more detail, you should now understand the basic idea of the
Enhancement Framework. It provides a modification-free enhancement technology,
enhancing source code units without modifying them.
The basic mechanism is to offer so-called enhancement options in development
objects. These enhancement options function like hooks where you can attach the
enhancements. The hooks are part of the development objects which can be
enhanced. When you assign an enhancement to a hook, at runtime the enhancement
is processed when the control flow reaches the hook. In other words: At runtime the
enhancement behaves as if it belonged to the development object it enhances, while
the enhancement as a transport object does not belong to the enhanced object.
As this probably sounds a bit abstract let us have a look at a specific enhancement,
the source code plug-in. At predefined positions in the source code (for example, in a
report) you have a particular type of enhancement option, that is an enhancement
point. At these points you can insert an enhancement that is called a source code
plug-in. The respective plug-in is processed after the enhancement point is reached
by the control flow. That is, the source code plug-in behaves at runtime as if it were
part of the report while in fact it can belong to another package.
This is what a source-code plug in looks like:

Ignore the details of the source code enhancement for the moment. This particular
example only serves to illustrate the point of how enhancements function: You have
the anchor point or enhancement option, which is an enhancement point in our
particular example. At this enhancement point which is in the orange marked line the
enhancement element 1 (in grey colour) is inserted. The spot flights_display_b and
the enhancement flights_display are units you should not be interested in at this
point.
In some way you can compare the enhancement technology with a closet system
where you can insert different elements at particular positions. You need not drill the
wood in the side walls, but nevertheless you can attach boards and other elements
where there are already hooks or holders at important positions. The boards and
other elements such as drawer or CD-holder look as if they were integral parts of the
closet system while in fact they are only attached to the walls by hooks or holders.
The holder in our analogy corresponds to the enhancement options. The different
elements you can attach there such as boards, drawers, CD- elements etc. behave
like the enhancements. You can not attach a board to the closet system everywhere
you like, but rather only where a holder is prepared. In the same way you cannot
enhance a development object anywhere, but only at predefined positions, which are
called enhancement options.
So irrespective of all further refinements, superimposed containers and their
respective connections, the basic structure of how an enhancement functions is as
simple as could be:

On the one hand, there are hooks or enhancement options where you can
insert enhancement elements. Further on I will also speak of the definition side of the
Enhancement Framework because it is there that the enhancement options are
defined.

On the other hand, there are the enhancement implementation elements that
you can attach to a hook or an enhancement option.

The Complexity of the Enhancement Framework

Despite this simple structure the Enhancement Framework as a whole is pretty
complex: You have different kind of enhancement technologies. At different kind of
enhancement options you can attach different types of enhancement elements. The

enhancement options are divided in two different classes: Implicit enhancement

options which are provided by the framework and exist without any particular
preparation by a developer. Explicit enhancement options have to be inserted
explicitly in the source code. These explicit enhancement options must belong to a
container.
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 these different units form a complex structure despite the fact, that the basic
concept of a single enhancement is so simple, as I have just shown you. But this
structure is indispensable to accomplish all the aims the framework is made for. The
Enhancement Framework is made to organize and manage a huge mass of
enhancement options and implementations of different types. And it is mainly this
aspect that requires the high complexity.
You might ask yourself why you need the containers if you just want to create a
single enhancement option and implement it. The answer is that you hardly ever
need only one enhancement. As good software is usually divided in components, one
change (for example an additional field in a structure) necessitates a lot of other
changes. And in real life programming it is not just you, but your team and many
other teams that create and so have to mangage their enhancements options and
implementations.
The framework not only offers you that structure to organize and manage your
enhancement options and enhancements, but the compliance with the framework is
enforced by the tools. By adhering to the rules you can be sure that you can fully
take advantage of the framework and you will never face a situation in which you
have lots of unorganized enhancements in your system.
In the next , I will explain to you something further about the Enhancement
Framework. I want to show you in which way it is complex and why this level of
complexity is needed. The aim of this , simply was to tell you what the Enhancement
Framework is about, why it was developed and what the basic structure of an
enhancement is like.

The new Enhancement Framework Part 2 - What

Else You Need to Know Before Building an
Enhancement
This , is part two of a series on the new Enhancement Framework. it gives you the
background information you need to understand what you are doing when you define
and implement an enhancement within the new Enhancement Framework. At the end
of this , we should have prepared the ground for building our first enhancement
definition.
You have learnt about the basic structure underlying the Enhancement Framework: It
is an enhancement option and the respective enhancement implementation element.
The option can be compared to a hook, while the enhancement is like a board
attached to the hook. What makes modification-free enhancements possible is the
fact that an enhancement option can be developed in one system, and
implementations in one or many other subsequent systems. Once the control flow

reaches the enhancement option the respective implementation is processed though

the implementations and the enhancement options are different transport objects.
The Enhancement Framework imposes a useful, complex structure of containers on
the different enhancement options and enhancement implementation elements. In
this , I want to introduce the different enhancement options and explain both the
structure of the containers and motivation behind it. It is important to understand
right from the beginning why this structure is very useful for you. Only if you
understand the benefits of this structure, you will be able to take maximal advantage
of it. Moreover the compliance to this structure is enforced by the tools. This means
as soon as you build your first enhancement you have to find your way within this
structure. So I have decided to explain another piece of theory before really showing
you how to build a new BAdI in the next ,.

The Different Enhancement Technologies

Let me start by giving a sketch of the different enhancement technologies that are
part of the Enhancement Framework. There are different kinds of technologies that
provide enhancement options:

Class Enhancements: You can add additional methods, optional parameters,

pre- and post-methods to existing methods.

Function group enhancements: You can enhance the interface of a function

module by additional parameters using function group enhancements.

Source code enhancements: Enhancement points are positions in the source

code where you can attach source code plug-ins that enhance the source code at
these positions. While a source code plug-in at an enhancement point is processed in
addition to the original code, the code of a so-called Enhancement Section is
substituted by the respective source code plug-in.

The BAdI is an object-oriented enhancement option. The BAdI defines an

interface that can be implemented by classes that are transport objects of their own.
The new BAdI is fully integrated into the Enhancement Framework. Within the
Enhancement Framework a BAdI is an enhancement option or an anchor point for an
object plug-in.

Implicit and Explicit Enhancements

There is one major distinction among the enhancement technologies: The implicit
enhancement options are provided by the framework without any effort on the
developer's part. This means: The enhancement definition is for free, while, of
course, the implementation has to be inserted. Implicit enhancements comprise class
enhancements, function group enhancements and predefined enhancement points at
particular predefined positions such as the end of a report, a function module, an
include or a structure and the beginning and the end of a method. If there is a need
for more or other enhancement options than those provided by the framework, you
can use so-called explicit enhancement options: They have to be inserted explicitly
by the developer. There are two types of explicit enhancement options: BAdIs and
explicit enhancement points or sections, where you can insert source code plug-ins.

The Nature of Developing Enhancements or Why to

Group Enhancements
Enhancements are sociable beings. They hardly ever come alone, in particular when
you write your programs according to sound modularization principles. Imagine, you
introduce an additional variable as an enhancement. Probably you will work with this
variable, transport it to all the different procedures that need the new variable for
doing their job and maybe show its value in the user interface. That means, you have
to enhance the interface of all these procedures, call these procedures using the new
variable and also have to enhance the respective interface. These considerations
corroborate the fact that you will probably have a large number of enhancements
once you start using this technology.
If you have a large number of things, you need some organizing. This is a reason why
it is a good idea to group enhancements. Just imagine the mess on your hard disk if
you could not sort the files stored there in folders. The same is true for
enhancements. Moreover, in general you enhance your code for a semantic reason.
That is, you want achieve some aim or other by your enhancements. For example,
you add an additional variable because maybe you want to calculate an additional
tax value. This project necessitates other enhancements. A good way to keep an
overview is to keep all the enhancement options belonging to one project together.
So it would be great to have a technology that enables you to group and organize
your enhancements.
Of course, the reasons for grouping enhancements apply in equal measure to the
definition and the implementation of enhancements. If you remember the structure
of the enhancements you have probably realized that so far we have talked only
about the definition side. The enhancement option is a hook where you can attach an
enhancement. Within the terminology of the enhancement framework the
enhancement that you attach to an enhancement option is called the enhancement
implementation element. So BAdI implementations, source code plug-ins or function
group enhancements are different types of enhancement implementation elements.
As a matter of fact, enhancement options and their implementations should not be
grouped together as they usually belong to different stages of development. Looking
a typical scenario you will easily understand this: The global IT department of a
company develops a program with enhancement options that are implemented later
by the different local subsidiaries. To group these enhancement implementations
together with the enhancement options would undermine the basic idea of the
enhancement framework, namely to make room for code that is processed at runtime
at a particular position of a compilation unit, while it does in fact not belong to this
compilation unit. Furthermore, developing these implementations is another project
than creating the implementation. And the grouping should group enhancements that
belong to different projects separately.

The Structure of the Containers for Enhancements

So it seems we need at least two containers: one for the enhancement options on the
definition side and another one for the implementation side. Within the Enhancement
Framework there are even more container types.
There are simple containers that can only contain enhancement options or
enhancement implementation elements respectively. As a consequence these
containers cannot be nested. Moreover, one basic container can only hold elements
of one type: That is a simple container cannot, for example, hold BAdIs and
enhancement points 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 of different enhancement
types. As 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:

It is important that you have a clear idea of this structure in mind because everything
you do when creating an enhancement happens within this structure. This is due to
the fact that the compliance to the rules is enforced by the framework. This means
for you: Every enhancement element has to be part of an enhancement spot. When
you create an enhancement from scratch you always have first to create the
respective containers. You can compare this to creating a method. There is no such
thing as a method on its own. A method is always part of a class. In the same way
there is no stand-alone BAdI. Every BAdI is part of an enhancement spot and it is the
spot that is the transport object. It is because of this fact that you cannot build a new
BAdI and just forget about the framework in the way you might be accustomed to
from the classic BAdI. It is also not possible to build the BAdI first and take care later
of how it fits in the structure of containers. 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.
I mention this explicitly because, at first, it might be a bit astonishing for you when
you want to create an enhancement point and you first have to create an
enhancement spot. When this happens, you should keep in mind two things:

Experience has shown that structure has to be imposed by tools. Otherwise

when programming it is tempting to forget about the structure because it is time
saving in the beginning. You see the real costs later when you get in trouble trying to
keep an overview of all the different enhancements.

You should be aware of the fact that you have only the containers after having
created an enhancement spot and a simple enhancement implementation. You have
prepared the ground for building enhancements, but that is all. Don't delude yourself
into thinking that you have already an enhancement option or the respective
implementation.
Previously, you have learnt the basic concept of an enhancement. In this , you have
seen the different kinds of enhancement options, you understand the difference
between implicit and explicit enhancement option and you know the structure where

the enhancements fit in. In other words, now you have everything you need at hand
to build a BAdI. We will build a BAdI and see all the pieces of theory at work that you
have become acquainted with by now.

How To Define a New BAdI Within the

Enhancement Framework - Part 3 of the Series
This is part three of the , series on the New Enhancement Framework. You get to
know some more facts as to what a BAdI is and when to use it, and then, at last, we
start with an example that shows you how to build the BAdI with the respective tools
in the ABAP Workbench and how the code to instantiate and call the BAdI is
integrated in the ABAP language.
In the last section, you have learnt about the basic structure of an enhancement, the
different enhancement technologies within the framework and the containers for
enhancement options and enhancement implementation elements. You need to know
them in order not to lose your bearings within the Enhancement Framework when we
now start building a BAdI. If you have a mental map of the entities in the framework,
you will find it really to easy to understand what is going on in the example. So I
would recommend you should take your time to recapitulate theses basics, before
proceeding to the practical part of this document.

Some Basics About the BAdI

Many of you know perhaps the classic BAdI. And there is some good news for them:
The basic things about the BAdI itself have not changed a lot, though there are some
major improvements, such as a gigantic step forward in performance. What will be
totally new for those familiar with the classic BAdI is the way the new BAdI is
embedded in the container-structure of the Enhancement Framework.
For those not acquainted with the classic BAdI, let me spend some words on what a
BAdI is and what it is for:
The BAdI is an object-oriented enhancement option. The BAdI defines an interface
that can be implemented by BAdI-implementations that are transport objects of their
own. The new BAdI is fully integrated into the Enhancement Framework. Within the
Enhancement Framework a BAdI is an enhancement option or an anchor point for an
object plug-in.
A BAdI is to put it this way a controlled explicit enhancement option. It is an explicit
enhancement option, which means: BAdIs are not provided by the framework, but
they have to be defined explicitly by the developer. Why do I call it a controlled
enhancement option. To understand what this means we have to go a bit deeper into
the methodology of enhancing development objects. Why is it done, and who does it?
What is the typical process of enhancing a development object like?

Providing and Implementing Enhancement Options Two Different Roles

In this process there are two different roles: There is the so-called option-provider. He
is the one who builds an enhancement option that is a hook where others can attach
something to. And it is essential to have such a hook: Where there is no hook you
cannot attach anything. This analogy means, that you can only insert an
enhancement implementation where there is an enhancement option. Of course,

there are implicit enhancement options, that are, so to speak, for free and always
available. But there are not implicit BAdIs. If you need a BAdI, somebody has to
define it explicitly. Let us call this role the (enhancement) option provider. In general,
the option provider is identical with the developer of a development object that
should offer an explicit enhancement option. Let us call this object the basic
development object. Typically, the developer of the basic development object could
be somebody working in the SAP core who anticipates that the customer or an
industry solution might want to add some code at a particular point. In this case he
creates both the development object to be enhanced at a later stage and defines an
enhancement option.
An enhancement option that has no implementation does not do a lot when
processed, in fact, it has no effect at all. To make something happen at an
enhancement option, you need to implement it. The developer who implements an
enhancement option, or to put it in the analogy, attaches something to the hook, is
called the implementer. He need not care about the details of an enhancement
option, but just know how he implements it. But, of course, he should have a sound
knowledge of the way enhancement options function. You might compare this to
somebody who uses a service class. He does not need to know the inside of this
class, but just its public methods or maybe even only the respective interface he is
interested in. In the same way, the implementer only needs a limited knowledge as
to how to define an enhancement option.
In the strict sense, many of you are probably only interested in implementing a BAdI.
They suppose that SAP provides the BAdI and calls the respective BAdI methods. All
they want to know is what they have to take heed of when writing the BAdI
implementation. But it is quite useful to know a bit more about defining a BAdI, and
once you have understood what a powerful pattern a BAdI is, you might also be
tempted to write your own BAdI definitions. Moreover, it would be a bit long-winded
to write two different series of ,s, one for the option provider and another one for the
implementer, because there is a large overlap in the background knowledge. For all
these reasons, I have decided to handle both topics in this one series. But still, I treat
building the BAdI in this , and providing an BAdI implementation in the next one. And
you should always keep in mind: Implementing and defining a BAdI are two different
roles. And the same is true for source code enhancements.

The BAdI as a Controlled Enhancement Option

To fully grasp in which way a BAdI is a controlled enhancement option, let us first
have look at source code plug-ins in contrast. This enhancement technology is not
controlled at all. This means: The option provider inserts an enhancement point in the
code thereby giving the possibility to attach a source code plug-in. The implementer
can insert any code whatsoever at this enhancement point. The option provider has
no control at all on the code that is written, because generally it is implemented at a
later stage of development. Moreover the code of the source code plug-in has access
to all the variables that are visible within the modularization unit that is enhanced. So
the option provider cannot prevent the implementer from changing the value of some
variables that should not be touched at all. In fact he cannot bar the implementer
from anything at all.
With BAdIs, things are completely different. The option provider has a firm grip on
what the implementer does insofar as he defines the interface and confines the
implementer to the class that implements the BAdI. In detail this means: A BAdI
defines the methods with their signature, that is, which parameters the respective
method imports, exports, changes or returns. The BAdI implementer has to
implement these methods defined in the BAdI interface. We could put it this way:

With a BAdI the option provider defines what has to be done, but leaves it to the
implementer how he implements the BAdI. Moreover, the BAdI implementer cannot
fiddle with the basic program. It is assured that a BAdI implementation can only
change the parameters handed over to BAdI. The implementation of a method has a
context of its own and the variables of the development object using the BAdI are not
even visible from inside the BAdI implementation.

BAdI Commands in ABAP

There are two ABAP commands for the new BAdI. GET BADI hugo returns a handle to
all active instances of the implementations of the respective BAdI. For example hugo
might refer to five active BAdI implementations.
You call a BAdI method with the command: CALL BADI hugo->method. If a method of
the BAdI is called, all active implementations are selected. So this amounts to a loop
with the different method calls in it.

When to Use a BAdI?

As a potential option provider you should use a BAdI if you already know that a
particular procedure should be executed at a particular position in your program, but
you want leave it to somebody else to specify the specific content of that procedure.
This is typically the case if the details of the procedure vary among different potential
implementers or are so specific that the developer of basic development object does
not know them or want to give the possibility to add different implementations at a
later stage.
So the developer of the basic development object just writes something like saying:
subtract your fees and return the result. He does not care about what the different
fees are and if there is a complex formula, percentages calculation or just a simple
subtraction. To do this the option provider writes a BAdI which contains a method:
subtract_fees CHANGING costs.
This way, a BAdI can be used quite well to understand what enhancements are for
from a semantic point of view. This is because the way BAdIs work is pretty much like
our common sense concept of enhancing something. Usually we do not think: Just
add any enhancement, but add something as a means to a particular end. You can
decide yourself how you want to accomplish the end, but the end is defined. This is
one analogy to explain a BAdI.
You might compare the usage of BAdIs also to the process when some company
delivers the same car body to different manufactures of multi-purpose vehicles. They
all build their specific vehicle on the same car body. The producer of the car body
leaves the technical details to the different manufacturer, but of course it prescribes
that the car suspension has to be build in here and the engine there. In this way, the
engine has to be in a particular place and has to have particular properties, but all
the other details are up to the manufacturer of the multipurpose vehicle.
This process can be compared to the process of multilevel software development I
have already sketched: The program logic of a SAP core program needs some value
at a certain point, but the developer of this program does not know how to calculate
this value. So he inserts a method call that should provide this value, but leaves the
actual implementation, that is the calculation to the developer of the next
development level. In terms of this framework, the developer inserts an
enhancement option that is a BAdI, providing the respective method in its interface,
and also a call of a BAdI method.

Multiple and Single Use BAdIs

Concerning the programming model, there are two different BAdI types: Single- and
multiple use BAdIs. They have a completely different semantics.
The use case with the calculation I have sketched above is a typical example of a
single use BAdI. The basic program needs the result of a calculation. You leave the
implementation details of the calculation to subsequent levels of development, for
example the developers for the particular countries. The business logic requires a
result of the calculation, and it must be exactly one result. The next steps in the
program need this result, so you need at least one BAdI implementation. And there is
no way to process many return values, so you need exactly one result. If you have a
single use BAdI, the system takes care that there is exactly one active
implementation. This way the call of the method of a single use BAdI functions like a
method call.
Multiple use BAdIs are quite different in this respect. Such a BAdI is suitable for
activities, that might be done or not and that might even be consecutively done in
different ways in different implementations when a program is executed. Imagine you
build a BAdI additional_output that might convert data for different additional output
devices such as a Blackberry, handy, etc Many different active implementations
can coexist in the program simultaneously, but there might also be no active
implementation. So the call of a method of a multiple use BAdI is in a way like
sending a message: You do not know and do not care how many services react to the
message. It corresponds to a publish and subscribe mechanism.

Building Our First BAdI

The Use Case

And now let us have a look at an example in detail. Imagine that the developer of the
basic program needs the VAT of different book entries. These entries should be
passed to a method that calculates and returns the VAT. As this developer does not
know what the VAT in a specific country is, he defines a BAdI badi_vat with the
method get_vat. This method should return the VAT for a particular value that is
passed to the method get_vat.

Building the Enhancement Spot

The first thing you need when creating a BAdI is a container for the BAdI. Up to now
we have no container, so we have to create a (simple) enhancement spot. This is the
container in which we develop our BAdI.
We go to the ABAP workbench and navigate there to our local objects. We select:
Create->Enhancement->Enhancement-Spot
from the context menu of the local objects folder.
This is what the dialog window looks like:

We enter a name for the enhancement spot and some short text. To name a
composite enhancement spot is voluntary. We are content with our enhancement
spot and need no higher level container for the example. In real life programming,
you probably should take advantage of the structure the composite enhancement
spots offer you and always work with these complex containers.
The BAdI Itself
Next we create a BAdI within the new enhancement spot. We select the CREATE icon
on the left:

In the dialog window that appears we enter the BAdI name z_badi_calc_vat plus a
short description and confirm. Now we have a BAdI in the list of our enhancement
spot. We deselect the property "multiple use", because for our calculation we need a
single use BAdI:

The BAdI Interface

More important is the fact that up now we do not have much of BAdI. We need an
interface. In fact, it is the interface where you define the methods that determine
what use you can make of your BAdI. Understood this way, the interface makes up
the identity of a BAdI to a large extent. After clicking the arrow in front of the BAdI
name and after doubleclicking Interface in the tree below we can input the name of
the interface. You can either choose the name of an interface that already exists or
create a new one. There are no restrictions on the name of the interface enforced by
the framework. But, of course, you should conform to the normal rules for choosing
speaking names in a systematic manner.

Selecting the Change icon leads you to the class builder, where you can create the
methods you need for your BAdI in the same way that you are used to if you are
familiar with the class builder. We just type in the name of the method get_vat and
enter the parameters we need.
A BAdI interface has to implement the interface if_badi_interface. But if we create a
BAdI interface in the way just shown this marker interface is already integrated in the
BAdI interface. Probably you know how to work with the class builder, but still I have
inserted the following two screenshots to show you: Defining a BAdI interface is just
normal ABAP Objects programming and as simple as could be for anyone familiar
with the Class Builder. We define one BAdI method.

Next we determine the parameters of the method.

We save and activate the interface and the spot.

So let us now take a breath and consider what we have created so far:

We have created an enhancement spot and a BAdI with an interface. The interface
has one method so far.
Of course, just building a BAdI does not suffice. It does not do anything. You need a
BAdI instance, and this instance must be called somewhere in the code. This is the
definition part of a BAdI. But as a BAdI only defines an interface, you need a class
that implements this interface. Remember: A BAdI definition is the option to insert an
object plug-in that does a job at runtime. You still need an object that is plugged in to
get something done.

BAdI Commands in ABAP

So it is time to write some ABAP code to use the BAdI. We need a variable that can
refer to the BAdI and some variables which are given as actual parameters to the
BAdI method. Next we create a handle for that BAdI and call the BAdI method
get_vat. The respective commands are GET BADI and CALL BADI.

If we run the program it dumps. Considering what I have told you before about the
single use BAdI, this is no wonder. It is mandatory, that there is exactly one active
implementation for a single use BAdI. Our BAdI is a single use BAdI. One way to
handle this is to catch the respective exception cx_badi_not_implemented.

Using and Creating a Fallback Class

The other way is the better solution, namely to use a fallback class. A fallback class
for a BAdI is used if there is no active BAdI implementation. This means: The GET
BADI command returns a handle to an instance of the fallback class and the
respective CALL BADI calls the methods of the fallback class instance. As soon as
there is an active BAdI implementation, the fallback class is not used any longer at
runtime. So using a fallback class serves two functions at once:

The program runs with a single use BAdI without raising an exception.

It is guaranteed that the fallback class is not used any more as soon as a BAdI
implementation is supplied. So a fallback class is only selected conditionally. This is
important, because the BAdI provider does usually not know the details of some
process. This is why a BAdI is used.
We select the checkbox the bottom with the text: Call fallback class if no
implementation is executed and insert a name for the class.

Clicking the change icon leads us to the class builder. Again the tools do a great job
for you: The respective method of the BAdI interface is already defined. We only have
to implement it:

I skip this, because it is no news to anybody familiar with the Class Builder. Of course,
we have to save and activate the class. Then we navigate back to the enhancement
spot and activate it.
Running the program again leads to result:
percentage: 20 VAT: 10.
And this is the end of this ,. Now, you know how to build an enhancement spot and a
BAdI including the BAdI interface and a fallback class plus the ABAP commands to use
the new BAdI. In the next , you learn how to create a BAdI implementation inside the
respective container, that is the (simple) enhancement implementation and how to
select among the different BAdI implementations using the addition FILTER to the GET
BADI command.

How to implement a BAdI And How to Use a Filter Part 4 of the Series on the New Enhancement
Framework

In the last , we defined a BAdI, provided a fallback class, instantiated the BAdI and
called a BAdI method. Of course, we also provided an enhancement spot, because
our BAdI, as every BAdI, needs a container to live in.
As you have learned, the fallback class is chosen in case no BAdI implementation is
available. As we have not created a BAdI implementation so far, the method
implementation of the fallback class was used in our example code. To change this,
we create a BAdI implementation in this ,. As soon as there is a suitable BAdI
implementation the methods of the fallback class are not used any longer.
First let us have a short look at the entities we have so far: There is the enhancement
spot z_es_calc_tax in which the BAdI z_badi_calc_vat lives. The BAdI interface defines
an important part of the BAdI identity, insofar it defines the BAdI methods that can be
used. Our interface z_if_calc_vat has one method get_vat( ).

The definition and the implementation of BAdIs are similar in one respect: Just as you
need a container that is an enhancement spot for a BAdI, you cannot build a BAdI
implementation unless you have the relevant container first. The relevant container
type for BAdI implementations is called (simple) enhancement implementation. A
simple enhancement implementation can keep many different BAdI implementations,
but with one restriction:
A simple enhancement implementation is uniquely assigned to an enhancement spot.
That means: A (simple) enhancement implementation can keep only BAdI
implementations of BAdIs that belong to the spot the simple enhancement
implementation is assigned to. This has the consequence: An (simple) enhancement
implementation cannot keep BAdI implementations that implement BAdIs belonging
to different spots.
This being so, we have first to create a container that is uniquely assigned to the
enhancement spot our BAdI belongs to. Despite the fact that we have to do
something pretty complex, the respective tool in the SE80 has paved a smooth way
to do this. All you have to do is to press one button. This button is marked with an
orange frame in the screenshot below:

We get to the dialog window, where we can create a (simple) enhancement

implementation:

The next dialog window opens:

What are we asked to type in here? We have created so far a container for BAdI
implementations, that is a (simple) enhancement implementation. This container is
uniquely assigned to our enhancement spot. Once this connection is established, we
can create a BAdI implementation for the BAdI within the enhancement spot. As we
have defined only one BAdI within the enhancement spot, we have no choice. If we
had more BAdIs in our enhancement spot, this would be the point where to select
which BAdI we want to implement. As matters stand, we type in z_bdi_calc_vat_us as
the name of the BAdI implementation, confirm and save the enhancement spot in the
next window. There we are: This is (simple) enhancement implementation that
contains the BAdI implementation z_bdi_calc_vat_us:

Obviously, the appearance of a (simple) enhancement implementation in the tool is

pretty much like the one of an enhancement spot: Under the tab Enh.
Implementation Elements there is a tree with the BAdI implementation(s) contained
on the right-hand side. On the left, you see the properties of the marked BAdI
implementation.
Note: Select the property "Implementation is active" under the header "runtime
behavior". If you do this the text below changes to: "Implementation is called". That
is intended to help you understand what the selection you have just made is for.
Farther below, there is a list that shows the properties of the BAdI definition our BAdI
implementation is assigned to.
To better understand the structure in which our objects are imbedded, let us have a
look at this sketch:

At the top, there is the definition part: In principle, such a spot can contain many
different BAdI definitions. Our enhancement spot contains only one BAdI definition.
We have created a container for the BAdI implementations. This (simple)
enhancement implementation is uniquely assigned to the enhancement spot, but one
enhancement spot can have many enhancement implementations assigned to it. We
have a one-to-many relationship between the enhancement spot and the
enhancement implementation. With this relationship established, we have assigned a
BAdI implementation to our BAdI. Again, this is a one-to-many relationship: A BAdI
definition can have many BAdI implementations, but a BAdI implementation uniquely
belongs to a BAdI.
Only if the relationship between the containers that is the enhancement spot and the
enhancement implementation is established, you can assign a BAdI implementation
to a BAdI definition. I have tried to show this in the picture by the large orange pipe
that contains the small grey pipe.
You should keep in mind: When implementing a BAdI, you have first to establish a
connection between the relevant containers. Based on this connection you can go on
and implement the BAdI. This principle applies to source code plug-ins in an
analogous fashion.
Now that we have a BAdI implementation, we need an implementing class. We click
the triangle in front of the name of the BAdI implementation in the tree and next
double-click Implementing Class:

It works the same way as with the creation of the fallback class in the last ,. As we do
not want to reuse an existing class we enter the name z_cl_calc_vat_us and select the
Change icon. Again, we get to the Class Builder where the relevant interface methods
are already defined. In our case it is only the method: get_vat( ).
We implement it:

We save and activate the class. If we have not activated the (simple) enhancement
implementation before, we have to activate it now. Now, we return to the program:

We run the program, and what do we get? The result is a percentage of four percent.
And this is because the fallback class is not selected, if we have an active BAdI
implementation.
As a next step, we create another BAdI implementation, this time with the VAT rate of
Great Britain. To make our example more like real world programming, we create
another (simple) enhancement implementation, that is another container. This is
because implementing the taxes for different countries most probably belongs to
different projects and because the structure of the (simple) enhancement
implementations should mirror the project structure.
We navigate to our enhancement spot and use the same button as we have done
above. We name the simple enhancement implementation z_ei_bad_calc_gb, the BAdI
implementation z_bdi_calc_vat_gb, and the implementing class Z_BDI_CALC_VAT_GB.
The implementation of the method get_vat is the same as for the USA except for the
VAT rate, which is 16,5% now. After saving and activating the enhancement
implementation and the class we return to the program and run it again.

This time we get a short dump with the exception cx_badi_multiply_implemented.

Remember: We have defined our BAdI as single use by deselecting the property
"Multiple Use". When instantiating a single use BAdI you have to make sure that there
exists only one active non-default implementation. Otherwise you get the respective
exceptions at runtime. These exceptions can be caught, but this is not our strategy
here. We want to avoid the exceptional situation right away.
Obviously, it would also make no sense, because we need exactly one result for our
calculation and could not make any use of if the two BAdI implementations would be
called one after another. This was just why we defined our BAdI as single use. What
we need is a way to select among different BAdI implementations. And this is where
the BAdI filter enters the game.
What we need is to change the BAdI definition, that is one we need to add a filter. You
can define one or many filters for a BAdI. We will be modest and be content with one
filter. Let us just define the filter in the BAdI definition, determine filter values for the
respective BAdI implementation and use the filter in the instantiation of the BAdI
handle. I hope in hindsight, you will understand what we have done and why.
You should keep in mind that what we do now when modifying our example does not
take into account the differentiation between the BAdI provider and the implementer.
In real life it is the BAdI provider who defines a BAdI with a filter or adds a filter to an
existing BAdI. It is also part of this role to use the filter condition in order to select the
respective BAdI implementation in the ABAP code. It is the implementer who
determines the filter value(s) or an interval for one or many BAdI implementations. In
the example we do all this ourselves for the sake of the example.
We start by adding a filter to our BAdI (role of BAdI provider) and to this we navigate
to our enhancement spot and stay in the tab "Enh. Spot Element Definition" that
shows a list of all the enhancement elements the spot. We switch to the change
mode, mark our BAdI in the list, and click the Filter icon above. A dialog box opens
and we fill out the relevant fields as shown below:

We confirm and get to the next screen. Obviously, the filter is now visible as a
property below the BAdI. After activating the enhancement spot, we double click
Implementation and navigate to the respective BAdI implementation by doubleclicking the respective row in the table of BAdI implementations.

We switch to the change mode, click the triangle in front of the BAdI implementation
in the tree and then double-click the filter icon below. In the next window we select
the Combination icon, select "Country" as filter and confirm:

Double-clicking the row below "Combination 1" leads us to the next window:

As I have told you above, adding or changing a filter value of a BAdI implementation
is part of the implementer's role.
After we have activated the (simple) enhancement implementation, we navigate back
to the spot. Apparently, the other implementation, that is the one for USA needs also
the respective filter value. So we go to the respective (simple) enhancement
implementation and change the BAdI implementation in an analogous manner. The
respective filter value for this country is 'US'. I skip the description of how to do this,
because what we do is identical to what we have done before when creating the filter
value for the BAdI implementation z_bdi_calc_vat_gb. We must take care that we do
not forget to activate the (simple) enhancement implementations and to select the
property "Implementation is active" for every BAdI implementation.
Now it is time to return to our program and adapt it to the modified BAdI (this is also
the task of the BAdI provider). Running the syntax check shows you that you need to
have a filter parameter in the GET BADI command if the BAdI you try to instantiate is

defined with a filter. The requisite addition to the GET BADI command is FILTERS. It is
after this keyword that you insert the name of the BAdI filter and a value the filter is
compared to. Of course, we also have to take care that an appropriate value can be
passed to the GET BADI routine:

If you pass "GB" to the parameter ctry, you will get a VAT rate of 16,5 percent. If the
value of the parameter ctry is "US", the VAT rate will be 4 percent. When the
parameter ctry has any other value, we will still get a calculated value for the data
field 'percent'. And this is because we have defined a fallback class for our BAdI. The
fallback class is not only selected if no BAdI implementation is available, but also if
none of the existing BAdI implementations meets the filter conditions in the GET BADI
command. Accordingly, we get a VAT rate of 20 percent. And this was the VAT rate we
have implemented in the method get_vat in the fallback class.
And this is the end of this ,. You have now learned how to create a BAdI
implementation for a given BAdI. You know that a (simple) enhancement
implementation is a container for BAdIs and moreover how and also why to assign it
to a (simple) enhancement spot. That is you have understood the way the different
elements of the enhancement framework interact when implementing a BAdI. And, in
the second part; you have learned how to create a filter for a BAdI, how to determine
filter values for BAdI implementations and what the appropriate syntax for calling a
BAdI with a filter is like.

Source Code Enhancements - Part 5 of the Series

on the New Enhancement Framework

In this , I want to address several topics that center more or less around creating
source code enhancements. At the beginning, I focus on the different use cases in
which developers outside of SAP create an enhancement option. In a next step I
narrow the scope and ask the question which type of enhancement option you should
prefer as an option provider and in which cases a source code enhancement should
be your first choice. As I have already stated , in general SAP recommends the use of
BAdIs. Still the BAdI is no all-purpose weapon. There are situations in which it is
better to use source-code enhancements instead. After sketching these situations I
will show you how to create an enhancement point, how to implement an
enhancement point and how to overwrite an implementation created in another
system without modifications.

Why to Define an Enhancement Option as a Developer

Outside of SAP - the Different Use-Cases
Let us start by spending some thoughts as to when and why you might want to
define an enhancement option as a non-SAP developer. Of course, it should be clear
at the outset that in most cases you will implement enhancement options if you are a
non-SAP developer. But as you will learn soon, there is one group of non-SAP
developers that will take great advantage of defining enhancement options
themselves. These are the ones developing solutions that should be enhanced by
somebody else later. I will treat this group in the first use case. In contrast, the
second use case is not confined to a particular group, but to any developer who is
interested in keeping an unavoidable modification as small as possible.
1a.Imagine, you are an ISV, develop your product in ABAP and want to enable your
customers to enhance your product at certain points. In this case, you provide
enhancement options where you think they are useful.
1b. The same applies to the IT department of a multinational company. It develops
some solution in ABAP and wants to make room for changes or enhancements that
the different local subsidiaries can implement. Again using enhancement options are
the suitable way to do this. Both cases are semantically and technically pretty the
same, so that I decided to subsume them under the same use case.
2. The second use case is a bit more complex to describe: You are a SAP customer
and need some enhancement of a SAP solution. Let us assume that the implicit
enhancement options available in the relevant development objects do not suffice to
accomplish this and that there are also no suitable explicit enhancement options. So
you are left with the possibility to modify the relevant SAP development objects. But
still there is room for using enhancement options. To reduce the effort necessary for
adapting your modifications after an upgrade it is a good strategy to keep your
modifications small. To minimize the size of your modification you create
enhancement options within the modifications you insert. Then you add all further
code to the implementation of these enhancement options. This way the
modifications only contain these enhancement options and all the other additions are
part of your namespace. In this use case modifications and enhancement cooperate
in an interesting way.

The Limits of the Enhancement Framework

The very existence of this use case also helps to provide an answer to a question
frequently asked: Namely, whether the new enhancement framework suffices to
avoid all modifications. A realistic answer is: A clever use of enhancements enables
you to do without modifications in many cases. On the one hand, there are explicit
enhancement options provided by the developers of the respective solution. On the
other hand, there are a huge number of implicit enhancement options. There are
implicit enhancement points at the end of a function module, of a structure definition,
of a report and of an include, in each defining section of a local class, and at the end
of the implementation of a local class. Moreover, you can enhance a function module
by additional parameter. A global class also offers a variety of implicit enhancement
options: You can add methods, attributes, and interfaces to the class. Each method
can be enhanced by a pre-exit, a post-exit and an overwrite-exit that substitutes the
original implementation of the method.

Looking at the huge number of different implicit enhancement options it is probably

possible to achieve your aim without modification very often. But still this is not
always possible. Let us put it this way: What the new enhancement framework offers
is intended to support modification-free enhancements to as large an extent as
possible. But still, there is no guarantee that this is always possible. In case the
enhancement options available for you do not suffice you should decide to create an
enhancement option as a modification.

When to Use Source Code Enhancements

So much for the question when to create an enhancement option and the little
excursus on the limits of the enhancement technology. The next question is what
enhancement option you should prefer. In general, SAP recommends using a BAdI
whenever it is possible. This is due to the reasons already named: A BAdI has a well
defined interface and because of that the enhancement option provider has a firm
control of the implementation. Moreover, the implementations can only access the
data passed to them by the parameters of the respective methods. And again, it is
you the BAdI provider, who determines which data should be passed to a BAdI
method.
This great advantage of the BAdI is also a drawback in some situations. Thinking
about this leads the way to understanding under which conditions a BAdI is not the
suitable solution if you want to provide an enhancement option. This is, for example,
a situation, in which you do not know which data the potential implementer of your
enhancement options needs or provides. To put this point another way, if you do not
know the interface, you cannot and, of course, should not use a BAdI. Given this
condition, you should use the technology of enhancing the source code.
This enhancement technology comes in two flavors:
- At Enhancement points an implementer can add some lines of code which are
executed at runtime when the line with the statement ENHANCEMENT POINT is
reached. Then the control flows proceeds to the next line after the enhancement
point. There can be none, one or many active source code plug-ins (as these
enhancement implementation elements are called) assigned to an enhancement
point. All these source code plug-ins are executed in addition to the code that is
enhanced.
- An enhancement point cannot be part of another statement. This means a
statement cannot be enhanced. And that fact sets a limit to the power of
enhancement points. For example, there is no way to add a new condition to the
where clause of a select statement by using an enhancement point. This is one
prominent use case for an enhancement section. Imagine you have a select
statement:
SELECT a b c FROM my_table INTO wa.
and want to leave it to the implementer to add a where-clause or select other fields
from this table. So you mark the select-statement as an enhancement section, which
looks like this:

Don't worry here about the details of the syntax. At this stage, you should just note
that the code marked as an enhancement section is substituted by a source code
plug-in as soon as one is provided. Obviously it is required by the logic of
enhancement sections that one enhancement section can have exactly one active
implementation.
Let me just restate the main point about the use of source code enhancements: This
enhancement technology is suitable if you want to provide an enhancement option
and cannot or do not want to specify an interface.

Defining an Enhancement Point

Now that you know why and when to use source code enhancements you are
probably eager to know just how you create an enhancement point and how you
implement it. Before going into any details let me just remind you of the basic
structure of the enhancement framework that applies to source code enhancements
as well: When you define an enhancement point, this point has to be part of an
enhancement spot. This means if you cannot use an existing enhancement spot you
have to create one when creating an enhancement point. The same applies in an
analogous way to source-code plug-ins: A source code plug-in is uniquely assigned to
an (simple) enhancement implementation. But this structure should be pretty familiar
to anybody in which I show how to implement a BAdI. (Simple) enhancement
implementations serve as container for enhancement implementation elements.
So enough with the background structure. Let us go into the details and create an
enhancement point. We go to the source code that we want to enhance, open the
respective unit in change mode, put the cursor on a line and choose the right mouse
menu:

In the next dialogue window we enter the name of the enhancement point and the
name of the spot plus the name of the relevant package as shown below.

As a result an enhancement point is inserted into the code before the line where the
cursor was:

This is what an enhancement point looks like. An enhancement point has a name that
is unique within the source code unit it belongs to and is uniquely assigned to an
enhancement spot.

Implementing an Enhancement Point

Now we switch our role. For the sake of simplicity we provide here both the definition
and the implementation of our enhancement point. Of course, you know by now that
the provider of an enhancement option and the implementer are two different roles.
To implement an existing enhancement point is not possible in the change mode for
an obvious reason. Of course not. The one who implements an enhancement option
does not want do modify the program. That is what the whole business of the
enhancement framework is about. So we switch to the enhancement mode by
selecting the relevant button:

There we are. We choose the right mouse menu on the line where the enhancement
point is and select Create in the submenu:

We get to this dialog window:

As I have told you have first to provide a container for the source plug-in, that is an
enhancement implementation. Let us call our enhancement implementation
ei_my_implementation. Of course you should not forget the explanatory text. It is
possible to create a composite enhancement implementation by using the Create
icon. But it is not necessary, and so we do without this meta-container here. And
there we are:

Before inserting some code just note that the source code plug-in itself is not named.
It is by assigning an enhancement implementation to an enhancement point that a
source code plug-in comes into being. We just enter the code: WRITE
'implementation'.
After the code for the source code plug-in is supplied we should activate it by
selecting the respective button:

Source Code Enhancements - The Structure of the

Entities
For those who do not feel totally familiar with the structure of the entities, we have
created so far let me just sketch the structure of entities we are concerned with:

Our enhancement point uniquely belongs to the (simple) enhancement spot

es_my_spot. This spot is assigned to the (simple) enhancement implementation
ei_my_implementation. (Simple) enhancement spots containing points or sections
and the relevant (simple) enhancement implementations are in an n to m
relationship. That means: Points belonging to one spot can be implemented by source
code plug-ins belonging to different (simple) enhancement implementations. And
source code plug-ins belonging to one (simple) enhancement implementation can
implement points belonging to different (simple) enhancement spot. (This does of
course not mean that one source code plug-in can implement different points) It is
the compilation unit that holds the respective (simple) enhancement spots and

(simple) enhancement implementations together: Spots containing points in one

report cannot contain points in other programming units. The same is true for the
enhancement implementations in an analogous way. An enhancement
implementation cannot be assigned to points that belong to different programming
units.
Source code plug-ins are unnamed. You create a source code plug-in by assigning a
(simple) enhancement implementation to an enhancement point. In turn, this means
that a (simple) enhancement implementation can only be assigned once to an
enhancement point. Otherwise the identity of a source-code plug-in would be blurred.
So much for the details of the structure of the entities involved when creating and
implementing an enhancement point. By the way, the structure of the entities and
the whole process of defining and implementing is pretty the same for an
enhancement section. There is one notable difference: When implementing an
enhancement section you have to make sure that there is not more than one active
source code plug-in.

Replacing Source Code Plug-Ins

Now let us consider in brief how to handle a use case that is a bit more complex.
Suppose you are a customer and want to change a source code plug-in created by a
SAP industry solution. The background is that this code is specific to the industry
solution and does not fit your needs totally though your company belongs to the
respective industry. Changing the source code plug-in in the SAP namespace would,
of course, mean modifying it. And this is no attractive move and should be avoided as
much as possible. There is a better solution for this problem than modifying the
source code plug-in in the SAP namespace.
The Enhancement Framework provides a nice feature to handle this situation. It
enables you to overwrite an existing source code plug-in by using or creating a
(simple) enhancement implementation that is an object of yours. This means you can
substitute a source code plug-in without modifying the plug-in or the code unit it is
plugged in. And this is how it works:
Position the cursor on the enhancement you want to replace, choose the right mouse
button and select: Enhancement Implementation->Replace.
In the next dialogue window we have to enter the name of a new (simple)
enhancement implementation. For reasons already given, it has to be a new one and
has to be different from the enhancement implementation to which the source code
plug-in to be substituted belongs:

What we do now is pretty the same procedure as when we originally implemented

our enhancement point. We enter some code and activate it by selecting the button
Activate Enhancements. This is what our enhancement point looks like now:

By using the respective entries in the context menu you can also change and delete
source code plug-ins. But you should keep in mind: You should not touch source code
plug-ins created by SAP as this would mean to modify a SAP object, in this case, the
respective (simple) enhancement implementation. If a source code plug-in created by
SAP does not meet your requirements, you should replace it in the way just shown in
the last use case. So you should change and delete only the source code plug-ins you
have created yourself. Instead of deleting an source code plug-in created by SAP you
should replace it by an empty source code plug-in. Again, this is the way to avoid a
modification.

Summary
By now you should have learned a lot of different things about the source code
enhancement technology. Let us first consider the definition part or the role of the
enhancement option provider. You know the use cases for this enhancement
technology: As an option provider source code enhancements are the means of
choice if you do not know the interface of the enhancements to be made. You can
also create an enhancement point as a modification and add the rest of the code you
need to a source code plug-in assigned to this enhancement point. This helps keeping
unavoidable modifications small. Apart from these use cases, the enhancement
technology recommended by SAP, in general, is to define a BAdI.
As to the implementing part, you know:

how to implement an enhancement point,

how to change or delete an source code plug-in of your own,

how to replace an existing source code plug-in in the SAP namespace.