Saturday, October 4, 2014

ABAP Debugger

1. News in ABAP Debugger

Request-based Debugging of HTTP and RFC requests


If you use external debugging in ABAP - that is, debugging of HTTP and RFC requests which arrive in your ABAP system - then you have used the user breakpoint for external debugging. There are, however, situations in which the user breakpoint is not adequate - for example, if a request is load-balanced to another server than the one you are on or your requesting user is mapped to another user or is ignored because of a generic user for requests.  
For these situations, SAP NetWeaver 7.0 EhP2 introduces a second technique for external debugging to supplement user breakpoints: request-based debugging (debugging via Terminal ID). A user breakpoint is now server-independent and active on all application servers of an ABAP system.  With request-based debugging you can capture any external HTTP or RFC request for debugging, without regard to the user who submitted the request or the application server at which the request is processed. The execution of the requests of other users is not affected, which makes it possible to debug problems in production systems without disrupting normal operations.














To activate request-based debugging check TerminalID checkbox in the debugger settings (Utilities->Settings->Debugging), apply the settings and set a user breakpoint.















To transmit Terminal ID in case of HTTP requests download SAP HTTP Plug-in for Internet Explorer from the OSS Note 1041556, start the plug-in and it will start the browser. Start your application and press Start Transaction button on the plug-in. In case of RFC requests sent from SAP GUI use Ok code "/htid".

Software Layer Aware Debugging (SLAD)

In the old days of R/3, debugging ABAP business logic was easy. You enter "/h" to start the debugger or set a breakpoint, and you find yourself right-away in the middle of your application code. Nowadays, finding your code in the debugger is often not so easy.  Business logic now relies on application frameworks and technical frameworks and infrastructures such as ESI or Web Dynpro ABAP. It may be hard to find your way to your application logic in the debugger, since significant amounts of infrastructure code are in the way. Often infrastructure code is intermingled in your application code, so that even a direct breakpoint doesn't necessarily let you concentrate only on your code.
SAP NetWeaver 7.0 EhP2 resolves this problem and gives you full control over what you debug with a new debugging mode:  Software Layer Aware Debugging (SLAD). With layer aware debugging you can debug only relevant parts of ABAP code and hide the rest. Furthermore you can define layers - for example, the database layer, application layer, or the UI layer - and then jump from layer to layer instead of running through all of the code with conventional debugger steps. 
It works as following. By using the new transaction SLAD you define specific object sets (or layers) which should be accessed by debugger and hide the rest of the code. In the SLAD you select objects into selection sets (your packages, programs, classes, function modules ...) and use ABAP logical operators (AND, OR,...) to combine them to object sets (layers). Layers are normal ABAP transportable objects. Then you define your debugger profile (SLAD profile), which consists of such object sets (layers).













After you defined your SLAD profile you can start ABAP debugger and activate layer aware debugging (Configure Debugger Layer button). The pop-up appears where you can load your SLAD profile (or you can define it directly in the pop-up). And the debugger will stop only in visible layers of your SLAD profile.  Use normal debugger steps to debug the code within the layer. You can also use a new button Next Object Set to jump between the layers.












Automated Debugging - Debugger Scripting

Have you ever dreamt of a debugger which debugs your problem on its own - in a (semi-) automated way? A debugger which also allows you to write all kinds of information to a trace file?

In SAP NetWeaver 7.0 EhP2, the new ABAP Debugger introduces Debugger Scripting. With ABAP Debugger Scripting you can automate anything that you can do by hand in the debugger - and you win some new capabilities, such as flexible tracing. Debugger Scripting lets you control the debugger with a small ABAP program. The script program accesses the same information about your application in the debugging mode as the debugger itself. The script can do everything that the debugger can do: analyze content of variables, execute debugger steps, change object values etc. It can also write information to a trace file.
You can write debugger scripts by using normal ABAP and a rich set of pre-defined script functions (methods of the ABAP Debugger Interface) comfortably offered to you by Script Wizard. In your script you can stop, trace, or change the context of your program in the debugging mode. An integrated Script Tool allows you to write, save, load, and execute scripts and view traces, your own and those created by other users.

