How to Get the Most From the Enhancement and Switch Framework as a Customer or Partner – Tips from the Experts
In this weblog we will tell you how to use the Enhancement and Switch Framework most efficiently when you adapt SAP programs as customer or partner and how to save a lot of time and costs in subsequent upgrades. Maybe you already know that the new Enhancement Framework is a powerful technology that helps you to change SAP programs while avoiding much of the drawbacks of traditional modification technology. In this weblog Michael Acker, the architect of this Framework and expert for SAPs adjustment tools for enhancements and for modifications, and I will explain how you work with this framework really efficiently. We repeat some basics of the new Enhancement and Switch Framework while focusing on the question of how you should design your enhancements as a customer when you change and enhance SAP standard applications:
- We first explain why enhancements are so much more robust in an upgrade than modifications.
- Next you learn how you profit from making your enhancements switchable and how you do this.
- In the next section you will understand why some enhancements may still need adjustment after an upgrade or installation of an SP and how you can minimize this risk by a clever choice of the right enhancement technology.
- When you have understood this the stage is prepared for a list that shows you how and with which technology to enhance SAP programs. This list is based on all the considerations mentioned in the sections before. It also covers classic enhancement technologies like Dictionary appends, Customer Exits and User Exits.
In general this weblog presupposes experience with modification technology and classic enhancements and that you know how to work with the new Enhancement and Switch Framework. For basic information on this framework have a look at the two weblog series linked at the bottom of this SDN wiki page. The first series is focused on technology of the Enhancement Framework while the second sketches the important use-cases of the Enhancement and Switch Framework from more a comprehensive and not so strictly technology driven perspective.
Why Enhancements are not overwritten in an Upgrade
At the beginning, let me quickly repeat the basic reasons why enhancements are so much better than modifications and why they save you a lot of work in an upgrade. With the new Enhancement- and Switch Framework you are almost as flexible as with modifications when you want to change or add something to SAP standard objects, without modifying these objects. This means, you achieve the same aim, but use a different technology. In a way, you can compare this to playing music CDs instead of records.
With enhancements you avoid most of the work that modifications cause in the software lifecycle. Enhancements are never overwritten in an upgrade, because they are objects in your namespace, while modifications are part of the object they modify. So with enhancements, you have most of the advantages of modifications, while enjoying a freedom from most of the work that modifications require in an upgrade.
Customer Enhancements of an SAP object are objects in their own right and live in the customer namespace in your packages.
Still, at runtime they are processed at the appropriate position in the object they enhance:
In an upgrade, all SAP objects are substituted whether they have changed or not. But customer enhancements safely survive an upgrade because they live in packages in the customer name space. The graphics shows a Web Dynpro ABAP UI in which a table element has been enhanced by an additional column for an existing table and a new detail table. All these enhancements live in packages of their own. In the example the new table version delivered by SAP has one column less (a pretty unrealistic example I must confess), and, still, the enhancements are not all influenced by this. They survive the upgrade in the customer-owned packages and are merged in by the compiler at the appropriate position just as before. :
In contrast to enhancements, modifications are physically part of the object they modify. This means that every single modification gets lost in an upgrade and to be re-inserted even in cases where the underlying SAP object has not changed at all:
Why and How to Make Your Enhancements Switchable
The Switch Framework can help you to decide if errors in an SAP application that was adapted by the customer results from a problem with the SAP code or if it was caused by your code. Let us tell you how this works.
Since Modifications and enhancements change an application at a very deep technical level, they may cause errors at runtime, both on the semantic or the syntactic level. In general, code adaptations may change the flow of control in applications in a relevant way that violates semantics constraints. For example, a modification and also an enhancement may avoid that some code is processed that protects the integrity of the data. Or another very simple example is that the modification or enhancement may lead to an uncaught exception. Obviously, it is difficult to determine whether an error would have occurred without the enhancement or modification, or in other words, whether it is the enhancement or modification that caused the error or semantic problem, or whether the problem lies in the SAP application.
The new Switch Framework provides a good solution to this problem: Just encapsulate all your changes of the underlying SAP application by switches and to assign these switches to business functions that should reflect your relevant project structure. By deactivating your business functions you can test where an error is located, in your code or the SAP code.
If the Business Function is activated/switched on all the dependant switches are turned on and the objects that are controlled by these switches are processed:
If you select the flag “reversible” when creating the business function, you can switch it off, and all your enhancement are not processed at runtime. (You can deactivate Business Functions and switch of the Enhancements assigned to switchable packages that are dependent on these Business Functions as of NetWeaver 7.00 SP14, which is available for all ERP 6.00 customers) In fact, they are not even compiled:
The Transaction to create and maintain switches is SFW1, the transaction to create and maintain business functions is SFW2. You activate and deactivate business functions in the transaction SFW5.
How to Minimize the Adjustment Effort for Enhancements: Deliberately Choose the Enhancement Options You implement
Though enhancements as transport objects are never overwritten in an upgrade, there are still situations in which you have to adjust your enhancements after an upgrade or import. If the enhancement options that you use or that you implemented are moved or deleted, during the upgrade or the import of an Enhancement Package or Support Package, we will inform you of this and support you by the transaction SPAU_ENH.
Let me explain in some more detail why you might have to adjust your customer enhancements after an import or upgrade. First all enhancements have a position in the SAP objects where they are attached. These are the so-called enhancement options. They are the hooks the enhancements are attached to and keep the information where the compiler should merge in the respective enhancement. If this hook is gone, the compiler can no longer merge in the enhancement. For example, if you implement a pre-method, for example, to the SAP method e_method and if e_method is deleted by a transport, your enhancement can no longer be called. In such cases the transaction SPAU_ENH informs you after an upgrade that you have to adjust these enhancements and offers you tool support to adjust these enhancements.
The Enhancement Framework provides a lot of implicit enhancement options that are available in every source code unit without the application developer having to stir a finger, and the explicit options such as the new BAdI and the enhancement points and sections. Still, the mere fact that an item can be enhanced does not mean that SAP can guarantee its stability. But, in general, interfaces that we release ourselves (such as BAdIs and customer exits) are more stable.
Though the transaction SPAU_ENH helps you to adjust the enhancement after an upgrade, an import or a support package installation you can minimize this effort by a clever choice of the appropriate enhancement technology:
- First look for high-order enhancements technologies like BAdI or CMOD should.
- If you find none of these technologies around to make the changes you want to use class enhancements or source code plug-ins in function groups or reports. The stability of a particular enhancement option of this kind heavily depends on its particular position: In general an enhancement option in a function module or a public method is more stable than one in a private method or a form routine.
In Which Order and How to Enhance SAP Applications with Switchable Enhancements – How to Proceed
We recommend the following procedure for Customers to adapt SAP development objects. This list takes into account the considerations mentioned in the sections above. So we prefer:
- enhancements over modifications
- switchable objects (all enhancements of the Enhancement Framework and many more objects can be switched with the Switch Framework)
- more stable enhancement options
To fully take advantage of this list you should have knowledge of the principles and techniques involved in enhancements and modifications of the standard SAP system.
Enhancements to the ABAP Dictionary:
- Create appends to add fields to existing databases.
- To add values to an input help for a domain, create a fixed-value append.
- To add customer indexes to SAP tables, create enhancement indexes.
- Use the collective search help append to include your own search helps in SAP collective search helps.
Dictionary Appends are not switchable before NetWeaver 7.00 Enhancement Package 2 that is available for SAP ERP customers when they install SAP ERP Enhancement Package 5. In general, it is not recommend to switch off Dictionary objects just for testing, because data on the database might get lost. For example switching off an additional column of a database table removes the column and all its data from the database.
Preparations and General Procedure to Make Your Enhancements Switchable
- Create one or several business functions in the customer namespace. The type of business function must be “Enterprise Business Function” and the business function must be “Reversible”.
- Create one or several Switch Framework switches and assign these to your business functions.
- Create one or more customer packages and assign these to your switches.
- When you create the enhancements mentioned in the next sections you must assign each enhancement to an enhancement implementation that belongs to a switchable package (the ones you have created in 3.)
- Organize your enhancement implementations in composite enhancement implementations. Since an enhancement project, in general, consists of many enhancements, it is important to impose a structure on all these objects.
- If you need to create many Enhancement Spots of your own as described below (How to enhance business logic, 8), organize them from the very beginning into composite Enhancement Spots and nest them if it suits the project.
How to Enhance Business Logic
- In principle, the BAdI is the best enhancement technology, since it provides an interface by which the data exchange between the application and the enhancement is controlled, and it is more stable. The new kernel-based BAdI is part of the Enhancement Framework and, for this reason, its implementations can be switched. Just add the enhancement implementation (to which the BAdI implementation(s) belong) to one of your switchable packages as described above.
From here on this procedure to make the enhancement switchable is not mentioned as it is the same for every enhancement of the Enhancement Framework: It must be part of a package that is assigned to a switch which in turn is assigned to a business function.
- If you want to implement a classic BAdI, you should know that these classic BAdIs are not switchable. Therefore, we recommend the following workaround: Implement the BAdI with a blank class. Add your source code as a source-code enhancement at a specific point at the beginning of the relevant method. Add new methods, attributes, and so on for local classes at the specified points at the end of the relevant class sections.
- User exits – CMOD are not switchable. Therefore, we recommend the following workaround: Create an empty customer enhancement. Add your source code as a source-code enhancement to the specific point at the end of the ZX include that was included by the exit module.
- Old user exits (blank subroutines): Add your source code as a source-code enhancement at a specific point at the beginning of the subroutine. Therefore, you do not have to enter your source code again in transaction SPAU the next time you upgrade. This procedure also makes the enhancement switchable.
- Use the class enhancement or the interface enhancement in the Enhancement Framework to enhance classes or interfaces. Of course, it is better to enhance public than private methods.
- Use the function group enhancement to add parameters to SAP function modules.
- Use the source-code plug-in technology (explicit and implicit) to enhance the source code.
You should try to use the most stable points. In many cases, an experienced developer can assess himself which points are more stable. For example: The beginning of a central function module is generally more stable than an explicit point in a relatively new application. You should keep in mind: Adjusting the implementation of an enhancement point generally requires less effort than the implementation of an enhancement section. The reason lies in the code that typically implements a section: Most time the implementation of a section contains code copied from the enhancement section plus the additional code, while the implementation of an enhancement point only contains the additional code.
- If you cannot find an explicit or an implicit enhancement point, use a modification to create your own explicit enhancement point or an enhancement section. To do this, use your own enhancement spot. Implement your enhancement point. After an upgrade, import, or installation of a Support Package, you must first adjust the modification, but you still profit from the fact that your code proper is in the enhancement: The advantage of this is that the enhancement is switchable and can be grouped with your other enhancements.
How to Enhance User Interfaces
- Use the Web Dynpro enhancements to enhance the Web Dynpro ABAP. You can also hide all UI elements of the SAP Web Dynpro user interface by deleting it in the enhancement mode. Add the enhancement implementation for your Web Dynpro ABAP project also to one of your switchable packages.
- For classic screens, there is no enhancement technique except for the BAdIs and CMODs mentioned above. Create all of your additions and changes as modifications, but make them switchable by assigning the UI elements or the modules directly to a switch. Note that you can also hide existing UI elements of the original SAP Dynpro.
If you need to enhance any other objects that were not mentioned, you should use modification technology. If possible, you should avoid these modifications because they are not switchable.
In order to profit most from the new Enhancement and Switch Framework you should take into account some considerations when you enhance a SAP application as a customer. Let me just sum up some of the main points:
- You should prefer enhancements, both those of the Enhancement Framework and classic ones like Dictionary appends and CMODS to modifications, because they live in your customer name space and are never overwritten in an upgrade.
- Choose enhancement types that are in general more stable such as BAdIs, CMODs or enhancements to public methods of global classes.
- Prefer switchable enhancements, and use the techniques described above to make classic enhancements switchable. If your whole enhancement project can be switched off you can more easily tell if a problem results from the standard SAP code or your enhancements.
If you obey the rules and rules of thumb described in this weblog you should have far less work in an upgrade than with modifications and also profit from all the additional benefits described above.
The enhancement and particularly the switch framework are a great invention for SAP and customers to find happy working (and upgradable) compromises together.
What I think should still be treated with caution, is that it should not be misused to make more extravegant modifications because it is "supposedly" safe now... and SAP should have some change control over the number and location of enhancement possibilities offered, otherwise it will become a "crows nest" as well.
An excellent solution though!
I must agree that some of these enhancements allow the developpers to make modifications to SAP's logic in a way that may seem "safer" because the code will not be overwriten during an upgrade.
These enhancements can however "break" the processes and the system just as much as a modification to SAP standard objects.
In our company, most developments must be approved by a comity and modifications to sap standard code was treated with much more care than other standard enhancements.
Recently , we even had developpers say that with the new framework, this would not even be a modification ... hopping to justify the changes they we're requesting.
I'm wondering how you make sure that your business dosn't do those more extravagant modifications ?
Also, is there some guidelines that we could give developpers so they could judge that their developments although done through enhancements may be riskier... (The one on using public methods rather than private was a good one.).
But what I describe in this weblog is something different: If you enhance a standard application as a customer and most of the relevant changes are brought about by additional code or Web Dynpro ABAP enhancements you are, in general, well advised to make your whole addon functionality switchable. (In general, even some Dictionary Appends should pose no problem. For example, having some more columns in a database table will not have an impact on an application if the relevant lines of code that work with these columns are switched off. But this statement about Dictionary Appends is only a rule of thumb, and each particular case must be assessed on its own. For example, if you access the enhanced database table with SELECT *, you will get into trouble if your program does not expect the columns in the table append.)
Making the enhancements switchable is done by encapsulating all enhancements by switches and assigning these switches to a reversible business function. Then you have your own reversible business function in your system. Still, all the ERP and IS business functions your system cannot be switched off.
I made an implicit enhancement in one program, I created a switch and assigned the package. in SFW2 I used EA-HR and added my switch, my enhancement is now working but I dont see it in the code itself. Any idea why?
first of all congratulations for this excellent analysis.
It is exactly this kind of insight we need in the community and it is not always easy to find.
I appreciated especially the part "Why Enhancements are not overwritten in an Upgrade".
I have a question for you. What is your opinion about de-activating an enhancement in a productive environment if something goes wrong?
Dr. Spyros Stamou
Some of these advices may also be found in note 1257033 - Cookbook: Modification/enhancement for standard SAP system
I think the worst drawback with enhancement framework is in companies where the developers work without coordination (yes it exists, and it happens very often), they enhance standard code anywhere, don't try to make any common code, it's awful for maintenance! With SSCR keys, there was a kind of limitation and control. When they need to enhance a standard block in the middle, some people don't hesitate to create a new implementation at the beginning of the block where they copy the whole block + their modification, and end it with an EXIT. I think we must use an SSCR key in that case.
Also, I noticed that switching on or off a custom BF takes quite a long time for only 4 or 5 objects (job lasts for 20 minutes, and the log shows it worked on standard sap programs and ddic), on my 7.00 sp13 system. But we do it once. Maybe there is a correction for that but I didn't find.
I found in the past that there were numerous little bugs while using the enh framework, but none critical. I am now in 7.0 SP13 + some notes and it works well. While looking for notes, I saw a few ones (2 or 3) that were a little bit scary, which corrected problems of enhancement deletion while using SNOTE or SPAU or SPAU_ENH, etc. We should be very careful to look at these notes (or as always said, apply the last SP!) Anyway, these problems should be detected in test systems (I hope), and enh framework will become more and more stable (or maybe already stable in the last SP).
In conclusion, I think the enhancement framework is very useful for customers (especially, be able to relate enhanced code portions within the same composite enhancement spot, + be able to switch off enhancements), but there must be a good coordination to avoid maintenance extra work.
very helpful document
thank you so much for sharing