Skip to Content

Program Parameters vs hardcoding

     *Introduction*  I’ve experienced many times the situation when users were absolutely 100% sure that some value (for example, tax code) will never ever change, not in a million years, for some functionality that I was doing development on. I believed them and hardcoded it, since it was the easiest and fastest way. And later, when the program got to final development phase, or even productive, they remembered an exception which got me in trouble. I had to change the code. Although at first glance a trivial problem, it caused me a lot of frustration and headaches.  I’ll describe here a component which enables storing and editing fixed (constant or rarely changed) values in programs or program parts. It’s object-oriented, and works in a flexible way, with no need to create additional dictionary components.       *Unload your burden to users*  My experience is that a developer must always avoid responsibility for data in program, even if the user is absolutely sure that some value wouldn’t change. You must never trust this. It’s better to always let the users decide in program runtime and be fully responsible, so that they can’t bother you later. You should parameterize as many values as you can. And if they’re really not expected to change, place a tiny command button somewhere aside, where it doesn’t distract the users in daily work.  Classical options to do this require a lot of application-specific coding and/or creating dictionary objects for each application or application part. You’ll have to maintain and transport those objects. These are pretty time-consuming and inflexible solutions. It’s also boring and frustrating work and you’ll always be tempted to hardcode. *What to do with fixed values in program?*  It’s not always easy to decide what to do with rarely changed, constant and “constant” values in your programs.  What are the options?  0.1.   0.2. hardcoding: no doubt the worst possible solution   0.3. selection-screen parameters: The worst thing is that selection-screen  variables are global for the program. They don’t really fit to the objects  world, the code becomes hard to maintain and it’s easy to get lost when it  becomes big. Besides, users will hate you if they’ll have to enter the values  each time they start the program, which you can overcome by PID parameters.  However, it would mean another set of DDIC components to maintain. 0.4. Z tables: a generic Z* parameters storage would not be bad, but a simple and intuitive UI must be built – coding effort   0.5. generic storage (such as INDX table): also a good option, but requires coding effort        *The component to wrap INDX table*  My goal was to create a flexible and simple reusable component which would require as little as possible Z* DDIC components specific for application.  I decided to use the special table: INDX, where you can store and retrieve all types of data – simple variables, internal tables… There are even special ABAP statements for this purpose:   0.1.   0.2. EXPORT obj1 … objn TO DATABASE dbtab(ar) ID key. 0.3.   0.4. IMPORT obj1 … objn FROM DATABASE dbtab(ar) ID key. 0.5.     I abstracted the table and all the coding within (at least 2) little dictionary classes:  0.1.   0.2. ZCL_PROG_PARAMS – an abstract class which handles data maintenance in db 0.3.   0.4. ZCL_PROG_PARAMS_* – subclasses which implement UI – my only implementation so far is with ALV grid 0.5.     I abstracted data maintenance from user interface to enable access to the same data by different technologies. Like this:  image    *Usage*  Usage is simple. You only have to initialize the component with a unique database key (for INDX table), and name the parameters that user needs to maintain.  There are two ways to define the parameter’s description:  0.1.   0.2. by reference to a dictionary domain  0.3. by freely entered text   A simple foreign key check against a check table is also possible.  Unfortunately, I wasn’t able to attach specific search help to each cell.   It works like this:   *   initialize parameters     “country     CLEAR s_parameters.     s_parameters-par_name    = ‘COUNTRY’.     s_parameters-domain      = ‘LAND1_GP’.     s_parameters-checktable  = ‘T005’.     s_parameters-checkfield  = ‘LAND1’.     APPEND s_parameters TO t_parameters.     “company code     CLEAR s_parameters.     s_parameters-par_name    = ‘COMP_CODE’.     s_parameters-domain      = ‘BUKRS’.     s_parameters-checktable  = ‘T001’.     s_parameters-checkfield  = ‘BUKRS’.     APPEND s_parameters TO t_parameters.     “some custom named parameter     CLEAR s_parameters.     s_parameters-par_name    = ‘DUMMY’.     s_parameters-description = ‘Freely entered name’.     APPEND s_parameters TO t_parameters. *   create object     CREATE OBJECT o_pars          EXPORTING i_id          = ‘SOME_UNIQUE_KEY’                    it_parameters = t_parameters                    i_title       = ‘Title’.   It’s very easy to get values into your program. Just one statement:  v_comp_code = o_pars->get_value( ‘COMP_CODE’ ).      You start the UI (editor) with a single statement too:  CALL METHOD o_pars->edit.    and it results with:      If user enters invalid value and tries to save, the foreign key check issues an error message:        Another expected functionality: if value changes and user tries to close, an options dialog pops up:   
You must be Logged on to comment or reply to a post.
  • Hi Igor

    I am atttempting to implement this on a 46B machine.  Looks like there is no data_changed event which has stopped me dead in my tracks.

    Any ideas???


    • Hi, Ian!
      Sorry to hear that ALV grid on 46B doesn't have DATA_CHANGED event.
      However, there's an easy solution:
      You simply delete the method ON_DATA_CHANGED from the class ZCL_PROG_PARAMS_ALV, and delete the line "me->on_data_changed FOR me->o_alv," (this is registering event) from the method EDIT of the same class.
      You'll have the entire functionality without foreign key check.
      Please tell me how is it going! Did you import the request or create the components manually?
      Kind regards,
  • Hi Igor,
      I'm new to ABAP Objects but find your blog very interesting, trying to implement your code manually but hit a small problem:  Since all the methods for Class ZCL_PROG_PARAMS_ALV are event handlers, I'm a bit lost and don't quite know how to define these methods. What do I need to do ? Can you please show me step-by-step how to do these methods ? My email is
    • Hi, Ruong!
      I understand from your email that you figured it out by yourself. I am happy to learn that my old weblog is still useful.
      Good luck!
  • Hello,
    I am wondering how you can get the cell-borders  to be colored red without the options dialog pops up showing the errors? is this possible?

    regards Ballo

    • Hi, Ballo!
      Not that I am aware. I am producing both red border and dialog popup simply by adding protocol entries to object which is parameter of CL_GUI_ALV_GRID event DATA_CHANGED. Namely, it's  ER_DATA_CHANGED->ADD_PROTOCOL_ENTRY within my ON_DATA_CHANGED method. There's nothing more I do. I can see that object ER_DATA_CHANGED (of the class CL_ALV_CHANGED_DATA_PROTOCOL) has method PROTOCOL_IS_VISIBLE. Maybe you can try calling this method with parameters 0 or 1 (like ER_DATA_CHANGED->PROTOCOL_IS_VISIBLE( 0 ).) I can't do it now - I don't have access to system at the moment. If you find the solution, please post here.
  • HI,

    I could not activate this class

    Initially i got an error for  ON_DATA_CHANGED, and as per the comments i deleted this method and deleted the line "me->on_data_changed FOR me->o_alv" also from the method EDIT.

    After this I received the error message:

    "The field 'MT_TOOLBAR' is unknown ."
    Will yoube able to help me.