So which are the typical use cases for the ABAP Debugger Scripting? You can analyze the behaviour of your application by writing custom traces or implementing your own conditional breakpoints and watchpoints, you can write interactive debugger scripts to investigate typical error situations (dump analysis, consistency check,...), or analyze and display complex data structures (think of generic application frameworks!).














A new standalone transaction SAS allows you to maintain scripts and display script results.













Memory Consumption Analysis

In SAP NetWeaver 7.0 EhP2, ABAP brings you re-worked and greatly expanded memory analysis capabilities, in both the new ABAP Debugger and in the Memory Inspector (transaction S_MEMORY_INSPECTOR or SMI). Here are the main new features:

  • Dominator Tree. The new dominator tree (tab Dominator Tree) helps to determine the cause when you analyze memory consumption for object groups. The dominator tree is the keep-alive tree. With the dominator tree you can easily analyze the hierarchy of references to memory. If you go down the tree, you can determine for which sub-objects your object is responsible for and which objects would disappear, if it will be freed. If you go up the tree, you can determine the responsible objects, which keep your object alive. You can also examine additive memory values. The dominator tree is available in both the new ABAP Debugger and in the Memory Inspector.

  • Memory Object Explorer. You can press the right mouse button on a node of a dominator tree and switch to the Memory Object Explorer. With the new tool Memory Object Explorer (available only in the new ABAP Debugger under Tools->Memory Management->Memory Object Explorer) you can browse the object graph of a particular memory object and display its subordinate and superior objects.













Memory analysis for Web Dynpro application. Now you can analyze your Web Dynpro application for its memory consumption in debugger. With the new tool under Memory Management->Application-Specific Memory Views different Web Dynpro framework and application views of the memory are presented. Select in the Memory View dropdown "Application Web Dynpro" and filter out (Filter button) everything that is not Web Dynpro specific.













More features and improvements
  • New Web Dynpro Tool helps you to debug Web Dynpro applications quickly and efficiently. With this new tool, you can display and analyze the content of components of a Web Dynpro application in the new ABAP Debugger. You can display Web Dynpro Tool by using the desktop button New Tool and choosing Special Tools->Web Dynpro in the popup window.














  • Redesigned Table Tool - Enhanced display of internal tables. The Table Tool lets you view and manipulate the contents of internal tables in the debugger. By using a new columns configuration (Columns button on the Table desktop) you can optimize table display to see the columns you really want to see. Columns configuration lets you quickly add content of nested structures and objects attributes to the display of an internal table. You can store your table layout (columns) so that you can re-use it in your next debugger session. And last but not least the Table tool adds support for secondary keys (the key used can be toggled in the debugger).

  • Statement and expression debugging. Now you can debug ABAP statements that contain multiple expressions and statements on the same line of code incrementally: one expression or statement at a time. The new debugger button Step Size allows you to toggle between statement debugging and normal line debugging. On the Auto tab of the variable fast display you can analyze return values of single statements.











Conditional breakpoints and watchpoints. Now it is possible to specify conditions for breakpoints and watchpoints that you set in debugger. The debugger will stop as soon as breakpoint or watchpoint is reached and the specified condition is fulfilled. To add a condition to a breakpoint, open the context menu of the breakpoint and choose Create Condition. A popup will be displayed in which you can enter the condition.













