Recently in ABAP Development one of the requirement about dynamically create screen parameters? was about creating selection screen dynamically from the entries that are being maintained in the database table. Although there is no straight-forward approach for the solution, it could however be done dynamically by creating ABAP code at runtime, such that the code contains the selection screen fields and executing it. The only other option would be to include all the anticipated selection screen fields in the program and to hide the screen fields at runtime. This technique however becomes cumbersome and more coding will be required if the number of fields is too large.
Consider the following scenario:
- The user maintains a table consisting of the selection-screen parameters
- When the report program is executed a screen must be generated dynamically with only the parameters that have been defined in the table
- After the user has made entry in the selection screen, the data should be returned back to the main program and the processing should continue as per the program flow
A custom table ZSCRFLDS is created which holds the selection screen fields that is to be created.
The table structure is as follows:
The mapping between the fields of the table ZSCRFLDS and the ABAP selection screen fields is illustrated below:
Implementation of Logic:
- Retrieve the required selection screen fields specified in the table ZSCRFLDS into an internal table GT_SCRFLDS
- Create a internal table of type ABAPTEXT to store the ABAP code that is to be generated dynamically
Now that we are going to create selection screen fields dynamically, we need to create TABLES declaration in ABAP code for the SELECT-OPTIONS fields.
SELECT-OPTIONS S_MATNR FOR MARA-MATNR.
The tables workareas for the SELECT-OPTIONS fields is then generated.
- The next step is to generate the declaration for parameters and select-options.
PARAMETERS P_MATNR LIKE MARA-MATNR.
SELECT-OPTIONS S_MATNR FOR MARA-MATNR.
The program code for this has been generated by checking the BASICTYP field, which specifies whether the field is a parameter or select-option.
After creating the code for all the defined selection screen fields, we need to have a processing routine in the generated ABAP code so that the values that are entered in the selection screen are stored and returned to the main program.
Since ABAP Shared Objects are quite unexplored, I decided to use them in the program to store the entries made in the selection screen fields into the Shared Objects Memory from which I could retrieve them.
For those new to ABAP Shared Objects Thomas Jungs blog on Netweaver for the Holidays: A Lession in Sharing (ABAP Shared Memory) would help.
For implementing Shared Objects, I have created a new root class named: ZCL_SELSCR with Shared-Memory Enabled turned on. A private attribute named RANGES of the data type ACE_FIELD_RANGES_T is also created in the class.
The data type ACE_FIELD_RANGES_T is a deep structure type with FIELDNAME to store selection-screen field names and a FIELDRANGE table containing the fields: OPTION, SIGN, LOW and HIGH.
I have created two public methods for accessing this attribute.
Next I created Area Class ZSELAREA using the transaction SHMA
The code to export the data to the Shared Memory is added at the START-OF-SELECTION event of the generated program and followed by LEAVE PROGRAM to return back to the main program
- Now the generated program is created using the ABAP command INSERT REPORT:
INSERT REPORT ‘ZDYNSELSCR’ FROM gt_prog.
- Now that the code is generated, we can execute the generated program in foreground using SUBMIT statement.
SUBMIT ZDYNSELSCR VIA SELECTION-SCREEN AND RETURN.
- The program ZDYNSELSCR is executed and the selection screen is displayed. In the START-OF-SELECTION event of that program the data is uploaded to the Shared Memory.
- In the main program the selection screen entries can be read from the Shared Objects and then the further processing can be done
The ABAP Code:
However, this is a sample program which illustrates handling parameters and select-options. However this could be extended to include checkboxes and radiobuttons and other selection screen fields.
I was rather unsuccessful in maintaining the text-elements of the selection-screen fields dynamically using code. I have temporarily solved the problem using selection-screen COMMENT fields and initializing these variables in the INITIALIZATION event. It would have been better if I could find a way to sort this out.
Thanks for reading this blog. If you have any comments/suggestions please post them here.