You have heard about the new Enhancement Packages of SAP ERP 6.0 or that SAP Industry Solutions are now all developed in one system, delivered on one set of DVDs and you just switch on the one you need? Maybe somebody has told you that there is now a more state-of-the-art technology than modifications to adapt SAP software to your customer needs? If so you should read these weblogs to learn more about these different approaches and how the Enhancement- and Switch-Framework the technology behind these use cases empowers them. If you have heard nothing at all about these exciting use cases, this new weblog series should interest you all the more. It puts into context the new Enhancement- and Switch-Framework from the perspective of its three most important use cases:
- Customers can now adapt SAP code to their needs without modifying it.
- All SAP Industry Solutions are now developed and delivered in one system.
- The Enhancement Package strategy of SAP ERP 6.0 provides you a new dimension of choice in getting new functionality.
You will learn both what the Enhancement- and Switch Framework is used for in these use cases and how it is used. In other words, you will both understand the basic benefits of this framework from a business perspective and the basic technological concept from an intermediate technical perspective.
The readers of my weblog series on the Enhancement Framework (find part 1 of the series and links to the other weblogs of this series here) who already know the basic concepts of this powerful framework can probably skip some parts of this new series, but they will still profit to see the framework from a more high-level perspective.
Looking at these use cases you will also understand
- The basic concepts of the Enhancement Framework
- The basic structure of the Switch Framework
- How the Switch- and Enhancement Framework interact.
In part one I will sketch the three uses cases in some more detail, and then present the basic difference between an enhancement and a modification in a very simple example.
Let me now sketch these three use cases in some more detail:
Overview: The Three Use Cases of the Enhancement- and Switch-Framework
1. Enhancements Instead of Modification Technology
What does it mean that you can adapt SAP objects without modifying them? 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.
2. Integrating the SAP Industry Solution into the SAP ERP Core
By means of the new framework SAP can develop most Industry Solutions in one system. This brings a couple of advantages for you as a customer:
You can install the IS you like based on the latest SAP ERP release because you need not wait for Conflict Resolution Packages. The ISs are developed on the latest SAP ERP release. So can use the latest SAP ERP technology in your IS, for example some new features of logistics in the IS Oil and Gas, while before you needed two systems for this: One for the IS and another system with the latest version of SAP ERP. This means that you need fewer systems in your landscape and this in turn means a lower TCO for you. And this is because for the first time you have the freedom to get the Industry Solution of your choice and the latest SAP ERP in one system
Apart from this, by getting it all on one DVD you can now use some functions of another IS in one IS, for example some functions of retail, in Oil and Gas.
3. The Enhancement Package Strategy of SAP ERP 6.0
The new Enhancement Package Strategy of SAP ERP introduces a new dimension of freedom in the world of business software.
In the classic world you could choose whether you wanted to stay on one release or get new functionality. With the new Enhancement Packages you can have all the advantages of staying on one release and still get new functionality. You can get the new functions not by upgrading, but as parts of Enhancement Packages. They provide new features on top of the recent release. For the new features, the import is separated from the activation. Directly after the import your system behavior has not changed at all. 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 can choose: Import only what want and activate only the parts of the imported new functions you are interested in. So you have a variety of choices as to which functions you want to import at which time.
By learning about these use cases you get acquainted with the basic concepts of the underlying Framework: At the end you should know what an enhancement option is and how to enhance a SAP object, what switching means and how it works.
Some words of caution at the beginning. Those who have read my weblogs on the Enhancement-Framework know that this framework has many layers: I explain only the ones that you need for an understanding of the overall functioning. This means that there are many special concepts of the new framework you not learn here. And it means: After reading this weblog series you will understand the power and the opportunities that come with this framework, you will also have some sense of its inherent limits, but you will not be able build your own enhancements and switches right away. This paper is intended to give a sort of middle-distance perspective. You will understand the major use cases and the most important concepts in the way you see the blocks of flats on a satellite picture, but not the windows of the houses.
Enhancements Without Modifications in Some Detail
We start with a very simple example and add new features until you have seen most basic concepts at work.
Once you know, how to enhance a SAP object and how and what to switch you basically know how the new IS and EHP function. They use the same basic mechanisms. So understanding how to enhance an object and how switch enhancements provides you with the basic concepts you need for understanding the other two use cases.
Let us start by considering a very simple use case: Within the classic flight model there is a Web Dynpro ABAP screen delivered as a SAP standard object that shows a list of customers. Let us further assume that the customer needs some more functionality on the screen: He wants to have an additional column that shows if a customer is a frequent flyer and a button that triggers the display of all flights of a particular customer.
With the Enhancement Framework this is quite easy to achieve. Just add the screen elements you want as enhancements (how you do this detail will be explained later). There you are, you add the new elements, and both in the design time editor of the Web Dynpro ABAP editor and at runtime you see them in the right position.
But what is the difference between these enhancements and a normal change of code? You create and add the enhancements as new objects in their own right in packages of their own, that is in your packages. The additional column, the additional table, and the button can enhance a SAP object and still be part of your package. So these objects are yours. And still at runtime they appear in the right position as part of a screen that is a SAP standard object.
How does this work? Your enhancements are merged into the object they enhance at compile time. That has one important consequence: Because this merging is done at compile time processing enhancements does not slow down an application. At runtime your enhancements are already merged with the original code. This way, enhancements have an ideal position:
• They are in your own packages where you can control on them.
• At runtime they behave as if they were part of the application.
To some extent, you can compare an enhancement to a temporary worker. It may do its job at the factory, but still belongs to a temporary employment company. As for the work he does, there is no difference, but from some point of view he is part of the temporary employment agency.
So much for the runtime- and the transport-perspective. But what about the design time tools? I have told you already, that you see the enhancements at design time in the position they occupy at runtime. Still you want to see which objects are part of the SAP code and which are only enhancements. Looking at the properties of an object in the editor, you see that it is an enhancement that belongs to a particular enhancement container that in turn determines the package assignment of an enhancement.
In fact, each enhancement is and has to be part of a container. These containers belong to an intermediate level between these objects and the package. Let us be content here with the fact that in the design time tools you see that some object is an enhancement and can drill down to its package.
But you may ask what is so special about enhancements compared to modifications. At runtime there is no difference between an additional column of a UI view that is an enhancement and one that is a modification. The design time tools also show the modifications at the right position.
The difference lies in the way the modification is technically realized: From technical point of view a modification is part of the object it modifies. This means, of course, that modifications are part of the package they modify. It is this fact that explains all the inconveniences that come with modifications: A modification is a subtenant in a SAP object and far more dependent on the SAP object than enhancements, which are objects of their own and live in a life of their own in packages of their own as is shown in the figure below. The figure below shows you the modifications of our Web Dynpro ABAP table from a transport perspective.
As I have already told you, it is in an upgrade that you see the disadvantages and limitations of modifications most clearly: In a SAP update each SAP object is overwritten, whether this object has changed or not. What does this mean for your modifications? The answer is simple: It is part of the old version of the object, once this gets substituted by the new version, your modifications are gone. Let us have a look at this how it is shown in the next figure. You see the object that is the Web Dynpro ABAP table plus its modifications and the next version of the table.
Now what does happen in the upgrade? The new object substitutes the old one, and all modifications are lost as you can learn from the figure below:
Of course, using the Modification Assistant you can reinsert the modification semi-automatically or manually (depending on the way the change in the SAP objects affects the position of the modification).
But unless you adjust every single modification in a system, it is gone after the upgrade. This is the hard luck of a modification, the poor situation of a subtenant. For you as the owner of modifications this means: You have to touch every single modification after an upgrade, even though none of the objects you have modified may have changed in the upgrade.
In contrast, enhancements are not like subtenants, they have a package of their own. So this makes their live safer in an upgrade. Let us consider this by looking at a case that seems more difficult at first sight. Let us suppose the SAP object that is enhanced changes in the upgrade and is replaced by a version that is different.
What does happen? The new object substitutes the SAP standard object, but this does not affect the enhancements. The upgrade only has an impact on SAP objects. The enhancements are not affected by the transport at all. Looking at the figure below you see that that the new version of the table overwrites the old one (1). And what does happen to the enhancements? All enhancements will survive an upgrade without you having to stir a finger (2 and 3). But what does the runtime perspective look like after an upgrade? The enhancements are just the same merged into the SAP object after an upgrade. (4)
Probably this example still raises some doubts:
As we see, the deletion of one column does not affect the enhancement with the new column frequent flyer. But what if the whole table had vanished in an upgrade or the whole Web Dynpro view? Quite obviously it does not suffice that an enhancement does survive an upgrade in its package. It needs a position in the original object it is attached to, a kind of hook that indicates where the enhancement is merged in at runtime. And what does happen if this hook does no longer exist after the upgrade. What about the enhancement?
The enhancement is then still there as an object of yours, but it is no longer processed at runtime. So even if the hook of the enhancement vanishes the enhancement as a transport object is not affected by this. But this can only be one half of the story. Obviously the customer can not be content if his enhancement exists somewhere happily and untouched, but he wants that an enhancement that is merged in at the right position.
There is a particular tool in the Enhancement Framework to cope with situations like this. In these rare cases where the hook of your enhancement gets lost, you can benefit from an adjustment tool that informs you about the enhancements that are no longer attached to their hook, because the hook has vanished or changed in some way. Just use the transaction SPAU_ENH or access the same tool in the Enhancement Information System in the transaction SE80. This tool informs you which enhancements you have to adjust after an upgrade. Though there are situations in which you have to adjust your enhancements there is a couple of advantages for you in comparison to modifications:
- The enhancements as transport objects are never touched by an upgrade at all. They survive every upgrade as objects in their own right, most probably in a package of their own.
- It is only if the hook of an enhancement changes or vanishes in an upgrade that you have to adjust an enhancement at all.
- The transaction SPAU_ENH informs you about these cases after an upgrade.
- Because the enhancements themselves are still there, you can copy them and to attach them to some other hook in case the hook has vanished.
Summary
Now you should know the three important use cases of the Switch- and Enhancement Framework on a higher level and have some understanding what is the basic advantage of enhancements over classic modification technology: All modifications are part of the object they modify and for this reason overwritten during an upgrade and have to be reapplied automatically, semi-automatically or manually. Enhancements are objects of their own, you own your customer enhancements, they are in your namespace and in your package. So they never get touched by an upgrade. In the cases where the hooks the enhancements are attached to changes or gets lost in an upgrade you get informed about this by a tool and can easily adjust the code.
In the next weblogs you will learn some basic facts about where and how you can enhance a SAP application.
Learn about the exciting opportunities that the three most important use cases of the Enhancement- and Switch Framework offer to you. In part 1 of this weblog series you get to know these use cases from a high level perspective: Enhancements instead of modifications, all SAP Industry solutions developed in one system, and the Enhancement Packages of SAP ERP 6.0. And you will understand the basic advantage of enhancements over modifications in some detail.
No comments:
Post a Comment