Introduction
Over the years, my company has developed quite a few template programs for different activities. These allow development to start quickly, they remove the time it takes to code the same basic code over and over again, they provide consistency between applications, and they help new developers learn techniques from more experienced ones.Now that we are in the middle of our R/3 4.6C to ECC 5.0 upgrade (WebAS 640), we wanted to update our most used template - our REUSE ALV report template.
The Old Template
Our old template program was based upon the set of REUSE function modules: REUSE_ALV_GRID_DISPLAY, REUSE_ALV_EVENTS_GET, and REUSE_ALV_COMMENTARY_WRITE. It also had functionality for working with ALV Grid Layout variants provided by function modules LVC_VARIANT_F4 and LVC_VARIANT_EXISTENCE_CHECK. This allows us to create reports with selection screens/variants that can also contain the grid variant. The REUSE function modules also work well Online/Interactive or for Batch Printing.But one of the biggest problem with the template program approach (which we started doing about 8 years ago well before ABAP OO), is that the template program is copied and modified to add the necessary business logic. This creates the situation where the same code exists in many different programs. So not only did we want to recreate the existing functionality of our template program, but we wanted to also take an OO approach. Our goal was to recreate the functionality mostly as an ABAP OO Class. Then the final application could inherit from the base template class and just redefine the necessary methods. This would provide better maintainability over time. It also will allow us to add new features to the existing reports very easily.
The New Template
First of all you are welcome to download the complete source and documentation for this template from the following (I am only going to cover the more interesting parts in this weblog):Download Content
First of all let's have a look at the output that our template program will produce:
We will put in some very simple business logic (a select * from SFLIGHT) just so we can test that all the functionality works.
Dialog Program
Even though we wanted to go with as much of an ABAP OO approach as possible, we still need to support the ability to have select-options or parameters. The easiest way to do this is still to start with a dialog program. Therefore we still have a small template program that must be copied from. This is when the programmer can place their select-options/parameters and the hooks to their business logic (preferably in separate class methods).report zesu_report_template_alv_om. tables: sflight. data: itab type table of sflight. data: keg_alv type ref to zcl_es_alv_om. selection-screen begin of block five with frame title text-017. parameter: variant like disvariant-variant. "ALV GRID VARIANT parameter: nodata1 as checkbox. "RUN ALV WITHOUT DATA selection-screen end of block five. at selection-screen on value-request for variant. keg_alv->f4_layouts( changing c_variant = variant ). initialization. create object keg_alv exporting i_repid = sy-repid. keg_alv->get_default_layout( changing c_variant = variant ). start-of-selection. keg_alv->auth_check( ). if nodata1 = 'X'. else. select * from sflight into table itab. * Perform to read data and do processing endif. keg_alv->set_report_title( 'Dialog Template'(t01) ). keg_alv->publish_alv( exporting i_variant = variant changing itab = itab ).There isn't all that much going on in the dialog program. We have the hooks into our class where all the real logic is. We also have hooks at the different events (on value-request and initialization).
Template Class
If you study the coding for the template class (available in full in the downloadable package), you will find an example of how to recreate all of the functionality of the Reuse ALV in the new ALV OM.
There are methods for creating the report header for instance. In the Reuse ALV you could just build HTML that would be used in interactive mode for the header. Now the ALV OM has its own meta data model for describing the header layout and content that is independent of the rendering output (HTML for interactive and ABAP List for background/printing).
There are also methods for adjusting the user interface (adding or taking away user events) and for registering and responding to ALV events (such as a double click on row). By default the event handlers are delivered empty.
This speaks to the power of using a class for the template. Now let's assume that you have a basic report but you want to allow the user to double click on a row to forward navigate to the detailed transaction. You would inherit from the ALV Template class. You would then only need to redefine two methods. You could redefine the REGISTER_EVENTS method and uncomment the event you want registered. Then you redefine ON_DOUBLE_CLICK and add your specific logic. All the other processing of the class you inherited from is still in use. This will hopefully save our programming team lots of time as we develop custom reports.
37 Comments
