GRC
HR
SCM
CRM
BI


Article

 

Modification-Free Adaptations of SAP Programs? With Enhancements, They're Possible — and Here's How

by Thomas Weiss | SAPinsider

July 1, 2008

In the past, an upgrade to the SAP core often swept away any modifications that your developers had carefully hard coded into your system. The solution to preserving your custom code? SAP’s new switch and enhancement framework. Here, get an intimate look at the framework’s structure and find out how it catapults you beyond the traditional limitations of modifications.
 

 

One of the great strengths of SAP software has always been its adaptability — customers can either use a solution straight out of the box or truly customize it to their business needs. Until a few years ago, though, developers had to hard code any changes as modifications, which would then be swept away should the company decide to upgrade the core.

But now, as previous Under Development columns have delved into, there's a more state-of-the-art technology to adapt SAP software to your needs: the switch and enhancement framework.1

NOTE! In the April-June 2008 Under Development column, Karl Kessler described how to enhance a Web Dynpro ABAP application in some detail. In this article, I'll focus on the structure of such enhancements and their basic principles, rather than implementation details.

In addition to the move away from modifications, this framework powers some exciting benefits for SAP customers — you've likely heard about the new enhancement packages for SAP ERP 6.0,2 or the fact that SAP now develops all of its industry solutions (ISs) in one system and delivers them on one set of DVDs (you simply switch on the solution you need). These are the switch and enhancement framework's most important use cases:

Customers can now adapt SAP code without modifying it. With the new switch and enhancement framework, you can use enhancements to change or add something to SAP standard objects without having to modify them. Enhancements are almost as flexible as modifications,3 and they help you avoid most of the work that modifications cause in the software life cycle; 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.

All SAP industry solutions are now developed in the latest ERP system. This translates into substantial advantages for customers:

  • You can install the IS you like based on the latest SAP ERP release — you need not wait for conflict resolution transports.4

  • You can use the latest SAP ERP technology in your IS — some new logistics features in the IS Oil and Gas, for example — whereas before you needed two systems: one for the IS and another system running the latest version of SAP ERP.

  • Accordingly, you now need fewer systems in your landscape — and this, in turn, means a lower TCO.

Apart from this, by providing all ISs on one set of DVDs, SAP can offer functionality that can be used within different ISs. A user of one IS can reuse functionality from another IS. For example, IS Oil and Gas customers can reuse all the functionality of the IS Utilities (as of enhancement package 3). This is a great advantage: Oil and gas companies can not only calculate the mineral oil tax and plan the storage and transport of oil and gas, but — because of the additional functionality of the IS Utilities — can also handle mass billing for the end customer.

The enhancement package strategy of SAP ERP 6.0 gives you a new dimension of choices for getting new functionality. In the classic world, you had to choose whether you wanted to stay on one stable release or have new functionality. With SAP's new enhancement package strategy, you can have all the advantages of staying on one release and you can get new functionality — not by an upgrade, but as parts of enhancement packages. Enhancement packages provide new features on top of the recent release. The import of these new features is separate from their activation. Directly after the import, your system behavior is still the same: There are no changes of user interfaces (UIs) or processes. Once imported, the sources that realize the new functionality are still not compiled before they are activated or switched on. On both levels (import and activation), you have full choice: Import only what you want and activate only the parts of the imported new functions you are interested in.

In this article, I will focus on the first use case: I'll explain the basic advantages that enhancements have over modifications and walk you through how to make modification-free adaptations of SAP programs. In future articles, I'll demonstrate how these basic mechanisms are put to work in the reintegration of SAP industry solutions and ERP enhancement packages. All told, you will learn how the switch and enhancement framework empowers all three of these use cases, and you will gain a solid understanding of this powerful new technology's basic structure and concepts.

Enhancements Versus Modifications: What Are the Key Differences?

Consider a customer who wants to enhance a Web Dynpro ABAP UI table element by adding an additional column and a detail table. With the enhancement framework, this is quite easy to achieve: You'd simply add the screen elements as enhancements — you'll then see them in the correct position, both in the design-time tools and at run time (see Figure 1). But what is the difference between these enhancements and a normal change of code? The additional column, the additional table, and a new button can enhance an SAP object and still be part of your package as is shown in Figure 1. And still, at run time, they appear in the correct position as part of a screen that is an SAP standard object. Your enhancements merge into the object they enhance at compile time (see Figure 2). This has one important consequence: Because this merging is done at compile time, processing enhancements does not slow down an application.

Figure 1
Adding enhancements to an SAP UI table element
Figure 2
UI enhancements merge into the SAP standard object screen at compile time

The best way to highlight the impressive difference that enhancements make is to sketch how you would make the same changes with the classic modification technology (see Figure 3) — specifically, how do modifications and enhancements fare differently in an upgrade?

Figure 3
A major inconvenience of all modifications is that they are overwritten in an upgrade

