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

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

Showing messages 1 through 5 of 5.

Titles Only
Main Topics

Oldest First

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,
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
o

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

The new Enhancement Framework Part 2 - What Else You

Need to Know Before Building an Enhancement
Thomas Weiss
Business Card
Company: SAP AG
Posted on Mar. 15, 2006 02:06 AM in ABAP

Subscribe
Print
Permalink

This weblog is part two of a series on the new Enhancement Framework. Together with
the knowledge from my last weblog 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 weblog we should have prepared the
ground for building our first enhancement definition.
In my last weblog, 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 weblog
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 weblog.

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, preand 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, in my last weblog you have learnt the basic concept of an enhancement. In
this weblog 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. And this is what I will show you in the next weblog. We
will build a BAdI and see all the pieces of theory at work that you have become
acquainted with by now.
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

Showing messages 1 through 6 of 6.

Titles Only
Main Topics

Oldest First

explicit enhancements
2006-07-19 02:01:33 Glen Spalding Business Card [Reply]
hi thomas, thanks for the blog first.
my question regarding explicit enhancements is this.
if the developer has to manually program the explicit enhancement (hook), and it
is required in amoungst standard SAP code, would that be considered a
modification?

thanks
glen
o

explicit enhancements
2006-07-19 23:40:45 Thomas Weiss

Business Card [Reply]

Of course, if a customer inserts an enhancement point in SAP code, it is a

modification. In principle, customers should preferably implement
enhancement points. But in some situations creating an enhancement point
as a modifcation will help to keep the modification small. The idea behind
this is: Instead of writing a large modification, add an enhancement point
(of course, as modification) and put all the rest of the code you need to add
in the source code plug-in that implements the respective enhancement
point. This way, all the code in the source code plug-in profits from the
features of the Enhancement Framework.

part !!! please

2006-03-21 03:18:06 Bertrand LAFOUGERE Business Card [Reply]
Really nice serie Thomas.
Concerning the different enhancement technologies I'm a bit surprised by the
class one.
The sentence "add additional methods, optional parameters, pre and post methods
to existing methods" does not sound object oriented. Will the enhancement inherit
the standard object or will it use a kind of "append" ?
o

part !!! please

2006-03-22 06:18:13 Thomas Weiss

Business Card [Reply]

From a technical point of view, pre- and post methods of classes are
implemented as methods of a local class. So they are perfectly object
oriented. It was a deliberate decision, that class enhancements should not
use inheritance. The enhancement implementation elements do not inherit
the standard object, but are compiled at runtime together with the class
that is enhanced in one compilation unit. Up to now pre- and post methods
have only access to the public attributes of the class, but this will be
changed in the next release.

Enhancement vs. Switching Framework

2006-03-16 01:26:07 Sergio Ferrari Business Card [Reply]
Thanks a lot Thomas for this great series.
I'm looking forward to the next weblog and I want to ask you if you can explain

the relation between Enhancement and Switching Framework (related to Industry

Solution).
o Enhancement vs. Switching Framework
2006-03-22 06:16:29 Thomas Weiss
Business Card [Reply]
There is a close relationship between the Enhancement and the Switch
Framework. All enhancement implementation elements are switchable.
The switch is assigned to the package of the respective simple
enhancement implementation, that is the container the enhancement
implementation element belongs to. So it is important to pack
enhancement implementation elements that should be switched differently
in separate enhancement implementations.
But you can also switch many other objects: Appends, SI- and CI-includes
for DDIC structures, fixed value appends to domains, secondary indexes,
append search helps are switched by package assignment. Screen elements
and flow logic in the screen, menu entries and functions, IMG nodes and
customizing can be assigned directly to a switch.