Skip to Content
Author's profile photo Former Member

Developing a self-programmed customizing screen

Here’s the scenario I faced. I was required to create a screen which has some discrete fields that should be used to store some settings to be used across the application. As it is clear from the requirement, that this screen would be part of the SPRO customizing, that the customers can access when setting up the other standard customizing for the application, post-installation. For such a settings page, I certainly cannot use a standard SAP view cluster with maintenance screen generator, as the fields in question were of completely different types.

Thus I decided to use a simple executable program with a selection screen which has the different types of fields displayed, as required. I also created a simple DB table which has only 3 fields, MANDT and a key-value pair of fields. I then decided of specific ‘Keys’ for each field on the screen. These keys are nothing but unique 4 CHAR codes to identify each of the screen fields. And ofcourse the value of each key would be the value entered by user on the screen.

After this all it takes is to code simply to create entries into this DB table corresponding to the key-value pairs decided, at the AT SELECTION-SCREEN event. And ofcourse, reading the same key-value pairs during the INITIALIZATION event of the screen, to populate the screen fields with the already stored data.

The basic work is done; the screen is ready and when executed (F8) it works perfectly. But now I was faced with some additional challenges due to the fact that this program is supposed to be used like a standard SAP customizing by the customers of our application:

  1. Users are used to do a Save (Ctrl+S) on the standard customizing screens, and not an F8 to save the customizing values. But my program is a simple executable report, which comes with a free F8 option.
  2. The standard maintenance screen based customizing comes free with option to transport the saved entries. But our simple report doesn’t have that option.

So here’s how I accomplished the above two challenges, to make the self-programmed customizing screen fully compliant with the SAP standards.

Ctrl + S instead of F8

There could be multiple ways to achieve this. One of the ways I achieved this is as follows:

  • Create a GUI status for the program, say STAT
  • Under the GUI status, expand the ‘Function Keys’ area, and define the function codes exactly like the screenshot below:

GUI Status Screenshot

  • It is important to define exactly the same function codes above, as they’re the standard FCodes used internally by the Dynpro Selection Screen.
  • Once you’ve defined these, you can activate the GUI status and leave it.
  • Next we’d need to remove the standard selection screen F8 button, and replace it with our own GUI status. This can be done under the event AT SELECTION-SCREEN OUTPUT.
  • This event is nothing but the PBO of selection screen. Thus call the function module as below:
  DATA: lt_exclude  TYPE TABLE OF syucomm.
* Set the GUI Status to remove the Execute Button
* And make the Save Button work as Execute
      p_status  = 'STAT'
      p_program = sy-cprog
      p_exclude = lt_exclude.
  • Note that the internal table lt_exclude is not filled with anything. This makes sure, that the selection screen gets our new GUI status STAT, and also excludes nothing.
  • That does the trick for us. Now whenever a user selects the Save button on the toolbar above, or presses Ctrl + S keys to save, it automatically calls the FCode ONLI, which is nothing but the internal code for the default Execute (F8) button.

Transporting customizing entries

As we’re just creating/updating DB table entries on saving the customizing, all we got to do is to be able to add those table entries to a transport request, just like the standard view maintenance generator does.

  • As we already have our own GUI status, just add one more FCode to it, say TRNS. This can be added to a Function Key, say Shift + F9, as well as to the Menu with the same FCode.
  • Once added to the GUI status, you can use this FCode simply at the event:
  IF sy-ucomm = 'TRNS'.
    PERFORM just_transport.
  • This makes sure the form just_transport is called only when this FCode TRNS is summoned. This form may also be called immediately after the Save operation described above, so that the table entries get added to a transport request after saving.

Now diving inside this form just_transport.

I got the idea to do this from another very helpful blog of my colleague, Tarun Kamal Khiani.

Extending the idea given in Tarun’s blog, here’s what we can do:

  • Create the E071 entry in the same way as Tarun mentioned.
  • Create individual E071K entries for each of the keys of our DB table. As they’re discrete keys, we cannot really use a loop to create the E071K entries. So just append the entries one by one as follows:
  ls_e071k-pgmid      = 'R3TR'.
  ls_e071k-object     = 'TABU'.
  ls_e071k-objname    = 'ZKEY_VAL_TAB'.
  ls_e071k-mastertype = 'TABU'.
  ls_e071k-mastername = 'ZKEY_VAL_TAB'.
  ls_e071k-lang       = sy-langu.
