SAP Controls Technology Part 1
Controls Technology – What Every ABAP Developer Needs to Know……
In this months blog I will begin to take a look at the SAP Controls Technology and how we can use it in our development.
Lets start out by defining a control of the Controls Technology. Controls are independent binary software components that are installed on a local PC (the presentation server). When you install a local SAP GUI on your machine, the system also installs the appropriate controls. The SAP GUI functions as a container for controls at the front-end. Controls can either replace or work alongside classical ABAP components, and can either be ActiveX controls or JavaBeans.
Typical examples of Controls Technology controls are:
- Picture controls, which allow you to display any picture (.BMP, .JPG, or .GIF format) on the SAP R/3 screen
- Tree controls, which are used to display and work with a tree structure
- Text-edit controls, which allow you to implement editors for viewing and maintaining texts
- HTML viewer controls, which allow you to display HTML pages and graphics in your transactions
Lets take a look at the transaction SE80 below
Figure 1 above shows the Object Navigator(SE80), which is used to display the contents of an ABAP program. Tree and textedit controls were used from the Controls Technology to design this interface. On the left, you can see the tree control, which allows you to navigate quickly through the various components of a program. On the right is the textedit control, which allows you to implement the functionality that a typical ABAP Editor provides. Starting as far back as Release 4.5, these types of Controls Technology controls came with the SAP GUI, and you could access them through ABAP Object classes.
What does an ABAP developer need to know to take advantage of the Controls Technology, and what’s the best way to get started? That’s what this blog series will address. I am assuming the reader has practical ABAP experience and a basic understanding of ABAP Objects.
Controls Technology: Some Brief Background
Let’s review some of the technical aspects of controls technology:
-The SAP Control Framework
-The Automation Queue, and the issues surrounding “flushing” it
-Event handling
-Error handling
Including Controls Technology controls on the front-end establishes a client/server relationship between the application server and the controls on the presentation server.
The application server (the automation client) drives the controls (automation server) at the presentation server by calling functions (methods) that they provide. Take a look at the diagram below.
The application logic runs on the application server. The application server transfers methods to the front-end by means of a Remote Function Call (RFC) and then executes them. The communication between the control and the application logic (on the application server) is administered by the SAP Control Framework
ABAP Objects are used to implement controls in programs. Each control has a global “wrapper” class in ABAP Objects. The table below summarizes the most common controls and their respective wrapper classes.
In order to work with Controls Technology controls on your screen, you simply create objects of these wrapper classes, call their methods, and react on their events.
The real “art” of controls programming lies in selecting the control that best fulfills your requirements and then calling the appropriate methods that its wrapper class provides.
Each wrapper class provides us with methods to modify the control properties, and thus influence the behavior of the control. For example, the class CL_GUI_PICTURE_CONTROL provides the method load_picture_from_url, which enables us to display a picture on the screen.
The user of an application program triggers control events by performing specific actions (for example, double-clicking). You can decide which events you want to catch in your ABAP program and then register these events for the relevant control. For example, the class CL_GUI_SIMPLE_TREE provides us with the NODE_DOUBLE_CLICK event to notify the program that a tree node has been doubleclicked.
A triggered event is then transferred from the SAP GUI to the application server. In response to this event, you can then influence the behavior of the control with additional method calls. For example, when the user tries to expand a tree node by clicking or double-clicking on it, you can add further nodes to the tree by calling the method CL_GUI_SIMPLE_TREE=>add_nodes.
Navigating Through the Control Classes in the Controls Technology
All controls in the Controls Technology are encapsulated in a wrapper class. A wrapper class is a global ABAP Objects class that encapsulates the complete functionality of the control, making it easy for developers to reuse the functions that they provide. Before coding, it’s always a good idea to become familiarized with the structure of the wrapper class.
To do this you could use SE24 (Class Editor), or an easier tool would be SE80 (the Object Navigator).
1. Enter transaction code SE80 (Object Navigator) in the command field.
2. Enter the name of the class in the “Class” input field on the Object Navigator initial screen and choose “Display.”
3. A tree structure appears for the class you have chosen.
You can see from the figure below, that I have called up the “CL_GUI_SIMPLE_TREE” wrapper class. You can see the expanded wrapper class and its sub-objects. I clicked on the “Methods” node, and then double-clicked on “NODE_SET_TEXT” to view the source code of that particular method.
You can click on the root node to view all the sub-objects of the wrapper class, and then go further and expand the child nodes to view the list of items in that particular category.
Typically, the Object Navigator provides you with the following information:
Superclasses: Under the superclasses category, you will find the complete inheritance hierarchy, which lets you see all the classes from which the control has been derived — e.g., the class CL_GUI_SIMPLE_TREE is derived from the class CL_TREE_CONTROL_BASE, which is further derived from the class CL_GUI_CONTROL, and so on. The interface of the class CL_GUI_SIMPLE_TREE also includes the public methods of the classes CL_TREE_CONTROL_BASE and CL_GUI_CONTROL.
Attributes: This is the set of data that the class encapsulates. Attributes may be properties of a control, establishing things like the shape, size, or position of an element on the screen. They may be static (defined for all objects), private, or public. Event IDs of specific events (e.g., click, double-click) are also included in attributes. For example, the class CL_GUI_SIMPLE_TREE has the attributes WS_VISIBLE and EVENTID_NODE_DOUBLE_CLICK.
Methods: These are operations that can be performed on a control. There may be methods to change the appearance of a control, to set values of its attributes, etc. One special method, the constructor, allows you to create (or construct, as its name implies) objects. For example, class CL_GUI_SIMPLE_TREE gives us methods like GET_WIDTH, COLLAPSE_ALL_NODES, and so on.
Events: The events that are listed by the Object Navigator tell you what specific events the control may be able to respond to. All events have a meaningful name. The class CL_GUI_SIMPLE_TREE, for example, has events RIGHT_CLICK and NODE_DOUBLE_CLICK.
Containers in Controls Technology – Linking Controls with Containers
Every control that needs to be displayed on the screen must be linked to a container, which is linked to a screen area. A container in the Controls Technology has the following features:
-It provides a physical area where the controls can be displayed.
-It manages controls in a logical collection.
-It behaves like the parent of the control within it.
-It can contain other controls (for example, a tree control, a picture control, an HTML viewer control, and so on). Remember, a container is also a control inside the Controls Technology.
-All controls in the Controls Technology live in a container. (The lifetime of a container should always be greater than the lifetime of the controls within it.)
-If a parent is not visible, its children are also not visible.
-The default size of a control is the same as the size of its container. It can be changed at the time the control is instantiated.
-Containers can be nested, thus you can place one container within another container.
SAP provides you with five kinds of containers for use in the Control Technology. The table below lists the SAP-provided containers, along with their wrapper classes.
Containers are instances of special global control classes. Each kind of container is wrapped in a separate class of ABAP Objects. Like other control classes of the Control Technology, container classes are derived from the class CL_GUI_CONTROL.
You choose the container that best suits the type of functionality you would like to implement. Linking a control to a container on a screen involves a few easy steps. Suppose we want to place a tree control on the screen. In order to do this, we must first create a custom container, then link it to accommodate the tree control. Take a look at the following steps:
1. Create a screen on which to place the control. Create a screen area CONT for your custom container control using the Screen Painter.
2. We then need to define a reference variable for the container in which to place our control:
DATA: mycontainer TYPE REF TO cl_gui_custom_container.
and then define a reference variable for the tree control:
DATA: mytree TYPE REF TO cl_gui_simple_tree.
3. The classes of containers provide constructors for creating the container objects. The constructors are called by using the CREATE OBJECT statement as follows:
CREATE OBJECT mycontainer
EXPORTING
container_name = ‘CONT’
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2
create_error = 3
lifetime_error = 4
lifetime_dynpro_dynpro_link = 5.
The above code creates a container for one tree control, and the container is linked to our control with the name CONT on the dynpro (exporting parameter
container_name).
4. Finally, we create a tree control object and place it in the container that we have just defined. We use the constructor that the class CL_GUI_SIMPLE_TREE provides us:
CREATE OBJECT mytree
EXPORTING
parent = mycontainer
EXCEPTIONS
cntl_error = 1
cntl_system_error = 2
create_error = 3
lifetime_error = 4
lifetime_dynpro_dynpro_link = 5.
We have successfully created a screen, added a customer container screen control, created an object for the controls container referencing the screen area, and finally created an object for the tree control and linked it back to the container.
That was a brief overview of the Controls Technology Framework. In the next blog we can look closer at the Automation Controller, and Automation Queue.
If you enjoyed this blog on the Controls Technology, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Please visit our FACEBOOK page and LIKE US to be be notified of new white papers, SAP news additions to this blog.
The New Enhancement Framework – Part 5
The structure of the Enhancement Framework
No matter if you create an enhancement point or a BAdI as an enhancement option provider, or if you implement an existing enhancement option (be it implicit or explicit), what you create must fit into the structure of the Enhancement Framework in a way that enables you to collect and organize the enhancement options and their counterparts on the implementation side. This means that the explicit enhancement options and all enhancement implementation elements (enhancements) have to be part of containers, which also serve as transport objects.
In this final part of the blog, I will explain what these containers are and how they are structured. At the end of it, you should know all you need about organizing enhancement options and enhancements.
Enhancement Framework Spots & Implementations
Option providers and implementers must assign all explicit enhancement options (i.e., BAdIs and source code plug-ins) and all enhancement implementation elements, respectively, to containers. Explicit enhancement options must be assigned to (simple) enhancement spots, enhancement implementation elements must be assigned to (simple) enhancement implementations, each of which can be grouped into composite enhancement spots or composite enhancement implementations, respectively. These containers not only serve to manage your enhancements and enhancement options and keep them organized, but also serve as transport objects. Lets define these a little further…
What do we mean by simple? Composite? Its easy, simple signifies that it is an individual enhancement spot or enhancement implementation as opposed to a composite, which is a grouping related enhancements spots or implementations.
(Simple) enhancement spots and (simple) implementation elements
You must create an explicit enhancement option within a (simple) enhancement spot. A (simple) enhancement spot can contain many enhancement options, while an enhancement option is uniquely assigned to one (simple) enhancement spot. So its a one to many relationship.
There are rules…A (simple) enhancement spot can only contain enhancement options of the same type; that is, a spot that contains enhancement options for source code plug-ins cannot also contain BAdIs.
You must create an enhancement implementation element within a (simple) enhancement implementation. A (simple) enhancement implementation can contain many enhancement implementation elements, while an enhancement implementation element is uniquely assigned to one (simple) enhancement implementation. As with (simple) enhancement spots, a (simple) enhancement implementation can only contain enhancement implementation elements of the same type. More rules…beyond this. a (simple) enhancement implementation containing source code plug-ins can contain only source code plug-ins enhancing one report or additional methods and additional attributes enhancing one class. Class enhancements in one enhancement implementation must belong to one class, function group enhancements to one function group, and Web Dynpro enhancements to one Web Dynpro component…etc…etc
Composite enhancement spots and composite enhancement implementations
Sometimes there is the need to put all enhancements of a particular project in a single traceable bucket. One of the main reasons for enhancement spots and enhancement implementations is to enable you to put entities semantically belonging together, (because they are all needed to solve the requirement together), in one basket. But, as I just described, (simple) enhancement spots and implementations can only contain options or elements of the same type. So what do you do when you need to put all of the enhancements of a particular project, which are bound to be of different types, in a single container? There is another type of container for this, enter Composites.
Similar to composite enhancement spots, composite enhancement implementations group related (simple) enhancement implementations, which can contain enhancement implementation elements of the same or different types. Like composite enhancement spots, composite enhancement implementations can only contain (simple) enhancement implementations directly, not enhancement implementation elements, but they can be nested.
Lets recap…and then see how this all fits together.
So there are four new transport objects in the new Enhancement Framework:
- (Simple) enhancement spots can contain explicit enhancement options of the same type (i.e., BAdIs).
- (Simple) enhancement implementations can contain enhancement implementation elements that are of the same type and implement enhancement options in the same development object.
- Composite enhancement spots can contain (simple) enhancement spots of the same or different type and other composite enhancement spots.
- Composite enhancement implementations can contain (simple) enhancement implementations of the same or different type and other composite enhancement spots.
How it all fits together..
Let’s now look at all these objects of the Enhancement Framework and the way they are assigned to each other, the picture below summarizes the relationships between all of these objects.
One enhancement spot can contain many enhancement options, while an enhancement option is uniquely assigned to a spot. The same applies in concept to the relation between simple enhancement implementations and the enhancement implementation elements.
So it follows then the simple containers on both the definition and implementation side can only contain elements of the same type: A spot that contains BAdIs cannot contain enhancement points/sections and vice versa.
The composite containers are not affected by this restriction. A composite enhancement spot can contain simple enhancement spots that in turn contain enhancement options of different types. One composite enhancement spot can contain many (simple) enhancement spots, while a (simple) enhancement spot uniquely belongs to a composite enhancement spot. Composite spots can be nested.
There are composite enhancement spots and composite enhancement implementations. And this makes perfect sense– All the stuff on the left hand side (the definition side) are hooks created by the enhancement option providers, while those on the right hand side (the implementation side) are used by the implementers. This is me and you.
Now that you have a solid understanding of the concepts behind the new Enhancement Framework, lets look at a final point for consideration and a best practice.
Consider: One enhancement usually will require other enhancements
You enhance a SAP development object to achieve some aim on the semantic level. Usually this aim cannot be reached by one enhancement only. For example, suppose you have enhanced a SELECT statement by an additional field. First, you need to enhance the structure that holds the result set. And most probably the new field should do something. So you probably have to enhance the interfaces of the relevant methods that work with the new data.
You probably also have to add some additional edits or validations because the additional data needs to be validated and/or derived. And after all you want to present some additional value in the user interface. That means you have to add an additional field to your user interface and to transport the new value there. In this way, enhancements are sociable — they hardly ever come alone.
So the very nature of enhancement development leads to a larger number of enhancements. And a larger number of objects need to be organized. In addition, there are the well-know reasons that require some structuring of every software project–Enhancement options may be created and implemented by a team, or even multiple teams, and be part of different projects. And you need to silo the enhancements in a way that mirrors the team and project structure.
So there are plenty of reasons why you will have many enhancements and why these many objects need some organization. This is why the Enhancement Framework not only provides containers but also enforces a container structure on the different objects. Containers enable you to organize your enhancements and explicit enhancement options according to type, project, content-related matters, and other sorting criteria, and these containers also serve as transport objects.
Best Practice: Several small enhancements are better than one large enhancement
If you keep your code small instead of, for example, replacing an entire program, the chance increases that they will create less work in an upgrade. Remember that one of the promises of enhancements is that they can survive an upgrade without requiring a lot of additional work.
The smaller a portion of code replaced by an enhancement is, the smaller is the possibility that the original code will be changed or deleted by SAP in an upgrade. So a number of small enhancements are less susceptible to changes of the enhanced object than one very large enhancement — there are less chances for dependencies that could cause problems after an upgrade.
Final thoughts..
The basic idea of the enhancement framework is to have a technology that serves the same aim and fulfills the same functions as modifications, without any of the drawbacks that are inherent to the very concept of a modification — a modification is part of the object it modifies, which means you have to reinsert modifications of SAP objects after every upgrade. In other words, modifications cause quite a bit of work. In contrast, enhancements are transportable objects in their own right that you develop within your own namespace. For this very reason, enhancements cause far less work during an upgrade.
This is a powerful technology and I cannot emphasize the importance of planning before you use the Enhancement Framework to adapt your SAP system.
To read part 1 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 1.
To read part 2 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 2.
To read part 3 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 3.
To read part 4 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 4.
If you enjoyed this blog on the Enhancement Framework, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Please visit our FACEBOOK page and LIKE US to be be notified of new white papers, SAP news additions to this blog.
The New Enhancement Framework – Part 4
OK…In this Blog let’s now take a look at the technologies offered by the Enhancement Framework.
The Enhancement Framework Technologies
Because you can only attach an enhancement where there is a hook, it is important to know the different kinds of enhancement options that are available.
In addition to the new kernel-based BAdI, there are many other types of enhancement options that are part of the new Enhancement Framework. You implement these enhancements using the Enhancement Framework tools, which are integrated into the ABAP Workbench — you simply switch to the enhancement mode directly within the ABAP Workbench tool that you are using, in the same way that you switch to the change mode. (see below)
Class Enhancements:
You can add methods to a class, or you can replace the code of a method entirely using an overwrite method. Can you see the latitude this gives you? You can completely change how a method delivered by SAP works.
You can also add optional parameters to existing methods (added parameters must be optional so that the enhancement does not invalidate the code).
You can add pre and post methods to existing methods.A pre method is executed before the method to which it belongs and has a context of its own. This means that you have no access to the local variables of the method. The same applies analogously to post methods.
Using overwrite methods in conjunction with optional parameters gives developers a lot of freedom. The only part of a method that cannot be changed using the Enhancement Framework is the signature of a method specifying the mandatory parameters.
Function Group Enhancements:
You can enhance the interface of a function module through the use of additional parameters. As with methods, you can add only optional parameters — but not mandatory parameters — because an enhancement must not invalidate the code it enhances.
Source Code Enhancements:
There are two types of source code enhancement options — enhancement points and enhancement sections. Enhancement points and enhancement sections are positions defined in the source code where you can attach source code plug-ins that enhance the code. There is one notable difference between enhancement points and enhancement sections: Source code plug-ins that are inserted at an enhancement point are executed in addition to the existing source code, while source code plugins inserted at an enhancement section replace the code of the section.
Given these enhancement sections, not only you can add something to the original code, but you can also replace sections if they are so flagged by the developer of the unit.
WARNING
When the Enhancement-Section is implemented, only the implementation gets executed and the original code doesn’t get executed.. Because of this, there can be only one active implementation of an Enhancement-Section.
On the other hand, there can be multiple active implementations of an Enhancement-Point, in which case all the implementations will be executed with no guarantee in the order of execution
Web Dynpro Enhancements:
The Web Dynpro ABAP user interface (UI) technology offers a variety of enhancement options. You can enhance a Web Dynpro view by adding UI elements to it — either new parts to existing elements (e.g., a new column to an existing table) or completely new elements (e.g., a new button). Many UI elements only make sense if they are “Event-able” i.e… a new button should trigger some action, a new table should show some data, and a new input field should transport data to the business layer, for example.
The Web Dynpro enhancements provided by the Enhancement Framework enable you to easily add such functionality.
Some examples of enhancements you can add:
- Add methods in the view or component controller and enhance existing ones using pre and post exits that are executed before or after the respective method is processed
- Add actions in the view controller and events in the component controller that trigger new methods if they subscribe to these new actions and events
- Add plugs that enable you to create new navigation paths in the view controller.
- Add attributes in the view or component controller to hold data.
- Add nodes and attributes to existing nodes to hold the data for new UI elements.
The New BAdI:
The new BAdI is now part of the Enhancement Framework. A BAdI is an object-oriented enhancement option, a hook for an object plug-in, and this way the most sophisticated enhancement type.
When defining a BAdI, you determine its interface — that is, which methods the BAdI offers. BAdI implementations are classes that implement the BAdI interface. Typically, these implementations are created in another development layer; for example, objects owned by the customer that are in the customer namespace, while the BAdI definition and the call of the BAdI methods belong to the SAP namespace. Calling a BAdI method is, in many respects, like a dynamic method call with a specified interface. Which methods are actually called is determined by the active BAdI implementation.
The old classic-BADI’s are implemented purely at the ABAP Workbench level; that is, both the definition and implementation are realized as workbench repository objects (global classes and interfaces)
The Enhancement Framework introduces a new BAdI with several advantages over the classic BAdI introduced with SAP R/3 4.6 — although the basic functionality has not changed. Due to its integration into the kernel, the new BAdI has taken a big leap in performance and is directly supported by the ABAP language through two new commands GET BADI and CALL BADI, which make for an easier syntax when you create a BAdI instance and later call BAdI methods. There is also advanced filter support, which provides for more flexibility.
Now that you have a solid understanding of the basic concept behind the Enhancement Framework technologies offered, let’s take a closer look at the enhancement options, which are the key to understanding the functionality of the framework.
Implicit and Explicit Enhancement Framework Options:
Some things in life are free, and, of course, some are not. This is also true for enhancement options, which come in two flavors: implicit enhancement options, which are provided by the framework, and explicit enhancement options, which must be provided by the developer back at SAP Waldorf.
Let’s look at these two enhancement option types in some more detail:
Implicit enhancement framework options exist in a unit without the SAP developer of the delivered unit having to lift a finger. There is no need to do anything explicitly — these are the ones we get for free. Implicit enhancement options are included with programs, global classes, function modules, and includes. The SAP developer back in Germany of a program or class need not make any preparations to make these compilation units enhanceable for me and you. This is done by the framework. Implicit enhancements comprise class enhancements, function group enhancements, Web Dynpro enhancements, and predefined enhancement points at the end of a report, a function module, an include, or a structure, and at the beginning and the end of a method.
Explicit enhancement framework options require some work on the part of the SAP developer back at SAP HQ, who must explicitly insert them in the compilation unit to make it enhanceable by somebody else (you & me). Only if the developer of a unit has preconceived the respective enhancement option’s need or value, can the customer do enhancements there later. Source code plug-ins and BAdIs are explicit enhancement options. An SAP developer can, for example, insert an option for a source code enhancement with the commands ENHANCEMENT-POINT and ENHANCEMENT-SECTION, so that somebody else(you & me) can insert a source code plug-in. BAdIs are a bit more complex. They must first create a BAdI in the BAdI Builder (integrated into transaction SE80 or SE18), provide an instance of this BAdI in the source code, and can call a method of this BAdI. We can then implement using (SE19).
Implementing and defining enhancement options: two different roles
Not only is defining and implementing an enhancement option technically different, there are two roles involved in enhancement options — somebody defines or provides the enhancement option (we will call them the option provider) and somebody uses the option to implement an enhancement (we will call them the option implementer).
Lets define these roles in more detail, as the final blog will use the terms and I want to be sure you clearly see the delineation of the roles.
The option provider creates an enhancement option that provides the hook to which others can attach an enhancement. In general, the option provider is the SAP developer, back in Germany, of an object who anticipates that a customer developer like us might want to add some code at a particular point to adapt the object to his or her own needs, and inserts an explicit enhancement option for this purpose. For example, perhaps in the program the SAP developer may see a need to select more columns than normally done, so they add an option for a source code plug-in to the SELECT statement. Since it is not possible to insert an enhancement point within a statement, they instead must mark the whole SELECT statement as an enhancement section, allowing the implementation contained in the source code plug-in to replace this section of code completely.
The option implementer is a developer like you and me who uses the enhancement option to implement an enhancement. An enhancement option all by itself, that is, without an implementation, does not do a lot when processed; in fact, it has no effect at all. It is a hook to which nothing is attached. So somebody needs to implement it if some work should be done here.
The implementer doesn’t need care about the details of an enhancement option, but does need to know how to use it. You might compare this to somebody who uses a service class; he or she only needs to know the public methods of the class or perhaps only the respective interface of interest, not what’s actually inside of the class. A typical implementer is an SAP customer who wants to add some functionality, and above all, wants to do this without modifying the source code delivered by SAP.
By now I am hoping you can see and appreciate the benefits this new technology brings to the table for us as developers when solving specific adaptation requirements at our customer sites.
Some of the benefits are:
- All enhancement technologies are now under a single roof of Enhancement Framework, and integrated into the ABAP workbench. Result: Enhancement is easily manageable.
- The Enhancement Framework can be switched using Switch Framework through package assignment.
- With new enhancement technologies (like Source Code, Function & Class enhancements), the options to enhance standard SAP code have increased tremendously. This cuts down on the need to do Core-mod, which requires more effort than enhancement
- Kernel-BAdi’s are much faster compared to the old classic-BADI’s
- Implementing classes of Kernel-BADI’s are re-usable through inheritance
One final word — “With great power comes great responsibility”!
So, PLEASE choose the options wisely. My best-practice recommendation for the order in which the enhancement options should be considered and used is as follows:
- Exit Forms
- SMOD/CMOD
- Use a BADI; if there is no BADI to suite your need then….
- Try to solve it using Explicit Source code, Function and Class enhancements;
- Implicit Source code enhancement should be the last option to choose as it is essentially a changing SAP code.
The final blog installment, will further refine your understanding and give you a set of tips and rules to follow when using the enhancement framework.
This is a powerful technology and I cannot emphasize the importance of planning before you use the Enhancement Framework to adapt your SAP system.
To read part 1 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 1.
To read part 2 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 2.
To read part 3 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 3.
If you enjoyed this blog on the Enhancement Framework, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Please visit our FACEBOOK page and LIKE US to be be notified of new white papers, SAP news additions to this blog.
The New Enhancement Framework – Part 3
OK, in Part 3 of this blog, let’s take a deeper look at the advantages of using enhancements in the New Enhancement Framework.
Advantages of the Enhancement Framework
In all the respects, enhancements are more powerful than modifications, even given all the modification support that transaction SPAU offers. The reason is due to an important difference between an enhancement and a modification that stems from the conceptual difference between the two technologies.
Lets quickly review….
Modifications are part of the unit they modify. This is why modifications are first overwritten during an upgrade. As you have already learned, if you change objects that belong to the SAP namespace, these objects are replaced during an upgrade.
Enhancements are objects in their own right. If you, as a customer, write an enhancement, it belongs to your namespace, not to that of SAP. As a matter of fact, it belongs to a package of yours and is your transport object: Customer enhancements are customer objects. The fact that enhancements are objects in their own right has a few important consequences. It is possible to:
- Transport enhancements separately from the compilation unit they enhance
- Keep or merge enhancements from developments in parallel or subsequent systems
- Group, or even nest, these objects, so that developers can easily view the available enhancement possibilities
- Attach documentation to these objects, so that additional information about particular enhancements is readily accessible without cluttering the source code
- Track who made which changes to what objects
Past SAP releases have offered enhancement technologies such as appends, includes, customer exits, and BAdIs. The Enhancement Framework is intended to integrate these technologies, improve upon them, and add some new ones to address recent developments such as Web Dynpro.
SAP has developed this framework to fully take advantage of all the opportunities enhancements offer.
The Enhancement Framework concept:
At the core of the Enhancement Framework is the concept of an enhancement. The basic idea might at first sound a bit confusing: Making an enhancement is like modifying an object without a modification. While an enhancement behaves in many respects like a modification, it is not a modification, and hence has none of the drawbacks of modification. We can actually Enhance objects without modifying them
So how do enhancements using the enhancement framework without modifications work? At some positions of a development object (i.e. code, parameters, forms, methods…etc ) you can enhance the object. These positions are called enhancement options. Such an option is like a hook for an enhancement. It is where you can attach the enhancement or, to use the correct full term, the enhancement implementation element. By using this predefined hook, you do not modify the compilation unit that you are enhancing. The implementations you add via these hooks are
processed at the appropriate position in the unit at run-time, but as transport objects, they are objects in their own right and can, for example, can belong to
different package.
Compare the enhancement technology to a wall storage unit system, say from Rubbermaid. I have one of these in my garage. These storage systems typically allow you to insert a variety of elements at various positions without drilling holes in wall unit. At each position you can insert a element that holds a bike, or a garden hose, or even a cabinet; the available positions are where hooks have been provided by the manufacturer. Different positions may offer different kinds of hooks, and each hook type fits exactly one kind of element that can be inserted there. Once you have attached an element, a shelf for example, it seems as if the element is really part of the wall unit, but in fact it is only attached to the parts of the wall unit by the hooks. You haven’t really changed the delivered wall unit, you enhanced it. The element you used is its own object in its own right.
In a similar way, the enhancements look and behave as if they were part of the unit to which they are attached. They are processed at the point where they are inserted, but, as a matter of fact, they belong to a unit of their own. The different types of wall storage unit elements described in our comparison correspond to different types of enhancements you can use in SAP.
It depends on the type of the enhancement option, on what kind of enhancement you can insert there. There are, for example, options for adding a source code plug-ins, an additional method to a global class, or screen elements to a Web Dynpro component, to name a few. This means that you can’t enhance Repository objects anywhere that you like — you can insert an enhancement only where there is an enhancement option. As a result of this separation between the enhancement definition and the implementation, enhancements are processed at the appropriate position in the source code unit, but they themselves are not part of the unit.
This structure allows you to adapt an object without making a modification — the only change to the source code is the insertion of the “hooks” to which the actual enhancements are attached. In contrast to modifications, customer enhancements are in the customer namespace, which means that they are not overwritten by an upgrade.
So, at the center of the Enhancement Framework there is a simple structure along with some basic concepts….
Enhancement options are hooks for enhancements. Since they define the possibility to enhance an ABAP Repository object, they reside on the definition side of the framework.
Enhancement implementation elements are attached to those hooks. Since they actually implement the changes, they reside on the implementation side of the framework.
The enhancement framework is intended to unify and standardize all the previous enhancement technologies and is naturally quite complex, but as you can see, its basic structure is extremely simple. We have hooks we hang elements on…
Now I know your are chomping at the bit, so in the next part of this Blog we will a look at the individual technologies offered by the Enhancement Framework. I will go into each one in detail with some pictures to help drive home your understanding. But please do not run out and start enhancing your system. The final blog installments after the next, will further refine your understanding and give you a set of tips and rules to follow when using the enhancement framework.
This is a powerful technology and I can not emphasize the importance of planning before you use the Enhancement Framework to adapt your SAP system.
To read part 1 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 1.
To read part 2 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 2.
If you enjoyed this blog on the Enhancement Framework, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
Please visit our FACEBOOK page and LIKE US to be be notified of new white papers, SAP news additions to this blog.
The New Enhancement Framework – Part 2
OK, in Part 2 of this blog, let’s take a deeper look at the limits of modifications to help gain an understanding of the advantages of using enhancements in the New Enhancement Framework.
Modifications vs. Enhancement Framework
Lets first get clear on what a MODIFICATION is…..
A modification means a change in SAP source code; that is, you add to, delete, or replace the source code delivered by SAP. Obviously, this leads to some drawbacks when you upgrade or patch your SAP system. In an upgrade, all SAP programs are replaced by new versions, whether they have changed or not. What does this mean for your modifications? Even if the SAP-supplied source code of the program is the same as it was before the upgrade, your modifications are effectively removed from the program after the upgrade.
SAP offers some support to help you reinsert your modifications after an upgrade. For instance, there is the modification adjustment transaction SPAU that supports many, but not all, types of objects. This transaction will show you a list of the parts of source code that have changed with the upgrade, and enables you to reinsert your custom code. How easy it is to reinsert your modification depends on whether the object you had modified has changed during the upgrade.
For those of you reading this that are not familiar with the upgrade process, let me illustrate with an example. Lets say you modified a method return_agent in a program me_assign_agents. What happens when you upgrade? Well, first the version of the program me_assign_agents is replaced with a new version from the upgrade. SAP does not concern itself at this point on whether not you modified a method in the program, it just does a complete replace. Take a look at figure 1 below.
Figure 1
In contrast to enhancements in the Enhancement Framework, modifications are physically part of the object they modify. This means that every single modification gets lost in an upgrade and needs to be re-inserted even in cases where the underlying SAP object has not changed at all! The ease in which you are able to re-insert your modification depends on whether the method containing your modifications was changed.
- If the method return_agent was changed in the upgrade, the SAP system cannot know, on its own, the position of your modification in the new version of this method. So you have to insert it again, semi-automatically. That is, you have to tell the Modification Assistant where to reinsert the modification.
- If the method return_agent is the same after the upgrade, the situation is easier to handle. In this case, you can just click on a button in transaction SPAU and your modification is automatically inserted into the new version of the program.
While you can adjust many modifications automatically or semi-automatically, there are some situations where you will have to reinsert modifications manually. In many cases, transaction SPAU can serve as a guide of which modifications you even have to consider and is a useful tool to reinsert them, but you still may have to go into the modified programs to locate the insertion point yourself.
Main Limitations of not using the Enhancement Framework
Let’s now take a look at the main limitations of using modifications instead of the Enhancement Framework:
- In general, you have to adjust all modifications after an upgrade. Otherwise your modifications would be gone after the upgrade. That means every modification causes work during an upgrade, even if the modified object is not changed in the next release.
- You have to adjust some modifications manually. The more complex the modifications get, the more difficult it is to manage or even keep the modifications.
- You cannot arrange modifications independently. Modifications can’t be grouped, nested, or organized with a structure of their own. In transaction SPAU, all modifications are shown at the same level. This is because modifications are not objects of their own — modifications are always part of the object they modify. Enhancements in the New Enhancement Framework, are discrete repository objects.
- You cannot attach documentation to modifications. Of course, you can document your modifications directly in the source code, but documentation attached to the source code itself would be ideal.
- There is no easy way to track modification developers. If you want to patch some part of a modification, it is always useful to know the original developer. However, it is often difficult to keep track of the different developers of modifications. Transaction SPAU offers only limited multiple user support. Starting with SAP Web Application Server (AS) 6.10, all developers who modify an object are logged, but it’s not possible to distill from the log data who modified which part of the object.
To summarize, the capability to modify SAP programs to meet your needs offers you significant flexibility, but it always generates additional work during an upgrade, even with the support of transaction SPAU. It is not possible to merge or keep modifications from different developments of the same object, nor is it possible to group and document modifications in the system.
In the next part of this Blog series, I will walk us through the main advantages of the New Enhancement Framework. To read part 1 of this series on the Enhancement Framework, use the following link. The New Enhancement Framework – Part 1.
If you enjoyed this blog on the Enhancement Framework, please click on the link below and sign up for our newsletter. We deliver relevant SAP Technical tips & tricks and current news right to your inbox!
The New Enhancement Framework – Part 1
This month’s Blog will begin a look into the NEW Enhancement Framework offered in SAP NetWeaver 7.0 (formerly 2004s).
SAP provides a large set of customizing options enabling SAP customers to adapt SAP programs to their needs. Customization alone, however, cannot always fulfill all customers’ requests for individual adjustments or enhancements to meet specific requirements. In such cases, programmers can enhance or change the standard SAP functionality by modifying the ABAP source code of the underlying development objects. This provision to modify standard capability provides a major advantage of SAP systems over other ERP systems.
Up to now, there have been two methods available for meeting SAP software adaptation needs, where IMG customization alone was not a solution:
- Modifications to SAP development objects either with or without the support of the Modification Assistant
- Enhancements to SAP development objects at predefined locations in the source code using customer exits, appends, includes, and as of SAP R/3 4.6, Business Add-Ins (BAdIs)
SAP NetWeaver 7.0 (formerly 2004s) offers the new Enhancement Framework that not only is intended to unify the modification and classic enhancement techniques, but also offers you almost the same flexibility as modifications without the limitations of modifications. The new Enhancement Framework, which is integrated directly into the ABAP Workbench, enables you to change and enhance the SAP source code without modifying it. This means no REPAIRS!
Why is this good news for you and me? Well first, it means no more getting permission for repairing an object as well as no more repair keys! Please do not misread this as wholesale permission to go out and enhance the system thoughtlessly! You will see in later posts that you have to give some thought to how you structure your enhancements because what you create must fit into the structure of the Enhancement Framework that enables you to organize the enhancement options and their counterparts on the implementation side. This means that the explicit enhancement options and all enhancement implementation elements (enhancements) have to be part of particular containers, which also serve as transport objects.
The second reason this is good news is because the new Enhancement Framework significantly reduces the number of adjustments necessary after an upgrade because your enhancements survive the upgrade. With modifications, the changes are overwritten by the upgrade and must be reapplied. With the new enhancement approach, some adjustments still may be necessary if, for example, the upgrade changes the enhanced object in a way that is incompatible with the enhancements, but the reduced number of adjustment leads to a strong overall reduction in your total cost of ownership (TOC).
In the next post I will look deeper into what the limitations are of the current modification concept. Although current SAP modification tools facilitate the handling of modifications with flexibility, you pay for this flexibility with some problems that are inherent in the very concept of a modification.
If you enjoyed this, please click on the link below and sign up for our newsletter.
The New Frontend ABAP Editor
This month’s Blog will focus on the NEW ABAP Front-End Editor. While I touched on some of the cool new features in my debugger blog, I will go into much more depth in this study.
Today developers are increasingly making use of modeling in ABAP development to build programs without having to write them line by line. Digging into the code, though, is still the trickiest part of any application development, so it is not surprising that the bulk of a developer’s time is spent with the ABAP Editor. Despite a selection of model-driven programming tools, the typical ABAP developer probably spends as much as 95% of his time writing — and reworking — code using the ABAP Editor.
Whenever your work relies so much on any one tool, the addition of any new time-saving feature will have some major impact on productivity and speed up projects significantly. Even from a more user-oriented perspective, you should not underestimate the power of a user-friendly coding environment. It can make sitting down at the computer to make last-minute changes to your application to adapt to
new business requirements — or even worse, to edit code you didn’t design on your own — all the more bearable.
With all their new features, the latest versions of the ABAP Editor, I thought it best to appreciate the new features; we should first go back in time to see some of the limitations that were present in prior versions of the editor. I began my career in SAP in 1993 and had come from 15 years in the IBM Mainframe world of IT design & development. So it made sense for me to research the editor that I started with back in 1993 and travel forward in time to the present. Here is what I was able to find…
Early ABAP Editors
The first application ever developed for SAP R/3 was the ABAP Editor. After R/3 Basis was developed in the late 1980s, SAP needed a strong programming environment based on UNIX and relational database technology for its new release. Two internal SAP projects were launched — one based on the C programming language and another developed in ABAP on the R/2 platform (mainframe). Since R/2 ABAP was more or less identical to R/3 ABAP back then, it’s not surprising that the ABAP based solution was available first, and thus has become the commonly used solution. The reason was simple: Even slight changes in C always required a recompile and redeploy on the various UNIX workstations (i.e., installation of a new local GUI), whereas the ABAP-based editor was stored in database tables and therefore, due to ABAP’s server-side nature, was immediately available to all developers.
A Block-Editing and Tables-Based Approach
This distribution and self-compiling feature of the ABAP Editor (and, in fact, all ABAP programs) helped to set up a rather stable environment in the early SAP R/3 days, which was key to its success. However, the ABAP-centric design also had its price — Its dialog characteristics reflected a “block mode” editing environment. Users coming from an IBM environment felt comfortable with this, since the ABAP Editor shared many features of editors that are available on an IBM host, such as ISPF that ran under TSO (dating myself here!) which included the “block” on the left side of the editor interface where you insert line commands to copy, move, or delete lines. Developers who were used to UNIX or Windows (Same as saying younger than me!), however, were expecting other types of tools; Windows users, for example, would have expected a new line when they hit “enter,” while mainframe users expected data to be transferred in block mode to the host. To address this, if you were around back then, you will remember the ABAP Editor offered a “PC mode” that supported a Windows approach. From an implementation perspective, the ABAP Editor continued to use table controls — again, emphasizing handling of tabular data rather than lines of code independently.
Incorporating ActiveX Controls
The next innovation was triggered with SAP GUI’s support of OLE, which allowed internal SAP developers to embed native ActiveX controls capable of sophisticated frontend features such as drag and drop, local search and replace, local scrolling, local printing, and support for keyboard accelerators. This innovation was also reflected in the ABAP Editor, with a control-based editor plus backend features like syntax check and Workbench navigation (including the now indispensable double-click that allows developers to jump from the code directly to the definition of a structure or field). This ActiveX approach was a major step forward. Since it was being incorporated into a text editor-based approach, however, the ActiveX control-based editor was not aware of the ABAP syntax. Features that had become popular in other editors, such as syntax coloring, could not be supported directly.
Highlighting the New ABAP Editor
This leads us now into looking at the new editor and highlighting some of its time saving features.
-Automated and customizable syntax coloring, bookmarking, and collapsible code views to help better organize and manage even the most complex development code
-Code templates, dynamic content, and auto-correct options that “understand” what developers are coding and help us avoid syntactical errors
-More sophisticated, state-of-the-art user interfaces, including split windows and customized screens, to compare different sections of a program and speed development and, because it is integrated in the new debugger, speed of debugging as well
What’s New with the ABAP Editor
Did I peak your interest? OK, enough of the highlight reel, lets dig in and take a closer look.
A look at the ABAP Editor’s history (see above section) reflects how the new editor is a real breakthrough in its native ABAP support and its new level of controls sophistication. From a technical standpoint, the new ABAP Editor, like its predecessor, relies on ActiveX controls technology. But this time, this technology knows about ABAP syntax and can better predict and support the ABAP developer’s actions. Wow…an editor that helps me code!
Like previous versions of the ABAP Editor, the new editor is tightly integrated into the classic Workbench tools, meaning all the familiar server-side features — such as activation, global search, navigation to other tools, proper embedding into all major tools like class and function builder — are still fully available.
This all sounds great…you want to begin to use the new editor. However, wait a minute; your editor doesn’t look anything like the one I am describing? How do you get access to the new editor? It’s simple… to get started with the new editor, simply switch on the “Front-End Editor (New)” preference setting (as shown on the left screen in below). You can find these preferences inside of SE38 or SE80 by following the menu path Utilities (M)–>Settings. You will also be able to set yourself up to use the new debugger in the Workbench settings under the “Debugging” tab. Please refer to my blog on the new debugger to see why you should always use the new debugger.
The New Look of the ABAP Editor is shown below. Compare this to earlier versions — the only thing that looks familiar is the actual ABAP code! The most obvious change is all the color; automated syntax highlighting color-codes different syntactical elements. Keywords, such as DATA and CHECK, are shown in blue; string constants are green; custom code is in black; and comments are italicized — and all of these can be customized, which I will explain in a moment.
There are other features that developers will welcome……
-In the leftmost column of the editor screen, developers can insert symbols, such as breakpoints, to indicate stopping points throughout the program — there was no way to display these control icons in the previous version of the editor
-To indicate newly added or changed code, red triangles appear to the right of the corresponding line numbers where code has been edited
-Numbered bookmarks (shown as flags to the left of line numbers) can be easily inserted and manipulated using a context menu to more flexibly navigate to important points within your program
Customization Options
The ABAP Editor’s color and style assignments are certainly not fixed. If you prefer alternate colors and shading, you can customize the editor by simply clicking the customize button in the lower right corner of the main ABAP Editor window (shown above), which brings you to the Options menu. (see below) Suppose you fancy changing the color for breakpoints (in this case, setting it to dark red). Well this is where you can make this adjustment.
Here you can also change the various types of items you can display, including errors and breakpoints. Other customization features include the ability to…
-Set auto-correction options for frequently occurring misspellings
-Establish rules for “pretty printing,” including indentation settings
-Format code using font, color, word-wrapping styles, etc.
Splitting the Screen for Easier Maintenance
Double clicking the split bar button at the top right of the main ABAP Editor screen and/or dragging it down allows you to see two views of the same program. This split view helps you maintain related parts of a program within the same window — for example, you can program data definitions and the affected sections of code in parallel. (See Below)
Clearer Views of Even the Most Complex Programs
Another outstanding feature of the new code editor is its support for outlining syntactical structures such as CASE…ENDCASE and METHOD… ENDMETHOD (see below).With the “+” and “-” buttons, you can easily collapse and expand the body of syntactical structures within your code, and therefore better follow the inner structure of your programs by hiding details that are currently out of scope.
Features to Make Development More Efficient
Code templates are a powerful means to abstract recurring syntactical patterns. With templates the system can provide hints — while you enter code — that a template is available. For example, if you type the keyword “select,” the system will automatically suggest using the code template for “select.” If you simply press CTRL+ENTER, the suggested template will be inserted. (Misspellings can be corrected on the fly in the same way.)
The new ABAP Editor comes with a large selection of common, predefined template patterns (such as FORM…ENDFORM). However, you can also define custom templates on your own, helping enforce customized programming guidelines. You can use the template editor, which is integrated within the customizing dialog in the Options menu. The template mechanisms also allow you to insert dynamic fields (such as date/time) and integrate dialog input (such as the form name) to provide fully flexible templates. (see below)
Additional Editing Features
Other features that have been enhanced for the new ABAP Editor include….
-Extended dialogs for find and replace
-A clipboard that holds code fragments cut during your editing session, This is known as the clipboard ring and will be indispensible if you have the two or more code snippets to install repeatedly throughout your code
-Capabilities to print and export code snippets or full programs in multiple formats (HTML, PDF, etc.) for sharing code
Summary
The new features and design of the ABAP Editor better understand the syntactical elements of the language, greatly enhancing the productivity of your ABAP development teams. As always, the tools are integrated into the familiar environment of an ABAP Workbench. But unlike earlier versions, the tools are now integrated with each other — the new editing environment is fully reflected in the debugging environment, and vice versa. What’s more, the tools also offer many new customization capabilities to personalize each user’s design-time and runtime environment. This is cool, time-saving stuff for ABAP developers!
Please sign up for our newsletter by clicking below.
To further investigate the New Editor, use the link below to download the official SAP documentation
The New ABAP Debugger – Part 3
In this, the 3rd and the final installment, I will explore the tools of the NEW Debugger somewhat in depth. I will explore the tools I feel you will most likely use repeatedly. Please consult the SAP help portal to explore any tool further, and learn about any not discussed directly in this blog.
The tools of the New ABAP Debugger are optimized for the different debugging situations you may have to deal with during the course of solving a problem. Some of the tools you will recognize from the Classic ABAP Debugger; others are brand new. Before we look at a few of the tools and how to use them, lets first get comfortable with the tools menu and how the tools are organized.
If you want to add a new tool to the current desktop, you will get the pop-up window titled “New Tool” where you can choose the appropriate tool based on your situation.
The tools are grouped into sections:
Standard Tools:
- Source Code: Display current source code in the back-end editor. Please note that this is the old editor and I recommend you do not use this. There is another tool farther down the menu that will use the NEW Editor
- Call Stack: Display the current ABAP stack and screen stacks.
- Variable Fast Display: Display variable value and type.
- Breakpoints: Maintain breakpoints, watchpoints, and checkpoints.
- Source Code (Edit Control): Display current source code in the NEW ABAP Front-End Editor. This is the option I recommend you use to enlist all the valuable enhancements of the new editor.
Data Objects:
- Object: Display/change objects and classes.
- Table: Display/change internal tables.
- Structure: Display/change structures.
- Single Field: Display/change variables with simple data types, such as C, N, D, T,STRING,… etc.
- Data Explorer: Display very complex data structures in a tree-like fashion.
Its worth mentioning, that if you double-click on a variable displayed in any tool, you will launch the corresponding detail view described above that corresponds to its data type.
Special Tools:
- Web Dynpro: The structure of the content of the current controller, the properties of the UI elements in the layout of the current view and the currently instantiated component usages
- Loaded Programs (Global Data): Display all currently loaded programs and their global variables.
- Memory Analysis: Display integrated Memory Inspector tool (S_MEMORY_INSPECTOR)
- Screen Analysis: Display the screen attributes and the subscreen stack.
- Diff Tool: Compare variables very quickly to outline delta
- System Areas (Internal): Display system areas such as SMEM, ABAP Memory, Datasets, Screen Attributes…etc
OK, lets take a closer look at the most common debugging activities — displaying source code and the call stack, analyzing variables, and setting breakpoints and watchpoints.
Displaying ABAP Source code
I believe it’s important that we are using the New Editor and not the old “Classic Editor”. To be sure you are using the new editor, from the ABAP Editor main screen (SE38 or SE80) follow the menu path Utilities–>Settings. Verify that you are positioned on the editor tab and have selected the radio button for the Front-End Editor (New).
There are several compelling reasons for doing this (look for an upcoming Blog on the New SAP Editor), the reason most relevant for this blog is that the New ABAP Debugger leverages the following benefits of the new ABAP Front-End Editor…
- ABAP code is easy to read because of real-time syntax coloring.
- Both vertical and horizontal free scrolling is possible.
- Processing block start and end (i.e., IF/ENDIF,LOOP/ENDLOOP) is
highlighted in real time.
- Variable values and types appear in a Data Quick Info pop-up.
- Breakpoints are easily set using a breakpoint column
Displaying the ABAP CALL Stack
The Call Stack tool displays the ABAP call stack. It allows you to switch to the context of each stack level and navigate to the source code by opening the ABAP Editor, in order to start a deeper analysis of the code in a separate window(just double click!). Also new with SAP NetWeaver 2004s is the ability to display the screen (Dynpro) stack as well. Even more important, you can display a combined ABAP and screen stack to find out on which ABAP level which screen was called, and which screen invoked which ABAP module.
You can navigate from each stack line to the corresponding source line in the editor by double clicking on the icon in the stack type column.
Displaying variable contents
One of the new features of the New ABAP Debugger is the Variable Fast Display tool, which enables you to view basic information about a variable, such as the variable type, value, hexadecimal value, etc.
To display this information, you select the tool and then type in the variable name, or you can double-click on the variable name (i.e., the symbol) in the source code to transfer the symbol to the Variable Fast Display.
Even more convenient is the ability to display all global variables of the current program or all local variables (including the interface parameters) of the current procedure.
If you are interested in a special global variable of another program that is part of the application, you can use the Loaded Programs (Global Data) tool belonging to the special tools category, which allows you to browse all global variables of all loaded programs, not just the current program.
This tool also allows you to check out which programs have been used (i.e., loaded) in the current internal session.
One of the most significant benefits of the New ABAP Debugger is the ability to provide tailored detail views for all ABAP data types. The detail views are part of the New ABAP Debugger’s navigation system. Regardless of the tool that is active, you can navigate to a detail view by simply double-clicking on the variable in any tool (with the exception of the Source Code tool), and the variable automatically appears in the appropriate detail view.
For example, if we go back to the above diagram for global variables for the current program and double-click on line 2 of the MARA structure, the tool displays the Structure of MARA at the discrete field level.
For very complicated data structures, such as a complex nested object, it is more convenient to start an analysis in a tree-like display that allows you to dig deeper and deeper into the object without losing information about the levels above. The Data Explorer tool provides this capability.
Break-Points and Watch-Points
While breakpoints have not changed much between the Classic and New ABAP Debuggers,save a few enhancements, watchpoints have. Let’s take a look at each in turn.
Break-Points
In ABAP there are three different kinds of breakpoints, each of which serve a specific purpose. In releases prior to SAP NetWeaver 2004s, only one breakpoint icon was displayed in the debugger to denote all three types of breakpoints. In SAP NetWeaver 2004s, three different breakpoints icons are displayed in the New ABAP Debugger, as well as in the ABAP Editor, so you know immediately which kind of breakpoint you are dealing with.
You can set debugger breakpoints inside the debugger. They exist only as long as the debugger is active. Once the debugger is closed, all debugger breakpoints are gone.
Usually, you set session breakpoints in the ABAP Editor. The scope of session breakpoints is the current logon session. This means that your session breakpoints are present in all external sessions (i.e., SAP GUI windows) of the current logon session. If you select the Save button in the ABAP Debugger (in a dialog logon session), all current debugger breakpoints are automatically converted to session breakpoints.
If you set a breakpoint inside the coding of a Web Dynpro or BSP application, then the ABAP Workbench automatically sets a user breakpoint. User breakpoints are stored in the SAP database, and they are valid for all logon sessions of the current user on the current application server. If you set a user breakpoint, then all following logon sessions of this user will have those breakpoints set .
Setting breakpoints in the New ABAP Debugger is not much different from setting them in the Classic ABAP Debugger. If you click on the breakpoint icon in the control area of the New ABAP Debugger, the Create Breakpoints dialog appears. Here you select whether you want the breakpoint to occur at ABAP commands, methods, functions, or forms, or whenever an exception is caught. You can also set a breakpoint at an arbitrary source code position (even in not-yet-loaded programs). This capability is not available in the Classic ABAP Debugger.
You can get help when you are setting breakpoints at a method, function, or form by pressing F4. For example, pressing F4 in the Method Name field on the Method tab displays all included methods of a given class. So even if you do not have all the details about the method or function module, you can still set a breakpoint. In the Classic ABAP Debugger, there is no such help available.
Using the new Breakpoints tool, which is on the Break/Watchpoints desktop, you can administer all your currently set breakpoints. You can create, delete, activate, or inactivate breakpoints using this tool. In the New ABAP Debugger, you can treat the breakpoints individually. For example you can promote any single debugger breakpoint to a session breakpoint or any session breakpoint to a user breakpoint..etc
Watch-Points
A watchpoint can be set on any variable with local or global scope to break the execution of the program when the variable’s content changes. This makes it easier to debug the program’s data flow.
In order to create a watchpoint, click on the Watchpoint button in the control area of the New ABAP Debugger. In the pop-up dialog that appears, you can specify the variable, the scope for a watchpoint on a local variable, and a free condition. The scope for a watchpoint on a local variable means that you can set the watchpoint for only the current instance of the module on the execution stack in which the local variable exists, or for all instances of this module that will be pushed onto the stack. The ability to associate a free condition with the watchpoint is a convenient way to limit the number of “watchpoint reached” events according to your needs. When you specify a condition along with watchpoints, it is a free-style condition for which you can choose two arbitrary operands (no need to specify the watchpoint variable, but you can) and one operator. Write the condition in the same way you would write it in ABAP. You can use two built-in functions as operands in the watchpoint condition….. “lines( itab )” and “strlen( str )” (the number of lines of the internal table itab and the length of the string str, respectively).
For example, I will set a watchpoint on the internal table itab1 to break when it is greater than 50 lines in content.
All currently set watchpoints are listed in the Watchpoints tab of the Breakpoints tool. Here you can create, edit, delete, activate, or inactivate watchpoints. In addition to information such as the variable name, the scope, and the condition, you will find in the watchpoint list a symbol for the “old variable” for all watchpoints. This information enables you to view the value of the variable of the recently hit watchpoint before it was changed. I will execute the above watchpoint for illustration of this point…
The final tool I want to explore is the new DIFF tool.
Do you remember this situation…
You are hot on the trail and need to find the differences between two tables. Using the Tables desktop, we can easily create two table views in order to compare the two tables. However, for large internal tables, finding out the differences within an acceptable period of time is not an easy task.
The New ABAP Debugger provides a special tool for this task — the DIFF Tool, which finds the differences between two arbitrary ABAP data objects. You can compare internal tables, structures, strings, or even objects using the DIFF Tool, which provides the differences concerning the types (e.g., one table is a sorted table and the other a hashed table), and of course, the values.
I will start the DIFF Tool for the internal tables’ itab1 and itab2; simply click on the Start Comparison button, and viola, a complete display showing a list of all differences between the two tables.
Now that you know about the most important tools of the New ABAP Debugger, I hope future debugging tasks are easier and quicker for you! Happy debugging!
If you enjoyed this, please click on the link below and sign up for our newsletter.
The New ABAP Debugger – Part 2
The New ABAP Debugger provides a state-of-the-art user interface that can be customized to your needs.
Before exploring how the New ABAP Debugger user interface can help you achieve greater productivity, let’s focus on the following ……
• What are the main parts of the user interface?
• How can I customize it?
• Which debugger tools are available through the user interface?
Let’s look at the new interface. See below.
There are five main components of the New ABAP Debugger user interface:
• Process information area
• Control area
• Source code information area
• Desktops
• Tools
Let’s take a look at each in turn.
Process information area: The process information (or title) area of the user interface provides information about the status of the debugger or debuggee. The following information is provided:
- Session number: Because you can debug several applications in parallel, you need to know which session the debugger user interface is connected to.
- Debug setting/session type: Next in the process information area is information about the session type or status:
(/hs) indicates that system debugging is active.
-HTTP- indicates HTTP debugging.
-RFC->destination indicates debugging of an RFC module at the specified destination.
-UPDATE- indicates debugging of the asynchronous update functionality of a transaction.
-ATTACHED- indicates that the debugger is attached to a process (you can attach the debugger to a running process via transaction SM50 by following the menu path Process–>Debugging.
- Exclusive/Non-Exclusive indicates whether the debugger session runs as an exclusive session or a non-exclusive session. In an exclusive debugging session, the work process is exclusively locked for your currently running debugging session; in a non-exclusive debugging session, the work process is not locked, and any debugger action may involve an implicit database commit during roll-in/roll-out of the debuggee context. (See July 2011 Q&A in Newsletter)
Control area: Standard features for execution control (step into, step over, return, continue) in the New ABAP Debugger are similar to those in the Classic ABAP Debugger. The new debugger also provides shortcuts to create breakpoints and watchpoints.
Source code information area: The New ABAP Debugger displays the full information about the current source position. The displayed information depends on the current code type — in ABAP code you see “main program,” “include,” and “source line” information; in screen flow code, you see “main program,” “screen number,” and “source line” information.
Desktops and tools: Finally, we reach the most important part of the New ABAP Debugger user interface — the desktops and tools. The desktops are your work areas, and all available tools (e.g.,the Source Code display tool and the Variable Fast Display and can be arranged on the desktops. You can configure the desktops to your needs and switch to specialized desktops for unique debugging tasks. As you can see, there are three user-specific desktops (Desktop 1, Desktop 2, and Desktop 3) and seven standard desktops (Standard, Structures, Tables, Objects, etc.). You can customize which tools appear on any desktop (with a maximum of four tools on a desktop), along with the position and size of the tools on the desktop, but only the configuration of the three user-specific desktops can be stored permanently in a debugger variant. That right, we now have debugger variants. A debugger variant can consist of Options (e.g., customizing the navigation to the Detail Views or special options for the different tools) and debugger settings (e.g., turn the system debugging on or off ). You can store your Breakpoints and any user interface customizations (e.g., which tools are located on which desktop). Debugger variants are stored on the database. To access them, you need the name of user who created the variants and the variant name. You can also download a debugger variant to a local file. Cool…huh?
Ok, let’s wrap this up with customizing the interface. Below you see a debugger tool (the Source Code display tool) residing on a desktop. It is automatically accompanied on the left by arrow symbols, which you can use to resize the tool, decreasing or increasing the size of the area it covers in the window. On the right side is an icon bar, which provides the following functionality:
• Close (or remove) the tool.
• Choose a tool from the pop-up dialog, and add it to the current desktop.
• Exchange the tool with another tool selected from the pop-up dialog.
• Set the size of the tool to full-screen mode (this hides all other tools – be careful)
• Swap the location of one tool with that of another tool.
• Invoke a tool-specific services dialog.
When you invoke a tool-specific services dialog, a services dialog pop up that is specific to the tool in use opens. Let’s use the Tables tool as an example. (see below)
The services dialog consists of two sections:
Standard: Standard services are available for almost all tools. You can download the current tool content — for example, you can download the content of an internal table to a local file in order to analyze it by sorting the data, for example, in Microsoft Excel. You can also perform searches in the displayed content of the tool (press Ctrl-F to start a search and Ctrl-G to continue a search) — you could search for a special attribute of an object in the Object View.
Tool-Specific: This portion of the dialog presents all the specific features of the selected tool. As shown in the table-specific services dialog above, there are tools for customizing the columns and for modifying the content of an internal table (e.g., changing or inserting a row). You even have the option to delete the table itself.
Now you know how easy it is to customize your debugger desktops by adding (or removing) any of the Tools, and how easy it is to arrange them on the desktops.
In the next part of this Blog I will dive into each of the tools.
If you enjoyed this, please consider signing up for our newsletter by clicking on the link below.
The New ABAP Debugger – Part 1
Welcome to IT Partners blog. I am going to attempt and use this platform as a mentoring and teaching space. Please bear with me as I gain more experience in the blogging arena and the post become more intuitive and hopefully fun and informative. I encourage any feedback, as well as topics you would like me to address in future blogs.
This blog series will deal with the NEW ABAP debugger in ECC. Part 1 will explore the Classic (Old) debugger and the architecture and drawbacks. I will introduce the architecture for the new debugger and show how to make it your default-debugging tool for ECC. (It is the default Netweaver 2004s).
SAP introduced the “New ABAP Debugger” with SAP NetWeaver ’04, which includes a new architecture that enables analysis of all ABAP programs and a state of the-art user interface. The architecture of the New ABAP Debugger, which has been developed from the ground up, will provide for a more flexible and intuitive user interface.
If you happened to upgrade to SAP NetWeaver 2004s, then New ABAP Debugger has even more enhancements. Such as integration of the new ABAP Front-End Editor into the new source code display, complete with syntax highlighting and a Data Quick Info pop-up; the new Diff Tool, which guides you through the differences between, for example, two nested structures or internal tables; and the Data Explorer.
So why do we need a new debugger?
The Classic ABAP Debugger runs in the same roll area as the application to be analyzed (debuggee). It is therefore displayed in the same window as the application. However, this technology also has some restrictions. For instance, it is not possible to debug conversion exits and field exits. The reason behind this drawback is because inside a conversion exit for filed exit NO ABAP DIALOG statements are allowed. Like a CALL SCREEN. Since the debugger and the debguee share the same context, the debugger cannot send a debugger screen.
Another drawback is the risk of code in the debugger affecting the debugge. They both reside in the same internal session and naturally can impact each other. SAP has attempted to mitigate this risk but not using ABAP as the development language for the classic debuuger and its core resides in the Kernel. However, this leads to eeven more drawbacks, as now it is impossible to leverage any new ABAP GUI enhancements, such as the CFW (Control Framework).
Ok…now let us look at the new debugger architecture, called the Two-process architecture. So what is the big deal? The fundamental difference of this architecture is its two external sessions, each of which appears in its own SAP GUI window. One session for the debugge, and a separate session for the debugger. The debugger controls the debugge. This two-window approach, in which the debugger lives in its own external session, has significant advantages, and solved the issues of debugging through field exits and conversion routines. It has also insulated the object being debugged from the debugger instance. That means the integrity of debugge is no longer at risk of impact from the debugger.
OK, you want to use the new debugger…..Here is how to set it as your default. Switching between the Classic ABAP Debugger and the New ABAP Debugger is easy — in the Object Navigator (transaction SE80) or in the ABAP Editor (transaction SE38), follow the menu path Utilities–>Settings. (See Below)
You can initiate the debugger as you already know how to do using /H or by setting a break-point.
In my next post I will take you through what the new debugger looks like and explain in detail the different sections & tabs.
