Badi Its Basic Structure and Elements for Beginners (1)

Blogs

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 weblog I want

to explain what it is exactly that the new Enhancement Framework, packaged with NetWeaver 2004s , 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 weblog, though. This weblog 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 weblog; 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 object-oriented interface that can be implemented by a customer.

The new Enhancement Framework, packaged with NetWeaver 2004s, is intended to unify these two approaches: the

What the New Enhancement Framework Is For

– Its Basic Structure and Elements For

Beginners Thomas Weiss

Business Card Company: SAP AG

Posted on Jan. 24, 2006 02:02 AM in ABAP, Beginner

Subscribe

Print

Permalink

of 5SAP Network Blog: What the New Enhancement Framework Is For – Its Basic Struct...

30/7/07https://weblogs.sdn.sap.com/pub/wlg/3056

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 weblog 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

high-end 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 weblog 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 weblog 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.

Thomas Weiss works in the SAP NetWeaver Product Management and has built elearning tutorials on ABAP topics.

Add to: del.icio.us | Digg | Reddit

Comment on this weblog

� great architecture

2006-01-26 06:43:12 Bertrand LAFOUGERE Business Card [Reply]

I'm pretty impress by that new "enhancement framework" and as facing customer specifics needs every day It's clearly

the SAP respons I was waiting.

Today there is 2 sides concerning the implementation of specifics needs (to extend SAP standards).

The "holy" side "copy the standard" (majority of people I think) and the other side "modify the standard".

Real implementation show most of the time that evolution, maintenability and upgrade are less "costly" with modifying

the standard than copying it. However modifying a standard make it loose it's SAP support (or an urban legend said

so ...).

One of the best practise we came too was modifying the standard using customer specific BADI (see "Sergei Korolev"

weblog "The time for me to have a BADi of my own" => https://www.sdn.sap.com/irj/sdn/weblogs?

blog=/pub/wlg/1370 ).

I see that SAP "technicaly speaking" go in that direction and even more sot it's awesome. I would also note that it's a

major victory of the minority side "modify the standard" against the "copy the standard" side :D.

� Thanks

2006-01-24 11:50:18 Peter Inotai Business Card [Reply]

Hi Thomas,

Showing messages 1 through 5 of 5.

Titles Only Main Topics Oldest First



Thanks for this great weblog, I'm looking forward to the next one about this topic.

Regards,

Peter

� Nice One!

2006-01-24 05:58:07 Abdul Hakim Business Card [Reply]

Hi Thomas,

There are lots of misconception that SAP has stopped delivering its products using ABAP and Java will be used for all new

developments.But the New Enhancement Framework says that it is false.If SAP is using Java for new development then

why we need New Enhancement Framework!!.

Very nice weblog.Keep up ur good work..

Thanks,

Abdul

� Nice One!

2006-01-24 09:26:53 Dirk Feeken Business Card [Reply]

It was probably not Thomas' main goal to clarify this misunderstanding. But if it helps to correct the false impression

that SAP will abandon ABAP development, so much the better.

Dirk

� ABAP and Mark Twain

2006-01-24 10:34:39 Marilyn Pratt Business Card [Reply]

To quote Mark Twain, "The rumors of my death have been greatly exaggerated"

ABAP from this article can be seen as alive and well and constantly evolving.....whatever the rumors may be.

Thanks to Thomas for a very good account of why we should keep an eye on the very much alive Enhancement

Framework.

cheers,

Marilyn

Showing messages 1 through 5 of 5.



Badi Its Basic Structure and Elements for Beginners (1)

Documents

Transcript of Badi Its Basic Structure and Elements for Beginners (1)