topic Re: Dynamic selection-screen based on custom parameter table. in Application Development and Automation Discussions

Dynamic selection-screen based on custom parameter table.

former_member602116 — Fri, 26 Jun 2020 11:26:59 GMT

Hi Experts,

So I have a requirement with the following details:

1. Create a custom table that contains all the "Tasks". One task = One class in the program.

2. Create a dynamic selection screen using the fields "Tasks" in the custom parameter table. One task = one checkbox. (So selection-screen is only composed of checkboxes)

3. Whenever a new "Task" is to be added in the functionality of the program. We only need to add the "Task" in the custom parameter table and the program will now automatically create a checkbox for it. (The program does not need to be updated. Only a new class will be created for the new task's functionality).

Is this requirement feasible? I have tried searching in SCN but I have not found any with the same requirements as ours.

Thank you.

Regards,

Katherine Darunday

Re: Dynamic selection-screen based on custom parameter table.

MateuszAdamus — Fri, 26 Jun 2020 11:39:37 GMT

Hello kdarunday

It's not possible to create a dynamic selection screen.

Since you still have to create a new class for the new task's logic, you can at this very moment also change a selection screen. If you don't want to change the selection screen in the main report, you can define a selection subscreen in an include and change only that.

Another solution I see, more dynamic, is to have a normal field, not a checkbox, and allow user to populate this field with predefined values based on your configuration table. These values would mean the tasks that are to be executed. You could defined a custom search help to list these values to the user.

Yet another solution, although a bit more complicated, would be to write a report which would generate the selection screen for you, based on the configuration from the mentioned table. The selection screen could be defined in an include, to not change the main program (the logic).

Kind regards,
Mateusz

Re: Dynamic selection-screen based on custom parameter table.

ziolkowskib — Fri, 26 Jun 2020 12:50:53 GMT

Hi kdarunday,
Regarding the possibility of creating dynamic selection screen I would suggest reading through following topics:

SAP Help Portal - Dynamic Selections

SAP Help Portal - REPORT demo_free_selections
SAP Blog - Dynamic selection screen

Anyhow it's hard for me to understand the requirement or rather it's hard for me to understand why you need dynamic selection screen to fulfil it.
Regards,
Bartosz

Re: Dynamic selection-screen based on custom parameter table.

former_member602116 — Fri, 26 Jun 2020 12:52:53 GMT

Hi Mateusz,

Thank you for your inputs. I forgot to mention that everything will be made from scratch including the main program, we just wanted to think in advance that if ever in the future a new task/functionality will be added we would not want to touch the logic of the main program and just create a new class for the new task instead.

"Yet another solution, although a bit more complicated, would be to write a report which would generate the selection screen for you, based on the configuration from the mentioned table." I think this is exactly my requirement although we are not allowed to add include programs in our main program. (This is as per client's standards). So everything will be made from scratch and in only one program(with no includes) Do you have any idea how this could be done?

Thank you.

Regards,

Kath

Re: Dynamic selection-screen based on custom parameter table.

former_member602116 — Fri, 26 Jun 2020 13:05:18 GMT

Hi Bartosz,

Thank you for these. I have actually read through these links already.

I forgot to mention that everything will be made from scratch including the main program, we just wanted to think in advance that if ever in the future a new task/functionality will be added we would not want to touch the logic of the main program and just create a new class for the new task instead. This is the reason why we want the dynamic selection screen instead.

Thank you.

Regards,

Katherine Darunday

Re: Dynamic selection-screen based on custom parameter table.

Sandra_Rossi — Fri, 26 Jun 2020 13:08:43 GMT

You will never find the same kind of requirement twice in the world, whatever it's your requirement or another...

You have to turn requirements into small minimal technical pieces first, then search the world for each piece that you have issues with.

Based on what you say, I don't understand what issue you have. Each line of the table has to produce one checkbox. You can say that the number of checkboxes will be limited to say 50, and if it's above, probably the UI and the requirement will have to be thought again as it's difficult for a user to have so many checkboxes... (instead there should be more general criteria to choose categories of checkboxes or something like that)

Re: Dynamic selection-screen based on custom parameter table.

Sandra_Rossi — Fri, 26 Jun 2020 13:11:19 GMT

Or an HTML (CL_GUI_HTML_VIEWER) or an ALV grid (CL_SALV_TABLE/CL_GUI_ALV_GRID) in a Docking Container (CL_GUI_DOCKING_CONTAINER) aside the selection screen for instance...

(the choices can even be saved to program variants in case it's part of the requirement...)

Re: Dynamic selection-screen based on custom parameter table.

MateuszAdamus — Fri, 26 Jun 2020 13:13:38 GMT

Hello kdarunday

Writing from scratch is good news - you can plan and define everything so that it works as you like.

If you can't create includes then one option would be to have the whole logic in a global class and in the report have only the call to the report. Then you can change the selection screen of this report after each configuration change and not worry about the logic. I'd go with this solution.

Other one I see would be to have a simple report with selection screen and have this report call second report, more complicated one - with the logic, and pass the information about the selected tasks. After every configuration change you could regenerate the simple report, change the selection screen, but be sure that the report's logic is not changed (because it is in another report).

Kind regards,
Mateusz

Re: Dynamic selection-screen based on custom parameter table.

MateuszAdamus — Fri, 26 Jun 2020 13:15:46 GMT

If I remember correctly, the issue with these dynamic selection screen functions is that they use tables/structures that have to be defined in the ABAP dictionary. Which means that every time after adding a new Task to the configuration a structure would have to be changed, to add a new field to the used table/structure.

Kind regards,
Mateusz

Re: Dynamic selection-screen based on custom parameter table.

former_member602116 — Fri, 26 Jun 2020 13:16:05 GMT

Hi Sandra,

My only issue is if my requirement is feasible or not and that is to create a dynamic selection screen based on a parameter table.

Regards,

Kath

Re: Dynamic selection-screen based on custom parameter table.

ziolkowskib — Fri, 26 Jun 2020 13:35:55 GMT

Hi Katherine,
I'm not sure if I understand the idea correctly but let me share my thoughts.
I do not know who is the target user group to execute the report but assuming that they are familiar with SAP user interface then my idea would be to have one SELECT-OPTIONS (NO INTERVALS) with search help attached to it - values could be taken from some custom configuration table.
That field would present all available actions / tasks that are implemented and can be executed. User could add several tasks / actions and then execute the report. I would have a single "handler" class that would execute the corresponding method.
If I misunderstood the requirement then sorry for that and please ignore my comment 🙂
Regards,
Bartosz

Re: Dynamic selection-screen based on custom parameter table.

Sandra_Rossi — Fri, 26 Jun 2020 14:33:14 GMT

I answered after Mateusz who said that it's not possible to create a dynamic screen (you can find this answer a lot of times in the forum too). So, what I meant, is to define 50 check boxes, hide those that you don't need. If in the future you have more check boxes, I think the solution will have to be reviewed, as it's not a good user experience to have a so big list).