Skip to content
Jan 17 16

Using The SALV OO Class – Changing how the ALV Grid is Displayed

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Recap from last Month

In the previous post Using The SALV OO Class – Adding Functions to the ALV ToolBar, we added functions to the standard toolbar delivered with the ALV Grid functionality (see below).

ALV with Tool Bar

In keeping in line with developing a feature-rich ALV grid for our users, in this post we are going to work on the appearance of the ALV. Specifically adding a custom title, and making the ALV more readable.

Adding a custom title to the ALV with the SALV Classes

I can hear you now… your like… wait we have a title! It’s “Demo for using SALV Class to Create ALV Output”.  Well, yes you are correct. But where did that title come from? It’s the title from the program ZSALV_DEMO02. You can see this if you use the menu path Goto->attributes in se38. The ABAP runtime processor will use this if no custom title is present. It will do the same in the classic ABAP List View as well.

SE38 Attributes

 

We can, thankfully, easily add our own title to the ALV quite easily. We first need to declare a new object reference variable GR_DISPAY.

SALV GR_DISPLAY

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Dec 15 15

Using The SALV OO Class – Adding Functions to the ALV ToolBar

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Problems with ABAP output and why using the ALV Toolbar can help

In the last post, we examined why using the ALV Grid as an output was far superior to the standard ABAP Classical lists created using ABAP statements like WRITE, POSITION, or FORMAT, etc…etc.

In this post we will add some needed functionality to our base ALV report created in the previous post. A TOOLBAR! Well actually we will add FUNCTIONS. We already have a toolbar, its just empty. see the screen shot below.

Empty ALV ToolBar

Remember how in the last post we saw that developers devise their own methods for common list handling activities such as headings, sorting, filtering, rendering subtotals, and the like when ALV Grid’s are NOT USED. Well using the Integrated ALV Tool Bar functionality solves this problem.

Before we get into the how-to, lets dig a little deeper into the UI of the ALV and Toolbar.

ALV Grid Baseline Functionality

Take a look at the screen shot below; it shows an  ALV Grid and its integrated toolbar, which enables mouse-oriented access to a variety of list handling functions. Remember, because we are using the SALV Classes, we are developing in ABAP OO ALV.

Users can invoke functions that refer to a selected column (like hide, search, or filter) directly via a context menu. (The selection of columns and rows complies with the Microsoft standard, which means that users can do things like use the CTRL key to select rows or columns that are not adjacent.)

Let’s take a closer look at the toolbar. See the screen shot below for an overview of the generic functions of the toolbar

ALV Grid ToolBar

The user can sort the list by one or more columns, filter entries (e.g., display only data of one day), and calculate totals and subtotals. Users can determine column order and column length to retrieve needed information in a more convenient fashion.

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Nov 15 15

Using The SALV OO Class for Quick and easy Table displays

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Problems with ABAP output and why using ALV can help

In this Blog series I will dive deeply into the SALV ABAP OO Class and elaborate on its advantages in ABAP over list processing. Lets begin by looking at some problems with “Classical” list processing…

 

Within an SAP system there is a lot of data that needs to be reviewed, maintained, and interpreted. You know what I’m talking about — inventory data, controlling data, accounting data, employee addresses, and so on and so forth. The bigger a company, the greater the amount of data that needs to be output for review and analysisWithin the context of certain applications, the terms “output” and “list” can be synonymous.

 

When I took my very first ABAP class at SAP Education, I learned that the term list denotes an output page that has been created using ABAP statements like WRITE, POSITION, or FORMAT, and text lines are buffered in a list buffer before a system program called the ABAP list processor steps in to perform various run-time activities. Lists created in this way are often referred to as classical lists (everything in SAP that is old is lovingly termed Classical) and represent the standard output method of data.

 

If you have dealt with list formatting issues and/or the use of events for interactive lists, you will find the features and functions introduced by an ALV report will make your life a lot simpler. Granted, the effort to create a classical list for just simple output of data is minimal. But amass a few lists across a few applications, each created by a different developer, and things get a bit more complicated.

 

The ABAP list  processor lacks standard baseline list handling functions like sorting, filtering, and calculations, so these types of functions have to be added by hand for each new list. Responsibility for list layout and interface design is also left to the developer. This is why you find different schemes for list handling and layout in different applications.

 

Lack of standard, baseline list processing functions means that developers devise their own methods for common list handling activities such as headings, sorting, filtering, rendering subtotals, and the like. The result is that end users who work with more than one application may have to deal with different ways to access these simple list functions based on the developer who coded the solution.

 

OK, Now you feel confident that using and ALV report or control is the way to go.

 

Now why use SALV?  Why not use the SAP ALV Grid Example I refer to in my previous Blog Series A Guide to the New ALV Grid Control ?

 

Prior to SAP Netweaver, we had so many different starting points to create the ALV. The starting point was entirely dependent on structure of the ALV (Tabular, Tree, Hierarchical), Type of ALV (List or Grid) etc…  If we wanted to use the Control framework, than we need to start the ALV by using the class CL_GUI_ALV_GRID as I described in my previous blog A Guide to the New ALV Grid Control. Moreover, we needed to make different calls for TOP-OF-PAGE, END-OF-PAGE etc… What’s the answer?

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Oct 18 15

Fast and Easy SAP ABAP Debugger Scripting

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest

97be63abb66b42f281dff9197b6b35da_WglrP9Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

SAP ABAP Debugger Scripting in NetWeaver 7.0 EHP2

SAP ABAP Debugger Scripting is a new tool added in SAP Netweaver 7.0 EHP2. It is a feature available in the New ABAP Debugger. However, just like some of the other debugger options, you need to check whether the security team has provided access for the debugger script tool.

