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.
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:
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?
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.
In detail there are implicit enhancement options for:
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
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.
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:
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.
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 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:
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 Framew....
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.