Page
1
SAP List Viewer Object Model for ABAP Developers Building Dynamic, Interactive, and User-Friendly ALV Reports — William Lawlor
Page
2
SAP List Viewer Object Model for ABAP Developers Building Dynamic, Interactive, and User-Friendly ALV Reports William Lawlor
Page
3
SAP List Viewer Object Model for ABAP Developers: Building Dynamic, Interactive, and User-Friendly ALV Reports ISBN-13 (pbk): 979-8-8688-2172-1 ISBN-13 (electronic): 979-8-8688-2173-8 https://doi.org/10.1007/979-8-8688-2173-8 Copyright © 2026 by William Lawlor This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Aditee Mirashi Editorial Assistant: Gryffin Winkler Cover designed by eStudioCalamar Cover image designed by Freepik (www.freepik.com) Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a Delaware LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail booktranslations@springernature.com; for reprint, paperback, or audio rights, please e-mail bookpermissions@springernature.com. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub. For more detailed information, please visit https://www.apress.com/gp/services/ source-code. If disposing of this product, please recycle the paper William Lawlor Dublin, Ireland
Page
5
(This page has no text content)
Page
6
(This page has no text content)
Page
7
(This page has no text content)
Page
8
(This page has no text content)
Page
9
(This page has no text content)
Page
10
(This page has no text content)
Page
11
xi About the Author William Lawlor is an SAP ABAP Developer and Consultant with over 30 years of field experience. Spanning environments from R/3 to Hana, he specializes in building complex reports and applications using ABAP and the SALV Object Model. William combines technical proficiency with a passion for knowledge sharing, breaking down intricate concepts into clear, accessible insights to help developers master SALV development.
Page
12
xiii Introduction Designing report layouts by hand and rebuilding the same framework again and again can quickly become tedious. SALV takes that burden off your shoulders. With built-in features such as sorting, filtering, totals, and export options, you can leave the formatting details behind and concentrate on implementing solid business logic. This book guides you step by step through the creation of SALV reports, starting with the fundamentals and progressing to more advanced techniques. You will learn how to adjust and enhance columns, control and save layouts, and respond effectively to user actions, all while keeping your ABAP code structured, readable, and easy to maintain. Along the way, common pitfalls are addressed with practical solutions, and you will find recommendations for organizing programs that are built to last. The objective is straightforward: help you deliver professional, well-structured reports with significantly less effort and greater confidence.
Page
13
1 © William Lawlor 2026 W. Lawlor, SAP List Viewer Object Model for ABAP Developers, https://doi.org/10.1007/979-8-8688-2173-8_1 CHAPTER 1 The Evolution of ALV Welcome! If you’re reading this, you’re ready to master a skill that, in my opinion, lies at the very heart of being a great SAP developer: presenting data with the SAP List Viewer (ALV). I’m talking specifically about its modern, object-oriented form, the ALV Object Model, or SALV. In nearly every SAP application, the end goal is to show the user some data in a clean, tabular format. It doesn’t matter if it’s a list of sales orders, financial documents, or custom application logs; getting information on the screen in a way that users can actually use is everything. I’ve seen brilliant reports fail completely because the interface was clunky and unintuitive. The adoption of any report truly hinges on how well it allows users to play with the information you give them. ALV was SAP’s answer to this challenge, and it’s now the gold standard for building user-friendly displays. But it wasn’t always the slick, powerful framework we have today. Like ABAP itself, it’s gone through a few generations. I think understanding this history is key to appreciating why the modern SALV exists and why you should absolutely be using it. A Brief History: From WRITE to SALV In the early days of ABAP, producing even a simple on-screen list was a slow, manual chore. Developers had one real option: the WRITE statement. It printed data, nothing more. Showing something as basic as a list meant looping through an internal table and outputting each field by hand, carefully calculating the position of every column. It was as painful as it sounds. You could spend hours aligning everything, only for a user to request one more column, forcing you to recalculate every position again. It was tedious, brittle work and an easy way to ruin an afternoon.
Page
14
2 Listing 1-1. A throwback to list display using WRITE DATA: gt_flights TYPE TABLE OF sflight, gs_flight TYPE sflight. START-OF-SELECTION. SELECT carrid, connid, fldate FROM sflight INTO TABLE gt_flights UP TO 20 ROWS. "--- Manually write the header WRITE: / 'Carrid', 10 'Connid', 20 'Fldate'. ULINE. "--- Loop and write the data LOOP AT gt_flights INTO gs_flight. WRITE: / gs_flight-carrid, 10 gs_flight-connid, 20 gs_flight-fldate. ENDLOOP. Figure 1-1. WRITE list. The exact date format and values will depend on your user settings and the data in the SFLIGHT table Chapter 1 the evolution of alv
Page
15
3 This approach was a real headache for a few reasons: 1. Zero Interactivity: The output was completely static, just a “print” of data to the screen. Features that users consider non-negotiable today like sorting, filtering, or calculating totals simply didn’t exist. If you wanted to add a sort button, you had to build it all from scratch, often re-reading and redisplaying the entire dataset with every click. It was a ton of work for very little reward. 2. No Standardization: Without a common framework, every report looked and behaved differently. My sales report might look nothing like the one built by the developer down the hall. This lack of consistency made the system confusing for users and a pain for new developers to support. 3. Spaghetti Code: The business logic (getting the data) and the presentation logic (WRITE statements) were all tangled together in one monolithic program. This made the code incredibly difficult to debug and maintain. A simple request like “Can you make that column header a bit wider?” could turn into a major code excavation project. The First Revolution: Function Modules Recognizing how inefficient this was, SAP gave us a massive upgrade with the ABAP List Viewer in Release 3.1. This new framework, delivered as a set of function modules, was a revolution even though it didn’t become the de facto standard for every custom report until 4.6C. The two most famous were REUSE_ALV_LIST_DISPLAY and the far more powerful REUSE_ALV_GRID_DISPLAY. The grid, in particular, felt like it was from the future, offering a modern, spreadsheet-like interface with tons of built-in features. Suddenly, instead of that tedious LOOP and WRITE combination, we could just pass our internal table to one of these functions. We’d configure the columns using a special structure parameter called the “field catalog,” and the framework handled the rest. Chapter 1 the evolution of alv
Page
16
4 With almost no effort, our programs inherited a professional, standardized interface with built-in sorting, filtering, and data export. For those of us who came from the WRITE era, it was a miracle. Listing 1-2. ALV function module * Type-pools for ALV definitions TYPE-POOLS: slis. DATA: gt_sflight TYPE TABLE OF sflight, gt_fieldcat TYPE slis_t_fieldcat_alv. START-OF-SELECTION. SELECT * FROM sflight INTO TABLE gt_sflight UP TO 20 ROWS. IF sy-subrc = 0. " Build and customize the field catalog PERFORM build_field_catalog. " Display the ALV grid using the custom field catalog CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY' EXPORTING it_fieldcat = gt_fieldcat " USE THE FIELD CATALOG TABLES t_outtab = gt_sflight EXCEPTIONS program_error = 1 OTHERS = 2. IF sy-subrc <> 0. MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ENDIF. ENDIF. *& FORM build_field_catalog FORM build_field_catalog. Chapter 1 the evolution of alv
Page
17
5 DATA: ls_fieldcat LIKE LINE OF gt_fieldcat. " Generate a default field catalog from the data structure CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE' EXPORTING i_program_name = sy-repid i_structure_name = 'SFLIGHT' CHANGING ct_fieldcat = gt_fieldcat EXCEPTIONS inconsistent_interface = 1 program_error = 2 OTHERS = 3. IF sy-subrc <> 0. MESSAGE 'Error during field catalog generation.' TYPE 'E'. ENDIF. " Loop through the generated catalog to make custom changes LOOP AT gt_fieldcat INTO ls_fieldcat. CASE ls_fieldcat-fieldname. WHEN 'CARRID'. ls_fieldcat-seltext_m = 'Airline Code'. " Change medium header text WHEN 'CONNID'. ls_fieldcat-seltext_m = 'Connection'. " Change medium header text WHEN 'FLDATE'. ls_fieldcat-seltext_m = 'Flight Date'. " Change medium header text WHEN OTHERS. ls_fieldcat-no_out = 'X'. " Hide all other columns from the output ENDCASE. MODIFY gt_fieldcat FROM ls_fieldcat. ENDLOOP. ENDFORM. Chapter 1 the evolution of alv
Page
18
6 Figure 1-2. ALV function module Of course it wasn’t perfect. Customizing the report meant battling with the infamous field catalog—a massive, complex structure where one little typo could cause a short dump. And event handling used callback subroutines, which felt clunky and outdated as ABAP began its journey toward object orientation. And here’s a fun fact: SAP never officially released these function modules for customer use! They were intended for SAP’s internal development, and to this day they remain unsupported (OSS 551605). But back then, nobody cared. The benefits were just too massive for us to ignore! The Second Revolution: Controls Technology Around the time of Release 4.0, SAP made a huge technical leap that changed reporting forever. They introduced something called Controls Technology, managed by the Control Framework (CFW). Before this, our ABAP programs were kind of stuck on an island called the application server. The user’s screen, running on their local PC as part of the SAP GUI, was a separate island. The CFW was the bridge that finally connected them. For the first time, our server-side ABAP code could directly communicate with and control powerful UI components that were running locally on the user’s machine. Chapter 1 the evolution of alv
Page
19
7 These new components, often delivered as little DLL or ActiveX files, were a world away from the simple input fields and buttons of classic Dynpro screens. Suddenly, we could embed things like interactive tree structures, rich text editors, and even HTML viewers right into our applications. But the most important new toy in the box, at least for reporting purposes, was the ALV Grid Control. This led to the birth of the CL_GUI_ALV_GRID class, which became widely supported for customer use around 2001 (with Release 4.6C). This was the direct, object- oriented way to use the new grid control. It was a revelation. It gave us the power to build the dynamic, Excel-like tables that users had been begging for, complete with out-of-the- box sorting, filtering, and subtotals. SALV was the next logical step in this evolution. As powerful as CL_GUI_ALV_GRID was, it still required a bit of manual setup, what we call “boilerplate code,” like creating a screen container to hold the grid. The developers of SALV looked at that and said, “We can make this easier.” Think of SALV as a smart wrapper class that sits on top of CL_GUI_ALV_GRID. It handles all that boilerplate for you, allowing you to create a powerful, professional report with just a few simple lines of code. It’s the culmination of years of progress, designed to give you maximum power with minimum effort. The Modern Era: Object-Oriented SALV As ABAP matured into a true object-oriented language, the old procedural function modules started to show their age. They were a relic of an older design paradigm. We needed a cleaner, more maintainable, and truly object-oriented API. That’s what led to the creation of the ALV Object Model, which we all know as SALV. Let me be blunt: the old REUSE_ALV_* function modules are now obsolete for new developments. You’ll see them all over legacy code, and you’ll need to know how to maintain them, but you should never use them for a new project. The SALV framework is a set of global classes (you’ll recognize them by the CL_ SALV_* prefix) that provide a beautiful object-oriented wrapper around the underlying grid technology. Instead of calling one giant function module and passing it a dozen complex parameters, you now instantiate a main ALV object. Then, you interact with that object through clean, clear method calls to configure its appearance and behavior. Chapter 1 the evolution of alv
Page
20
8 Look at how much cleaner the code is. This is the basic structure: Listing 1-3. The beautifully simple ALV Object Model DATA: lx_msg TYPE REF TO cx_salv_msg. * --- Basic ALV Object Model Usage --- DATA: lo_alv TYPE REF TO cl_salv_table, lt_flights TYPE TABLE OF sflight. " 1. Get data SELECT * FROM sflight INTO TABLE lt_flights UP TO 20 ROWS. TRY. " 2. Create an ALV instance using the factory method cl_salv_table=>factory( IMPORTING r_salv_table = lo_alv CHANGING t_table = lt_flights ). " 3. Get component objects and call methods to customize lo_alv->get_functions( )->set_all( abap_true ). " Enable all standard toolbar functions lo_alv->get_columns( )->set_optimize( abap_true ). " Optimize column width " 4. Display the ALV lo_alv->display( ). CATCH cx_salv_msg INTO lx_msg. " Error handling MESSAGE lx_msg TYPE 'E'. ENDTRY. Chapter 1 the evolution of alv