As ABAP programmers we regularly use Break-Points & Watch-Points for debugging. These are necessary in an ABAP programmers role to find the bugs in custom developments, analyze the Standard SAP program or find a BADi for that matter. So where does this Debugger scripting come into play? What is Script Debugging Used for?

Designed To Make Debugging ABAP Code Easy

The debugger scripting is a tool is designed to make debugging easy. Sometimes debugging can be very tiresome, especially when debugging SAP standard code is involved. See my previous blog on Layer Aware Debugging (SLAD) in SAP Demystified for another great tool to speed up debugging time.

The debugger scripting tool can sometimes come to the rescue, as it helps automate the process of debugging.

Some of the benefits of Debugger Scripting are:

he new scripting capability lets you automate anything that you can do by hand in the New ABAP Debugger. Debugger Scripts also make some things possible – like all kinds of tracing – that aren’t possible by hand.

With ABAP Debugger Scripts, you can:

- Analyze and modify the contents of variables and objects in the program you are debugging.You can display or change the value of a variable by hand in the debugger, and you can do the same thing with a script.  The classical example: You can skip over failed AUTHORITY-CHECK statements with a script by stopping at each AUTHORITY-CHECK, running it, and resetting SY-SUBRC to 0.  (This is still recorded in the System Log….)

- Perform any imaginable tracing that you might want to do.

With scripts, you can…..

- Do the first automated absolutely complete trace of executed ABAP statements possible (SAT – the new ABAP Runtime Analysis – cannot capture every executed statement.

- Trace the call stack in an ABAP application or in any part of an application – very useful if you want to find out what to include in a profile for ABAP Layer-Aware Debugging (See Layer Aware Debugging (SLAD) in SAP Demystified.)

- Define your own traces with any trace message content that you can imagine. You can for example trace the value of a parameter that is passed up or down the call stack in your application to find out where it goes bad.

- Implement your own breakpoints and watchpoints, should the extended set introduced in EHP2 not meet your needs. You can combine the powers of the new ABAP breakpoints and watchpoints with the intelligence of scripts.  Some system in your landscape is returning trash in an RFC data structure?  No problem. Have your script run whenever the program in the debugger does an RFC (breakpoint at RFC), execute the RFC call, check the returned data in your script, write a trace or break execution when you find the bad data return.

- Analyze and display data from complex data structures (internal tables with nested objects, for example) The revised Table tool in the New ABAP Debugger makes it a lot easier to look at data in a complex data structure (look for the upcoming weblog). But for tracing data generation or checking data consistency as your debuggee runs, a script is the better tool. The classical example is an internal table with nested objects whose attributes you want to check. A script can read those nested attributes row by row, check or trace them as you wish, and even stop execution if something goes wrong.

- Program (interactive) tools for standard tasks, such as checking data consistency, changing variable values to test error handling, and so on.

A lot of script programming is quick ad hoc work right in the debugger to help you with some analytical or data collection problem.

But ABAP Debugger Scripting also lets you save scripts for re-use.  And Transaction SAS offers a comfortable workplace for developing scripts away from the pressure of an active debugging session.  You can develop tools or utilities for debugging to suit your special needs, and you can share these scripts with others on the same or on other ABAP Systems.

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
Sep 13 15

Layer-Aware Debugging (SLAD) in SAP Demystified

by admin
Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest
97be63abb66b42f281dff9197b6b35da_WglrP9Anthony Cecchini is the President of Information Technology Partners (ITP), an SAP consulting company headquartered in Pennsylvania. ITP offers comprehensive planning, resource allocation, implementation, upgrade, and training assistance to companies. Anthony has over 17 years of experience in SAP R/3 business process analysis and SAP systems integration. His areas of expertise include SAP NetWeaver integration; ALE development; RFC, BAPI, IDoc, Dialog, and Web Dynpro development; and customized Workflow development. You can reach him at ajcecchini@itpsap.com.

Software Layer-Aware Debugging (SLAD) in NetWeaver 7.0 EHP2

SLAD Debugging

How many of us have had this happen during debugging? You need to analyze a bug, or you want to find out how an application works. And you don’t know where exactly to set a breakpoint. So you start the ABAP Debugger and start stepping through the code. And you keep on stepping through the code, endlessly, without reaching any of the application logic in which you are interested!

Well there is a solution and its Software Layer-Aware Debugging (SLAD), sometimes referrefd to as Profile Controlled Debugging. With NetWeaver 7.0 EHP2, which is delivered with Enhancement Package 5 of SAP ERP, ABAP brings you an elegant solution to the problem of reaching the code you want to debug: layer-aware debugging.

The basic idea of layer-aware debugging is simple: you separate the code in the system into the code that you want to debug and all the rest that you don’t want to see. You tell the New ABAP Debugger about this, and the debugger lets you jump right to the code you want to see, skipping over (optionally) all the rest of the code.

Take a look at this short film demonstrating Layer-Aware Debugging: Demo: ABAP Layer-Aware Debugging.

You can vary software layers along these dimensions:

Granularity: You can define an object set broadly, as the list of software packages in a package component, for example. You can also define very narrow object sets, citing individual programs, classes, and function modules.

Visibility: You can specify in an object set whether code is visible in the debugger. You can also specify how the debugger should behave when it finds code from the object set – stop on entry, stop on exit.

Flexiblity: You can include multiple object sets in a profile, so you can modulate the behavior of the debugger with respect to software layers precisely. And a profile can specify what the debugger should do with all the rest of the code that is not defined in object sets.

read more…

Recommend This Post! Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Pin on Pinterest