Skip to Content
Technical Articles

selection criteria as a class

Dear community, in the openSAP course “Writing Testable Code for ABAP” was unit 1 of week 6 about working with legacy code. It was shown how to transform a procedural report into an object-oriented design with a class. The selection criteria, consisting of PARAMETERS and SELECT-OPTIONS, are transferred to the constructor.

Since there can sometimes be many selection criteria, I have thought about a dynamic solution. Below the core idea as a simple graphic (sorry, UML generation of my demo failed 🙁 … that’s the story for another blog):

In my little demo there is a local helper class called LCL_SELECTION_CRITERIA with access to PARAMETES and SELECT-OPTIONS (global variables) of the report ZSEL_CRITERIA_TEST. Therefore it is possible to transfer the selection criteria to an instance of a global class called ZCL_SEL_CRITERIA dynamically. Subsequently, the instance of this global class is passed to the constructor of another class called ZCL_SEL_CRITERIA_TEST where selection takes place and a small output is generated.

One of the nice side effects of presenting the selection criteria as a class is the possibility to automatically generate an identifier with more than 8 letters (for example “PA_BUKRS” is now “COMP_CODE”).

At the moment the whole thing is nothing more than a “Proof of Concept” and lacks of any error handling 🙂 You can download it from GitHub via abapGit.

What do you think about it?

 

Have fun

Michael

 

 

 

 

 

 

 

 

6 Comments
You must be Logged on to comment or reply to a post.
  • Hi Michael,

    that’s a good idea!

    I do not understand why you have your local class which does some important and general things. I am not totally sure but I think these methods should be placed in a global class. When instantiating the class you can provide the reports name to read the selection parameters. Or use CL_ABAP_GET_CALL_STACK=>GET_CALL_STACK to automatically get the callers select options. 😉

    To generalize the transportation of PARAMETERS and SELECT-OPTIONS to any class is really a great thing and could help a lot on testing.

    At least the RANGES table must not fit 100% to the used data! You can use CHAR50 as rollname for any SELECT-OPTIONS. I am not sure how it behaves on numeric values (INT etc), but most rollnames should do.

    Cheers
    ~Enno

    • Hi Enno,

      really fast reply 😉 Impressive!

      I thought a local class is needed to get access to the parameters and select-options of the report. If there is a design without the local helper class, that would be great because “keep it small and simple”.

      Just another question: Is there a chance to convert the methods GET_PARAMETER and GET_SELECT_OPTION to work with a RETURNING VALUE? I was looking for something like “DATA(lt_sel_opt_tname) = mr_sel_criteria->get_select_option( EXPORTING iv_name = ‘TABNAME’)” but that was not possible with something like “RETURNING VALUE(rt_sel_opt) TYPE any” 🙁

       

      Best regards and many thanks your comment

      Michael

       

       

       

  • serendipity 🙂

    Returning parameters must be be fully specified. 🙁

    Unluckily there are no implicit range-types for rollnames.

    As a workaround you might use some generic rangetab as mentioned above (like COCF_T_RANGE_CHAR80) and then work with “CORRESPONDING”.

    I am not sure why you would like to code “DATA(lt_sel_opt_tname) = mr_sel_criteria->get_select_option(…)” with inline data creation?! If you want to get back the select-options, I assume that you have the SELECT-OPTION declaration in your report…?!

  • Looks like a variant of the “Property Container” design pattern. You might want to read about that particular pattern to get some further inspiration.