Surely you have seen what ALV can do for the reporting possibilities of your end user. ALV is a must and us developer should deliver our reports in ALV. No exceptions. Over the past few years, I've developed a wrapper class that allows easy access to the all standard ALC class. It's a wrapper class in an include - which means it needs to be implemented in your system only once. A wrapper without limitations: if the options you seek are not covered in the wrapper, the SALV object reference is available to you.
 |
The EASY ALV wrapper class can be made available in your coding as lcl_Easy_ALV and there is a series of articles that demonstrate how the class can be used to implement a series of options / tackle real-life issues.
With a little help of the Easy ALV wrapper class, coding looks cleaner and complexity of ALV development is reduced quite a bit. The local |
Download your copy here. The coding for your own lcl_EASY_ALV class can be downloaded and made available as an include. This way with a single download it is available for the whole system (as is a global class). You can of course also copy the class definition and implementation into your own report and use it from there.
.
The suggested name of the include is ZABAPCADABRA_EASY_ALV, which is applied to the examples on the article series on Easy ALV.
The easiest way to utilize the easy ALV class. A simple program that composes an internal table and makes it available via ALV:
report ZDEMO_ALV_1_SIMPLE.
include ZABAPCADABRA_EASY_ALV.
data: gt_data type table of t100,
go_alv type ref to lcl_easy_alv.
start-of-selection.
select * from t100
up to 20 rows
into table gt_data.
create object go_alv.
go_alv->set_alv_from_template(
changing content = gt_data ).
go_alv->display( ).
And that's all there is to it.
Example in which field settings are altered. Note, these are only a few of the supported options.
Effectively the ready-to-run functionality will determine most field/column details automatically, but if you want to alter a description, turn your column into a key field or apply other options, here's how:
For this example a layout needs to be stored (hence abap coding alone is not enough).
Storing a layout (much like a variant but not with selection screen settings but with the ALV column configuration) is demonstrated here, with a focus on aggregate fields (totals and subtotals).
To make an ALV report interactive, the class needs a local class definition for it's menu handling and cell clicks. Cell content can be set up as hotspot, icon hotspot or button. ALV also supports line or column selection, for which the selecton results can be made available when a menu item is clicked.
Tooltips are not the first thing that presents itself when composing an ALV report. When your user hovers over a field, the tooltip text is revealed which can be a great additive to reports with a lot of columns. Also screen-to-speach software like Jaws can use tooltips to make reports more accessible to the visually impaired.
Assign a color to your cell in ALV and access another dimension to ALV reporting. With easy ALV it's even easier:
The ALV concept can also be applied several times on a single screen, for which a DYNPRO needs to be created. This example shows how that can be done for a simple screen with 2 custom containers.
With some ALV reported content, the sequence of the reported rows is very relevant, and the end user should not be allowed to change it. E.g. a log of executed steps are time-relevant and should thus not be sorted or filtered on.
The end user can move columns around, hide them or show columns that are not visible by default. These are changes to the layout of the ALV report and these changes can be stored in a "layout". Users can even set one of these layouts as his/her personal favorite, which means the report will start with the default the next time it started. For the user. Can layouts be made available to everyone ? Yes they can.