ABAP Object Oriented Approach for Reports – Initial Design

Many times, I see incorrect usage of ABAP Objects in custom development. In this two post blog series, I would show few incorrect designs and finally would show OO approach.

Incorrect Usage of Object Oriented

As part of my QA review responsibilities, many times, I see the report programs which are trying to use Object Oriented but would fail achieving any kind of object orientation. I consider these approaches as Pseudo OO Designs where the OO becomes just a vehicle to drive the procedural code. Something like this:

I would start this post with few bad examples. After them, I would take you back to procedural program – very simple program using subroutines. After that, I would show you the way I generally write Report programs using OO.

Only Static methods

Most of the times, I see developers are using only static methods in local class. Mainly the methods serve kind of wrapper to just have all the logic within it. Generally, there would GET_DATA and SHOW_DATA methods. This is not at all considered as Object Oriented design as there no objects involved only static method calls !

 
* Class definition
CLASS LCL_VALIDATION DEFINITION FINAL.
   PUBLIC SECTION.
     CLASS-METHODS :
              AUTHORITY_CHECK_TCODE,
              VALIDATE_CUSTOMER,
              VALIDATE_BILLING_TYPE.
ENDCLASS.
 

Basic problems using this approach

• The core logic of the report is hidden beneath the local classes in the program. As I have noted in when to use local class, this limits the reuse of the core logic
• Static methods along with other issues, lacks the basic advantage of method redefinition as we recently discussed in ABAP Static vs Instance method – Which to use when?

Wrapper methods to call Subroutines

Another flavor of what I generally face the design using the wrapper methods. You would see a method call in say START-OF-SELECTION, but that method would just call another subroutine. This subroutine would have more code modularization.

 
CLASS LCL_REPORT_PROCESS IMPLEMENTATION.
*
  METHOD GET_DATA.
     PERFORM F_GET_DATA.
  ENDMETHOD.
*
  METHOD FILL_FINAL_DATA.
     PERFORM  F_FILL_FINAL_DATA.
  ENDMETHOD.
*
  METHOD GENERATE_OUTPUT.
     PERFORM F_GENERATE_OUTPUT.
  ENDMETHOD.
*
ENDCLASS.              " LCL_REPORT_PROCESS IMPLEMENTATION
 

By simply looking at the design you would think what would be the benefit of using the methods as wrapper to the subroutines. This design has more issues than the previous one as this creates lot more confusion on which method calls which.

Use of Selection Screen Parameters & Select Options in the method implementations

All the time, whenever I see the OO ABAP used for any report, I see that developers are always using the parameters and select options directly in the method implementation. This makes the method impossible to use in any other way.

 
*
DATA: V_WERKS TYPE T001W-WERKS.
*
CLASS LCL_VALIDATION DEFINITION FINAL.
   PUBLIC SECTION.
     CLASS-METHODS :VALIDATE_PLANT.
ENDCLASS.
*
*
*...
* Validate Plant.
  METHOD VALIDATE_PLANT.
 
    IF S_WERKS IS NOT INITIAL.   " << Select Option
      SELECT WERKS UP TO 1 ROWS
             FROM   T001W
             INTO   V_WERKS
             WHERE  WERKS IN S_WERKS.
      ENDSELECT.
      IF SY-SUBRC NE 0 AND V_WERKS IS INITIAL.
"
      ENDIF.
    ENDIF.
  ENDMETHOD.                    "VALIDATE_PLANT
&#91;/abap_code&#93;
 
<h3>Global Variables instead OF Instances</h3>
IN this approach, developers TRY TO use the LOCAL Instance METHODS, but they still declare ALL the TYPES, DATA, Internal TABLES everything AS Global Variables. Many TIMES, these variables wont be used IN more than one place.
 
IN the code above, you can see that V_WERKS IS NOT declared locally IN the METHOD. There isn't any need for doing that.
 
You would find few of these issues in the post on SCN <a href="http://scn.sap.com/community/abap/application-development/objects/blog/2012/12/15/abap-oo--an-abapers-perspective" target="_blank" rel="nofollow">OO - An ABAPer's perspective</a>. I tried TO outline the similar design issues IN my <a href="http://scn.sap.com/community/abap/application-development/objects/blog/2012/12/15/abap-oo--an-abapers-perspective#comment-335366" target="_blank" rel="nofollow">comments</a> to the post.
 
<h3>Procedural Report</h3>
Lets take a step back AND think how this design can be improved. So, Start WITH this basic PROGRAM. PROGRAM has few subroutines TO validate the INPUT, GET the DATA AND generate the OUTPUT.
 
[abap_code slider="X" title=""]
*&---------------------------------------------------------------------*
*& Purpose - Simple procedrual report
*& Author  - Naimesh Patel
*& URL     - http://zevolving.com/?p=2037
*&---------------------------------------------------------------------*
REPORT  ztest_np_t100_report.
*
DATA: v_msgnr TYPE t100-msgnr.
DATA: v_arbgb LIKE t100-arbgb.
*
DATA: t_t100 TYPE STANDARD TABLE OF t100.
DATA: o_salv TYPE REF TO cl_salv_table.
*
SELECTION-SCREEN: BEGIN OF BLOCK blk1 WITH FRAME TITLE text-t01.
PARAMETERS:     p_arbgb TYPE t100-arbgb OBLIGATORY.
SELECT-OPTIONS: s_msgno FOR v_msgnr.
SELECTION-SCREEN: END OF BLOCK blk1.
*
AT SELECTION-SCREEN ON p_arbgb.
  PERFORM f_validate_message_class.
*
START-OF-SELECTION.
  PERFORM f_get_data.
*
END-OF-SELECTION.
  PERFORM f_show_data.
 
*
FORM f_validate_message_class.
  SELECT SINGLE arbgb
    INTO v_arbgb
    FROM t100
    WHERE arbgb = p_arbgb.
  IF sy-subrc NE 0.
    MESSAGE 'Message Class not found' TYPE 'E'.
  ENDIF.
ENDFORM.                    "f_validate_message_Class
*
*
FORM f_get_data.
  SELECT * FROM t100
    INTO TABLE t_t100
    WHERE arbgb = p_arbgb
    AND   msgnr IN s_msgno.
ENDFORM.                    "f_get_Data
*
*
FORM f_show_data.
  TRY.
      CALL METHOD cl_salv_table=>factory
        IMPORTING
          r_salv_table = o_salv
        CHANGING
          t_table      = t_t100.
 
      o_salv->display( ).
 
    CATCH cx_salv_msg .
  ENDTRY.
ENDFORM.                    "f_show_Data