From a technical point of view, a modification is part of the object it modifies. This explains all of the inconveniences that modifications introduce in an upgrade. A modification is a subtenant in an SAP object, so it depends on the SAP object far more than enhancements do. Enhancements, on the other hand, are objects of their own — and they live a life of their own in packages of their own.

In an upgrade, a new SAP object substitutes the old one, and all modifications are lost. Using SAP's Modification Assistant (the SAP tool that adjusts modifications) you can reinsert the modification semiautomatically or manually (depending on the way the changes in the SAP object affect the position of the modification). But unless you adjust every single modification in your system after the upgrade, your modifications are gone. You have to touch every single modification after the upgrade — even though none of the ojects you have modified may have changed in the upgrade.

NOTE! It is never the change mode, but always the new enhancement mode, in which you add enhancements to an object.

In contrast, enhancements cause far less work in an upgrade because they reside in packages, which make their lives safer in an upgrade. Consider that you've enhanced an SAP object that will change in the upgrade; it will be replaced by a different version, as shown in Figure 4.

Figure 4
An upgrade only overwrites SAP objects; your enhancements are not touched by an upgrade

At the bottom left corner of Figure 4 (enclosed by the blue dotted line), you see what happens to our UI table in an upgrade. The new version of the table, where we're back to one less column, substitutes the old version . But even though the new object substitutes the SAP standard object, this has no impact on the enhancements. The upgrade only affects the SAP objects. Customer's packages are not touched in an upgrade, so all your enhancements will survive the upgrade without you having to lift a finger ( and ). In the next step, the enhancements are again merged into the SAP object at compile time .

Easily Exchange a Global Class Method — A Step-By-Step Description

As simple as it was to add a new column to the UI table, that alone will not suffice — to populate the new column with data, you also need enhancements in the back end. In particular, you have to adapt the SELECT statement, which retrieves the necessary data from the database. To give you the real flavor of how easy it is create back-end enhancements, let's walk through how to enhance the method that gets the data.

It's important to understand that you can now not only enhance but substitute an SAP development object without modifying it. To do this, there is a new mode for enhancing objects in the ABAP Editor: The enhancement mode.

  1. First, you get to the enhancement mode in an analogous way to how you moved to the change mode (see Figure 5).

    Figure 5
    Entering the new enhancement mode from within the ABAP Editor
  2. Next, create a new container (or use an existing one) for your enhancements (see Figure 6). I won't delve into any details about these containers, which are called Enhancement Implementations, in this article; for the most part, they function only as a useful coating for the enhancements themselves.

    Figure 6
    Choosing a container for your enhancement
    As you confirm this dialog window by clicking the green check mark, you're ensuring that everything you now create will be an enhancement — and therefore will not change, or even touch, the underlying development object.

  3. After closing the dialog window, you will see the screen shown in Figure 7. You are now in the enhancement mode of class CL_EXAMPLE_CLASS. In the brackets at the top of Figure 7, you see information about which container your enhancements are stored in.

    Figure 7
    The enhancement mode of the global class
  4. For a method of a global class, you have three options for where to attach an enhancement: a pre-exit, a post-exit, and an overwrite exit. An enhancement attached to a pre-exit is processed before the method, to a post-exit is processed after the method, and to an overwrite exit replaces the implementation of the method at run time.

    From a functional perspective, we want to select one more column in our SELECT statement. Because it is not possible to add an enhancement within a statement, we have to substitute the whole statement — so here we'll select the overwrite method in order to substitute the whole method implementation.

    To do this, select Edit ? Enhancement Operations ? Insert Overwrite-Method (see Figure 8).

    Figure 8
    Selecting the appropriate option for where to attach the enhancement
  5. You will then see an additional button in the row (see Figure 9). This button represents the enhancement method, which will substitute the original method.

    Figure 9
    The button leading to the implementation of the overwrite exit
  6. Click the Overwrite-Exit button to navigate to the ABAP Editor, where you can implement the overwrite exit code. Then, when the applications calls the method at run time, the code of the overwrite method will execute instead of the original code (see Figure 10). And that's it!
Figure 10
The overwrite method code, not the original code, executes at run time

 

By means of the enhancement framework, all of this happens without the developer having to change the original class. The framework knows: If an overwrite exit is implemented, compile the overwrite method code instead of the original method.

Where and How to Enhance an Application: Lessons Learned

