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
That it is interesting!
J.
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.
Thanks for the note. There is a book about design patterns in ABAP Objects that covers the topic … ?