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:
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.
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:
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.
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:
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:
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.
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.
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:
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.