So what does this example teach us? I'd like to emphasize three main points:

  • You cannot add an enhancement to a method of a global class anywhere you want; you can only implement or add enhancements at positions where there is an enhancement option, which is like an exit or a hook for an enhancement (see sidebar). This is generally true for all types of enhancements. If there is no option, or no hook, there is no place for the enhancement to hold on. At run time, the enhancement option functions as a jumping off point where the relevant enhancement merges into the code of the enhanced development object. And for a method of a global class, there are only pre, post, and overwrite exits.

  • Enhancement options carry information about where an enhancement should be processed at run time. If an option gets lost or is changed in an upgrade, the system might no longer know where to place the enhancement. To support you in this situation, the transaction SPAU_ENH shows you which enhancements you have to adjust after an upgrade, which support packages to install, or which transports to import.

  • The kind of enhancement you want to attach must fit the enhancement option. For example, you can only attach an overwrite method to an overwrite exit, or new methods to an enhancement option for new methods. In other words, you can attach different kinds of objects on different kinds of hooks.

Enhancement Options: Implicit and Explicit

Global and local classes, function modules, reports, includes, and Web Dynpro ABAP views offer a lot of different enhancement options without anyone having to do additional work. They are much like default exits, which the framework automatically provides in the respective development unit. This means, for example, that whenever you have a method of a global class, the framework automatically provides pre, post, and overwrite exits. This is why they are called implicit enhancement options.

In addition to implicit enhancement options, which the framework supplies, there are also explicit enhancement options, which have to be clearly defined by an SAP application developer, for example, who anticipates that a customer might want to select more columns from the database than the original program does. Here, the developer could insert an explicit enhancement option. This way, another developer could implement this enhancement option without changing the original development unit.

An interesting note: While implementing an enhancement option is not a modification for a customer, inserting an explicit enhancement option into the original SAP program does modify the program. For modification-free adaptations of SAP objects, customers depend on the existing enhancement options. If you need to add some code at a position where there is no enhancement option, you still have to modify the object. (This is why I earlier referred to enhancements as being almost as flexible as modifications.)

Conclusion

SAP's new enhancement framework makes customer adaptations of SAP objects far more robust in an upgrade — and creates far less post-upgrade work for developers. In contrast to modifications, which are part of the object they modify and are lost in an upgrade, enhancements are never overwritten in an upgrade because they live in the customer namespace.

In contrast to modifications, which are part of the object they modify and are lost in an upgrade, enhancements are never overwritten in an upgrade because they live in the customer namespace.

To implement enhancements, developers have to assign them to enhancement options, which carry information about where the enhancement should be processed at run time. The framework provides many different implicit enhancement options, but developers can also add explicit enhancement options. In the rare case that an enhancement option is affected by an upgrade, a new support package, or an import, a new transaction (SPAU_ENH) will alert you so that you can then insert the untouched enhancements somewhere else.

Modification-free enhancements are one important use case of the switch and enhancement framework. Look for future Under Development columns that will cover how the framework empowers the reintegration of SAP industry solutions in the SAP ERP core, the new enhancement package strategy of SAP ERP 6.0, and the benefits of each. With an understanding of these additional use cases, you will gain an even deeper understanding of the power of the framework and its benefits for developers.

 

 

Additional Resources

  • "Introducing the Enhancement Framework — a new way to enhance SAP programs without having to modify them" by Thomas Weiss and Michael Acker (SAP Professional Journal, January/February 2008, www.SAPpro.com)

  • "Introducing the switch and enhancement framework — consolidating industry solutions with the mySAP ERP core" by Karl Kessler (SAP Professional Journal, March/April 2006, www.SAPpro.com)

  • "A New and Improved Approach to SAP Industry Solutions — How the Switch and Enhancement Framework Now Consolidates SAP Industry Solutions with the ERP Core," an Under Development column by Karl Kessler (SAP Insider, July-September 2005, www.SAPinsideronline.com)

 

 


1 For an introduction to the switch and enhancement framework, see "A New and Improved Approach to SAP Industry Solutions — How the Switch and Enhancement Framework Now Consolidates SAP Industry Solutions with the ERP Core" by Karl Kessler in the July-September 2005 issue of SAP Insider (www.SAPinsideronline.com). [back]

2 For more about the SAP ERP enhancement package strategy, please see "SAP's New ERP Strategy for Developers: 4 Ways to Make the Most of Your SAP ERP System" by Karl Kessler in the July-September 2007 issue of SAP Insider (www.SAPinsideronline.com). [back]

3 The benefits of enhancements greatly outweigh those of modifications, and the enhancement framework covers a lot of cases in which customers want to adapt SAP code to their needs. But there might still be some cases in which modifications are necessary; I will explain in more detail later in this article [back]

4 Conflict resolution transports (CRTs) resolve conflicts that can arise between a support package for SAP ERP and an SAP industry solution or other add-on component. [back]


Thomas Weiss (thomas.weiss@sap.com) has a Ph.D. in analytic philosophy and worked as a professional writer before he joined the SAP NetWeaver Product Management Training team in 2001, where his responsibilities included the e-learning strategy for ABAP. After getting increasingly involved in writing ABAP material himself, he is now a member of the SAP NetWeaver Application Server Product Management team. The enhancement and switch framework has been a topic of primary interest to Thomas for quite some time.

 

 

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