Skip to Content

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, 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 thatcan 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:

image

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.

To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Sergio Ferrari
    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).
    (0) 
    1. Thomas Weiss Post author
      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.

      (0) 
  2. Bertrand LAFOUGERE
    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” ? 

    (0) 
    1. Thomas Weiss Post author
      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.
      (0) 
  3. Anonymous
    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
    (0) 
    1. Thomas Weiss Post author
      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.
      (0) 
  4. Goharjou ardavan
    Thanks to your blog not only have I learnt a great deal about BADI’s, I’m also on my way to solve a problem which has been bugging me for some time now. Please keep up the good work and keep these wonderful and easy to understand blogs coming. Only if everybody else could explain things this simply!
    (0) 
  5. anit gautam
    Hi Thomas ,

    i want to enhance a SAP Report prog .

    my question is can i create an enhancement point in the code without applying its developer access key ?

    I know i can do it with implicit enhancement but can i do it with explicit .

    Also when we right click on enhancement point and click create enhancement we dont get enhancement-section.
    so how can we create enhancment section and what is the purpose to create it .

    (0) 
    1. Thomas Weiss Post author
      Creating an Enhancement Point or an Enhancement Section in a SAP program is a modification. In contrast, implementing an existing Enhancement Point or Enhancement Section is no modification. You can use the existing explicit Enhancement Points and sections or the implicit Enhancement Points. There are no implicit Enhancement Sections.
      (0) 
    2. sri vas
      Hi,
      when i created a implcit enhancement in bapi_billingdoc_createmultiple,  next i am entering the code in SE19 in my enhancement but next time the code disappearing,

      i am new to ecc6.0
      plesae tell me where i have to write the logic

      Regards
      Srinivasu

      (0) 
  6. piyush mathur
    Hi Thomas,
    Just want to know, if i insert Explicit enhancement in standard program then it will be a modification, so in that case whether my program will come under SPAU while going for upgrade or not?
    (0) 
    1. Marcin Pciak
      He already mentioned in his previous blog that enhancement is not part of a standard object, but a separate one. Though you seem to be modyfing orignial object, in fact you are creating new one and assign it to different transport. So no modification takes place, only new objects are created (implemented).
      (0) 

Leave a Reply