Adding just one enhancement to an existing SAP application will usually not do the job. But what is the job of an enhancement? Most probably you want to add some change to an existing application, and not just any change, but one that makes a semantic difference. This means you need an enhancement project that contains quite a number of enhancements, and this project, like any other development project, needs a proper design and good organizing. You should never just add an enhancement here and there without careful planning.
In other words, in part 2 of this weblog series I want to explain why in general you will always end up with more enhancements than you might have expected (you find this whole series linked at the bottom of the SDN Wiki page on the Enhancement Framework). Even seemingly tiny enhancements will necessitate other changes. Moreover, you will understand that and how the classic append technology and the new enhancements cooperate very well. So conceptually I make a very abstract point about enhancement projects. To make this plausible I look at the example from weblog 1 from a closer perspective that shows us some more technical details.
Let me resume in short what we have done in weblog 1 and then focus on how this is related to the content of this weblog. In the last weblog you have seen how easy it is to enhance a simple user interface that is built with Web Dynpro for ABAP. We had a table of customers and added an additional column, a button and a detail table as enhancements. The main point was: Modifications are technically part of the objects they modify, while enhancements are objects in their own right. This is why modifications are overwritten in an upgrade, and why you have to re-insert each modification after an upgrade. In contrast, enhancements live a secure life in a package of yours, and are not touched by an upgrade at all.
Provided I convinced you that you benefit more from enhancements than from modifications, you are probably eager to learn more about enhancement technology. And this is what this weblog is about. It is about the fact that enhancements hardly ever come alone and the lessons to be learned from this:
Developing enhancements is different from normal development. In general, you do not add one large enhancement to an application, but many small enhancements. With an enhancement project, you want to achieve some semantic aim. To accomplish this, you usually have to add many different enhancements spread over the different layers and components.
How One Enhancement Implies Other Enhancements
But now let us dive deeply into the details from the last weblogs and let us consider only the additional column we have added as an enhancement in the example and ignore the detail table we have also added. What is so interesting about this additional column? The point I want to emphasize seems trivial: Just adding an additional column as an enhancement does not suffice by itself. Obviously, the new column needs to be typed, it should show some data, and it needs some wiring up, if you want to populate it.
Before we go on with the details I want to put those at ease who are not familiar with the user interface technology we use in this example: In our example we have a Web Dynpro ABAP screen. Still, I do not presuppose any knowledge of Web Dynpro for ABAP, and you can understand the content of this weblog without any experience with this new UI technology. I stay on an intermediate level and I introduce the few Web-Dynpro-related terms I am using.
But now let us go on with the example and just look at the single column we have added as an enhancement. There arises one question: What use is an additional column if no type is provided for it and no data shown in it at runtime? So we need some other changes or enhancements to populate our additional column with some data. Supposing that the UI table is typed with the fields of a database table, we first need a new data element, and next we create an append for the database table by adding the new field freq_flyer. Doing this we use the classic append technology. The classic appends cooperate perfectly with the new enhancements from the Enhancement Framework. How this typing works in detail is shown in the figure below. We add the relevant append to the database table and enhance the table UI-element in the Web Dynpro by using this additional column of the database table as the type of the column in the UI table:
The data for a Web Dynpro View element is held in some container, a so-called context. We have to enhance this context as well as you see in the next figure. I use red color for the enhancements and orange color for appends in this and all other figures:
Of course, this context has to be filled some way or other. This is done by a method in the controller that in turn calls another method that selects the data from the database. Why are there two subsequent methods to do this simple job? Because of the separation of Web Dynpro- and application-logic the Web Dynpro method does not select the data itself from the database, but calls another method that performs this job. What does this layered structure mean for our enhancement project?
It means that both methods have to be adapted: The one method must select an additional field and needs a broader structure as a returning parameter, because additional data for the new column must be retrieved from the database table and handed to the other method. So we must enhance both the implementation of this method and its returning parameter. The other method needs another component for the structure that is used to fill the enhanced node in the Web Dynpro context, because the new column must also be filled with data . Let us have a look at the relevant figure and then explain some more details:
Some details are easy to understand and some need some explanation. I start with the easy ones. You see the enhanced SELECT statement in the method get_scustom_lean that gets the additional data from the database (by the way, it is not possible to insert an enhancement into a statement, but here I only want to emphasize that the SELECT statement is enhanced, no matter how it is done in detail). Once the data is selected by this method it is returned to the other method that inserts the data in the context.
It seems hard to understand at first why the figure shows no changes in the returning-parameter of the method get_scustom_lean. In the same way it might seem strange why the other method is not changed at all. Let me explain why we do not need these changes. In both methods we need to enhance data of the same data type: This type describes a structure that contains all the fields of our UI table as components. One method needs this structure as the line-type of the table it returns, the other method as the line-type of the table it inserts into the Web Dynpro context. The efficient way to enhance both structures with one effort has one presupposition: They must be typed from the very beginning with a Dictionary structure that contains all and only the fields we need in the UI table. This is the structure that is shown on the bottom left. In our example this DDIC structure is used for the relevant typing in the way just described. Under this condition it suffices to add an append to this DDIC type, and both methods will get their structures enhanced automatically as soon as the DDIC type is enhanced. And this is because both the table in the returning parameter of the one method and the table that is inserted into the context have this very DDIC structure as a line type.
Before we express somewhat more concisely what the lesson of this little example is let me add another figure that divides the elements into two groups: Those belonging to the Web Dynpro logic and those that are part of the application logic.
No let us state what this example teaches us:
1. Initially we wanted just one additional field in a Web Dynpro table, and to populate this field with some data, we needed two enhancements in the Web Dynpro Component, another enhancement in the application logic, and two Dictionary appends.
So even in a project that indeed very small we end up with 3 enhancements and 2 Dictionary appends.
2. As a consequence, you should plan your enhancement projects carefully. As you will learn in another weblog, enhancing applications is as easy as anything, in particular there is no need to get a modification key. Still, you should not feel tempted to enhance a SAP application without proper planning and organizing. As you have just seen, even a tiny change implies a couple of other changes. So it is very important that you design an enhancement project as precisely as a development project from the very beginning
3. Not everything in terms of adding elements to SAP objects in new: You still use the known and proven append technology you are familiar with when enhancing DDIC objects like tables and structures. These appends cooperate pretty well with the new enhancements.
In the next weblog I will explain to you how easy it is to enhance the SELECT-method in our example. I will not go into much technical details there, but what I write should just suffice to give you the flavor of this new framework. Moreover I will answer some basic question every potential user of the framework is faced with. You have probably also already asked yourself: What are the presuppositions for enhancing a development object? Can I enhance it everywhere? Does anybody need to provide exits explicitly, or are they given for free? I will present the answers to all these questions from a generic perspective so that after reading the next weblog you will have a better understanding of the possibilities and limitations of the Enhancement Framework.