How can I reuse elements of a Selection Screen or Data / Type declarations?

Question

I want to reuse elements on a Selection Screen or Data / Type declarations which normally belong into a top include. I have several Reports sharing several elements on the selection screen. The same Reports share various data elements in regards to the application log, hence the question of reusability.

Since the SAP Programming Guidelines states

Do not use include programs more than once .

Use an include program for the modularization of exactly one master program.

We strongly recommended using only suitable means for reuse, such as global classes or interfaces

I am looking for alternatives to achieve my goal.

The only way I can think of using a global class for this is by defining class attributes instead of the data declarations and use those as variables.

class->Attribute = desired_value

This seems a bit weird, albeit very close to how classes are used for constants. On the other Hand I could then just create a structure in the DDIC containing all desired declarations as components.

Macros would be my last idea and the only one concerning the Selection Screen elements.

DEFINE test.
  PARAMETERS: pa_delta TYPE c AS CHECKBOX.
  PARAMETERS: pa_date TYPE dats.
END-OF-DEFINITION.

TABLES: lfb1.

SELECT-OPTIONS: so_lifnr FOR lfb1-lifnr.
SELECT-OPTIONS: so_bukrs FOR lfb1-bukrs.

test.

How would you solve this Problem?

Answer 1

For the types you certainly should use classes or interfaces over includes for reuse.

interface ZIF_DEMO
  public .
   types: begin of myType,
            a type flag,
            b type i,
          end of myType.

endinterface.


REPORT zdemotype.
data gs type zif_demo=>mytype.
select-OPTIONS: s_a for gs-a.

As for the selection screen reuse. Thats a a little tricky to avoid.

See REPORT demo_call_selection_screen for some ideas.
If you have many programs that need such functionality you can submit one report from another. Or have 1 report with the selection screens with an initialization logic.

Note the statement submit also supports reference to a specific selection screen.

submit demo_call_selection_screen USING SELECTION-SCREEN '100'  and return.

Of course this raises the question do you want to run the program or just reuse the screen. In which case you will need to return the selection screen content via memory. In which case a function like RS_SELECTIONSCREEN_READ will prove useful. Infact the entire Function Group ALDB is worth a look if this topic is of interest.

But If I had multiple reporting problems that used similar and large selection options that were somehow how partly common and consistent I would use 1 driving program that just called different functionality that is in classes.

If the screens aren't so complex just copy the selection screen code. How much of DRY issue are you looking at before this is a concern.

Personally If was doing a code review and saw 10 programs with 1 common include and the only thing in that include was a selection screen and no data statements types or code, I would probably move right along. Especially if it contained a comment about why a common selection screen was necessary and the rest of the programs were well structured. Guidelines are guidelines. Maintainability and robustness is the goal surely. There are greater sins you might commit as an ABAPER :)

Answer 2

For selection screen elements, you may simply define subscreens. If elements are in several selection screens in the same program, you may also SELECTION-SCREEN INCLUDE.

Variables and types can be reused by modeling them into classes and interfaces. If you just put together variables that have no relationship between them into one class or interface, then it's just a bad idea and I would say that maybe defining one include program would not be the worst idea.

But as you only expose the final question (you come with only one solution to an original problem that we don't know), it's difficult to help better...