This is weblog 4 of the series on the use cases of the Enhancement- and Switch Framework. (You find a list with links to all weblogs of this series at the bottom the SDN Wiki page on the Enhancement Framework) In the The Three Use Cases of the Enhancement- and Switch-Framework – Part 3 I have shown you how easy it is to enhance or substitute the method of a global class. In brief, you must just switch to the enhancement mode, provide the name of the container you want to work in, implement the overwrite method, save and activate. That’s it.
In this weblog I will answer the questions you surely have now. Can you enhance every kind of development object, and where can you enhance it? Can you just add what you want as an enhancement or are there limitations? Can you only enhance an application that its developer has prepared for later enhancement? Let me sketch the main answers to these questions before going into any details.
- You can only enhance an object at so-called enhancement options, not just everywhere.
- There are different types of enhancement options, and the type of option determines what kind of enhancement you can attach there.
- Global and local classes, function modules, reports, includes, and Web Dynpro ABAP views offer a lot of different enhancement options for free. They are like a lot of default exits that are automatically provided with the respective development unit.
- In addition to the implicit enhancement options there are explicit enhancement options. Such an explicit enhancement options has to be explicitly defined by an application developer.
Enhancement Options – The Hook Where to Attach Enhancements
Imagine you were the architect of the enhancement framework. What would be the constraints that you would have to take into account when devising an enhancement mechanism? On the one hand there should be plenty of positions where enhancements can be attached to. On the other hand you should not be too permissive: If an application could really be enhanced everywhere this could easily lead to confusion. You could very easily get a mess of code by having SAP code intermingled with your code. Obviously changing SAP code everywhere you feel inclined to will not produce transparent code.
With these considerations in mind you can now better appreciate what the Enhancement Framework offers for you in terms of where you can enhance development objects. One thing that is so sophisticated about the new framework is: You have a lot of options to enhance every application, and still there is some discipline imposed by the framework. How does this work? Well, how does it work regarding the methods of global classes we have just seen? In fact, you cannot add something to a method of a global class just where you want, but you can only implement or add enhancements to enhancement options .
An enhancement option is like an exit or hook for an enhancement. At runtime it functions as a jumping off point where the relevant enhancement is merged into the code of the development that is enhanced. For a method of a global class there are just pre-, post-, and overwrite-exits as we have seen:
What does this figure tell us? You can implement the pre-, post-, and overwrite-exit of a method of a global class, but apart from these enhancement options there is no particular enhancement option available for methods of global classes. To return to our analogy: You need a hook to attach something. Where there is no hook you cannot attach an enhancement. This is why enhancement 4 cannot be assigned to the method.
Looking at a global class at a whole there are many different enhancement options:
You can add new attributes, as many new methods as you need, and you can implement the different exits of methods. And you can add all this using the enhancement technology, that is without modifying the global class.
But there is something you cannot do: You cannot attach an additional UI element of a Web Dynpro ABAP table, such as a table column, to an exit for new types. This observation leads us to a general fact:
The type of an enhancement option determines what kind of enhancement you can attach there. So we have two limitations:
- You can only attach an enhancement to where there is an enhancement option. If there is no option, or no hook to use the analogy, there is no hold for an enhancement.
- The kind of enhancement you want to attach must fit the enhancement option. So you can attach an overwrite method to an overwrite exit, new methods to an enhancement option for new methods etc. Or to make the same point another way: On different kind of hooks you can attach different kinds of objects.
These restrictions raise a very basic question. You want to know which kind of enhancement options exist at all. Which kind of objects can you enhance in which way?
Plenty of Different Enhancement Options Provided By the Framework
Let me sum up the answer before I go into the details: There are really a lot of different enhancement options around for development objects like global and local classes, includes, reports, and function modules. And they are provided without anybody having to stir a finger. If you are familiar with the classic customer exits, you probably know: Each customer exit had to be provided by an application developer. If the developer of the relevant unit had not inserted a customer exit, there was none.
With enhancements options, this is completely different. There are the so-called implicit enhancement options. They are provided by the framework for you. So, if you have an ABAP development unit in a system with a NetWeaver 7.0 (or higher) ABAP stack, you have a lot of implicit enhancement options, which you get for granted.
Implicit Enhancement Options for Application Logic
In detail there are implicit enhancement options for:
- Additional types, attributes, and methods of global classes
- Overwrite-, pre-, and post-methods of global classes
- Optional parameters of methods of global classes and function modules.
The source code plug-in technology of the Enhancement Framework provides a lot of default positions where you can add source code to existing source code units. You can add source code plug-ins at the
- beginning/end of method (both of global and local classes)/function module/form routine
- end of a local structure
- end of a private/protected/public section of a local class
- end of report and include …
For example, a source code plug-in that is assigned to the implicit enhancement option of a report is merged with the report at runtime and has access to all global variables of the report. Though this is an overview weblog let me just add one interesting detail. How can you know if there is an implicit enhancement option in a source code if you have not memorized this list or suppose that I might have forgotten some option in this list? I must confess, sometimes I am not sure myself if there is an implicit enhancement option at some position. But there is no need to know this. Just ask the framework. Let me show you an example of the method of a global class. Suppose you look at the method code in the Class Builder, then you choose the menu Edit- Enhancement Operations – Show Implicit Enhancement Options as shown in the next screenshot:
As result you see all the implicit enhancement options in the relevant source code unit:
As I have told you there are two implicit enhancement options, one at the beginning and one at the end. So it is really perfectly easy to find out which implicit enhancement options for source code plug-ins a development unit offers.
Implicit Enhancement Options for Web Dynpro ABAP
Up to now I have only described how to enhance backend functionality. But what about the user interface? As you remember from weblog 2 we enhanced a Web Dynpro ABAP screen. And this is possible because there are dedicated enhancements for Web Dynpro ABAP. In fact, this new SAP user interface technology offers a lot of different enhancement options. There are options for:
- Pre- and post-methods of Web Dynpro methods
- New methods
- New navigation paths (Plugs)
- New actions
- New attributes
- New nodes that hold the data for the UI elements
And the probably most surprising feature is: You can hide any existing UI element in the enhancement mode. This means: At runtime this UI element does not exist, but it is still part of the component as a transport element. This is because a Web Dynpro UI element that is overwritten simply is not compiled. That is why it looks at runtime as if it were deleted.
Looking at all these different enhancement technologies, you are probably convinced that there are now plenty of implicit enhancement options in the system. This means for you as a SAP customer: You can enhance a SAP application at a lot of different positions, called enhancement options, and you can do this without modifying or even touching the SAP objects. Remember: Hooks work like standard exits. Once something is attached there it is processed at runtime.
Explicit Enhancement Options
But the implicit enhancement options are only one side of the medal. While they are provided by the framework and so-to-speak unconditionally available, there is still another type of enhancement options that are different in principal:
These options or hooks have to be provided by an application developer. Only if he provides an additional hook, you can attach something to this hook. Up to now there are two different kinds of enhancement options:
- The new kernel-based BAdI
- Explicit enhancement points and sections.
The new BAdI is now part of the Enhancement Framework. It is so-to-speak an option for an object plug-in. The typical use case is that a SAP developer calls a BAdI method and by implementing the BAdI you determine which method implementation is processed at runtime. So a BAdI call is in a way like a dynamic method call with a fixed interface. Apart from the fact that the new BAdI is now fully integrated into the enhancement framework, it offers plenty of other advantages over the classic BAdI:
- Its performance is up to 600 times higher than that of the classic BAdI
- Due to its integration into the kernel it is not only faster, but comes with a simpler and clearer syntax.
For more information on the new BAdI, in particular on how to create and implement a new BAdI look at my weblogs: How To Define a New BAdI Within the Enhancement Framework – Part 3 of the Series and How to implement a BAdI And How to Use a Filter – Part 4 of the Series on the New Enhancement Framework.
The other explicit enhancement options I mentioned are explicit enhancement points to insert source-code plug-ins. In fact an explicit enhancement point behaves pretty much like an implicit enhancement point: A source code plug-in attached to such an explicit enhancement point is processed in addition to the code of the enhanced object. But the enhancement section is something that exists only as an explicit enhancement option. The code of an enhancement section is substituted by an enhancement at runtime if the section implemented. If an enhancement section is implemented, at runtime the enhancement is processed instead of the code in the enhancement section. So an enhancement section is marked for possible substitution.
Just keep in mind: The explicit enhancement options have to be provided by an application developer. He has to insert an enhancement point so that somebody else can assign an enhancement to this point. In contrast, the implicit options are unconditionally provided by the framework.
There are plenty of implicit enhancement options in an ABAP based SAP system of the NetWeaver release 7.0 or higher. All classes, function modules, reports, and includes offer standard positions where a customer can add enhancements. This does not require any particular preparations on the part of the SAP application developer. The implicit enhancement options are provided by the framework. There are different types of enhancement options and the type of enhancement options determines what kind of enhancement you can attach there. In a UI based on Web Dynpro for ABAP you enhance any UI element that you could add in the change mode. Moreover you can overwrite every UI element in a Web Dynpro ABAP screen by an enhancement. In contrast to the implicit enhancement options , there are the explicit enhancement options . They require some consideration, planning and preparation on the application developer´s part. The most prominent explicit enhancement option is the new kernel-based BAdI that is now integrated in the Enhancement Framework. In addition, there are explicit Enhancement Points and Enhancement Sections. If you need more detail information on how to implement an enhancement option refer to my weblog series on the technical details of the Enhancement Framework. You can find these weblogs as well as all the weblogs of the series on the use-cases of the Enhancement- and Switch-Framework at the bottom of the SDN Wiki page on the Enhancement Framework.
In the next weblog you will learn the basics about switching. You will both understand its motivation that is why you want to switch and how the switching is managed by the Switch Framework.