* Transport Entry Key – Repeat the lines below for each Key entry
  ADD 1 TO lv_posn.
  ls_e071k-as4pos     = lv_posn.

  lv_tabkey = sy-mandt.
  lv_tabkey+3 = 'KEY1'.
  ls_e071k-tabkey     = lv_tabkey.

  APPEND ls_e071k TO lt_e071k.
  • Finally, before we add the entries to a transport request, we’d also like to check if the entries were already added to an open (modifiable) request, to avoid duplicate addition.
  • This check can be achieved as below (assuming the work-area ls_e071 is already populated as per Tarun’s blog):
  RANGES: lt_status     FOR e070-trstatus,
          lt_function   FOR e070-trfunction.
  DATA: BEGIN OF ls_request,
          trkorr        TYPE trkorr,
          trfunction    TYPE trfunction,
          trstatus      TYPE trstatus,
        END OF ls_request.
  lv_string        = 'DLPA'.
  lt_status-sign   = 'I'.
  lt_status-option = 'EQ'.
  WHILE lv_string <> space.
    lt_status-low = lv_string. APPEND lt_status.
    SHIFT lv_string.

  lv_string        = 'WK'.
  lt_function-sign   = 'I'.
  lt_function-option = 'EQ'.
  WHILE lv_string <> space.
    lt_function-low = lv_string(1). APPEND lt_function.
    SHIFT lv_string.
  SELECT SINGLE e070~trkorr e070~trfunction e070~trstatus
             INTO ls_request
             FROM e070 JOIN e071
             ON e070~trkorr = e071~trkorr
             WHERE e071~pgmid      =  ls_e071-pgmid
               AND e071~object     =  ls_e071-object
               AND e071~obj_name   =  ls_e071-obj_name
               AND e070~trstatus   IN lt_status
               AND e070~trfunction IN lt_function.
  • This query gives us a transport request of types either Workbench (W) or Customizing (K), which has status  modifiable (D, L, P or A), and contains the TABU entry for our table.
  • If this query does not return any results, then we can go ahead and add our table entries to a transport request by calling below API:
  IF sy-subrc NE 0.
        iv_request_types     = 'WK'
        iv_lock_objects      = 'X'
        iv_cli_dep           = 'X'
        it_e071              = lt_e071
        it_e071k             = ut_e071k
        invalid_request      = 1
        invalid_request_type = 2
        user_not_owner       = 3
        no_objects_appended  = 4
        enqueue_error        = 5
        cancelled_by_user    = 6
        recursive_call       = 7
        OTHERS               = 8.
    RAISE EXCEPTION TYPE cx_sy_no_handler.
  • This API call makes sure to ask for a transport request popup, and lets you choose or create only Workbench or customizing request.

This completes our development of an SAP standard compliant customizing with very less complexity and easy to maintain as well. You are ofcourse free to build upon this and extend it to suit your own requirements.

All the best! 🙂

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Sivaprasad ML
      Sivaprasad ML
      Dear Mithun,
      Thanks for posting a good development of course a rare one.. ALl the best. Looking forward for more such postings!
      Author's profile photo Former Member
      Former Member
      Hey Mithun,

      Really an impressive development for a complex requirement! 🙂 Well done..

      Kripa Rangachari.

      Author's profile photo Former Member
      Former Member

      Good Blog! Keep up the great work.

      Author's profile photo Gomatheeswaran Palaniappan
      Gomatheeswaran Palaniappan

      It's quite impressive.  Appreciate your effort.  It would be helpful if you could distinguish this with the project option available in SPRO screen.  We used to add preconfigured project (set of customization) as worklist in SPRO screen and double click on it.  The screen is different from std IMG.

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Thanks for your comments. Unfortunately I've not really worked on any such implementation where Projects are used for IMG. So I'd not be able to give my inputs for this.
      Moreover, this one is more focused on developers who'd be developing new screens for IMG, and I'm not sure if that happens so much outside SAP.

      Do you know if new IMG nodes(and screens) are created as part of customer implementation projects?