You can add a condition to a watchpoint when you create it (Create Watchpoint button) or when you change it on the Breakpoints/Watchpoints tab in the debugger.












  • Special breakpoints ABAP has significantly extended the set of available breakpoints that you can set in the debugger.  Click on the Create Breakpoint button in the debugger, and you will find useful new breakpoints like the following:  
    • Special breakpoints for Web Dynpro ABAP (you can specify component, controller, or method)
    • Breakpoints for simple transformations (ST breakpoints)
    • Stack change breakpoints (stops only if ABAP and screen stack has changed)
    • A breakpoint at non-precise decfloat calculation (stops if a non-precise statement or calculation with decimal floating point numbers takes place)
    • Breakpoint at RFC and so on.

  • Simple transformation debugging. Now you can debug simple transformations (step-by-step execution, variables display, breakpoints).

  • Enhancement debugging. Now you can visualize enhancements in the stack, skip or execute enhancement implementations.

  • Adoption of functions from the old debugger. In the new ABAP Debugger, you can display current generated classic list in debug mode, restart the entire application,  use debugger settings (block sending TRFC, ESI debugging, Shared Objects: debug automatic area structure, always generate exception object, Control Framework: Automation controller, Always processes requests synchronously, check sorting before READ BINARY SEARCH).

  • Miscellaneous. Now there is F4 help for breakpoints on ABAP commands. You can also set watchpoints on objects. In the variable fast display a new tab page, Auto, displays the last return values of methods. Among other new features are these:
    • You can change long data objects in the detail view.
    • There is a new screen tool for analyzing screens (control, properties, layout). 
    • In the stack tool there is a new setting for displaying the call stack of an internal call mode.
    • There is a new exception tool for displaying and analyzing the last and previous class-based exceptions.
    • The new console tool displays the growing data of serializations from ABAP to XML for CALL TRANSFORMATION and for classic list outputs.
    • In the ABAP byte code or ABAP byte code (debug macro) context menus, you can select what a replacement for a proper macro debugging run can depict.

    2. New ABAP Runtime Analysis (SAT)


    SAT is the transaction name of the new ABAP Runtime Analysis Tool which replaces the earlier transactions SE30 and ATRA. As the successor of SE30 and ATRA, SAT can be used for typical scenarios of ABAP runtime analysis such as performance analysis, program flow analysis or memory consumption analysis.
    SAT has a modern and flexible multi-tool user interface (the same as in the new ABAP debugger) which can be customized individually. SAT stores measurement results centrally on the database, which allows analysis of the results from any ABAP server in a multi-server system .  SAT also enables cross-system comparison of measurement results.

    SAT offers a rich set of flexible new analysis tools which help to analyze different aspects of a trace. You can navigate between tools with comfortable user interface features: display specific trace details or focus on the trace sub-area to analyze it more deeply. 
    The Call Hierarchy and Hit List tools, which you may know from SE30, continue to be available. But you can also benefit from these new analysis tools:

  • Profile Tool checks out the runtime consumption of components, packages, programs and even debugger layers (SLAD)
  • Processing Blocks Tool displays a tree of processing blocks to get aggregated view on the call sequence
  • SAT offers a hotspot analysis to find performance and memory hotspots
  • Call Stack Tool displays the call stack for each item of the Call Hierarchy
  • DB tables Tool identifies time-consuming database statements
  • Times Tool provides more specific time measurement values for call hierarchy events
     












3. News in ABAP Testing Tools


ABAP Unit

An ABAP Unit Browser that is integrated into the Object Navigator of the ABAP Workbench allows:

  • A structured overview of existing unit tests to be displayed.
  • Several test runs to be started at the same time.
  • Unit tests to be organized in favorites.

When you test favorites, you can also have the code coverage of the tests in the favorite measured and displayed.














SAP NetWeaver 7.0 EhP2 also adds the tokens RISK LEVEL and DURATION to the CLASS ... FOR TESTING statement to replace the pseudo comments "#AU Risk_Level ... and "#AU Duration ..., which were introduced in SAP NetWeaver 7.0 for defining the properties of test classes.
The class CL_AUNIT_ASSERT is replaced by the new class CL_ABAP_UNIT_ASSERT, and class CL_CONSTRAINT has been replaced by CL_AUNIT_CONSTRAINT. New methods have also been added to the new classes. Existing module tests do not have to be converted to the new classes. However, we recommend that you use only the new classes in new tests.

Coverage Analyzer

The Coverage Analyzer has been extended with these new features:

  • Code coverage is now measured at statement level (statement coverage).
  • The coverage of individual conditions of logical expressions is measured (condition coverage).
  • The coverage of empty branches is measured.
  • The coverage of statement blocks executed and not executed is measured in control structures (branch coverage).

Code coverage is visualized in different colors in the new ABAP frontend editor. To measure the coverage of test runs, the Coverage Analyzer has been integrated into ABAP Unit testing.


No comments: