The new Enhancement Framework Part 2 – What Else You Need to Know Before Building an Enhancement

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.

You find all weblogs of this series here:

What the New Enhancement Framework Is For – Its Basic Structure and Elements For Beginners

How To Define a New BAdI Within the Enhancement Framework – Part 3 of the Series

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

Source Code Enhancements – Part 5 of the Series on the New Enhancement Framework

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:

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.