key value pairs (in persistent storage)

[Former Member]

Hi experts,

in our application, i want to have some conguration parameters with values (in persistent storage) to be set by the application owner. these values determine the behaviour of the application.

few parameters are:

appl_country , possible values: Canada, UnitedStates

is_trace_enabled, possible values: X, or space

print_record_count, possible values: any integer value.

for this, i have created a table ztable_config, with fields

MANDT

PARAM_NAME  (primary key), type char20

PARAM_VALUE, type char50

the user needs to enter data into this table, so created a maintence view of the table.

before giving the application to the user, i added all the param_names into the table, with blank values.

asked the user to fill appropriate values in the params in the sm30 of ztable_config.

but that did not restrict him to delete few params, that are imp for application.

he deleted by mistake, and tried to recreate but he used some different spelling etc, so finally the application developer had to get into to recreate the actual parameter.

is there any way we can restrict the user not to delete rows, but need to able to edit the non-primary key fields.

is there any better way to manage the key value pairs that can be used as config params for any application.

thanks,

Madhu

[Former Member]

Hi experts,

in our application, i want to have some conguration parameters with values (in persistent storage) to be set by the application owner. these values determine the behaviour of the application.

few parameters are:

appl_country , possible values: Canada, UnitedStates

is_trace_enabled, possible values: X, or space

print_record_count, possible values: any integer value.

for this, i have created a table ztable_config, with fields

MANDT

PARAM_NAME  (primary key), type char20

PARAM_VALUE, type char50

the user needs to enter data into this table, so created a maintence view of the table.

before giving the application to the user, i added all the param_names into the table, with blank values.

asked the user to fill appropriate values in the params in the sm30 of ztable_config.

but that did not restrict him to delete few params, that are imp for application.

he deleted by mistake, and tried to recreate but he used some different spelling etc, so finally the application developer had to get into to recreate the actual parameter.

is there any way we can restrict the user not to delete rows, but need to able to edit the non-primary key fields.

is there any better way to manage the key value pairs that can be used as config params for any application.

thanks,

Madhu

[amy_king]

Hi Madhu,

Instead of a z-table, you could store your parameter name/value pairs in table TVARVC. We use the table for this purpose. The table can be maintained with transaction STVARV.

Cheers,
Amy

[Former Member]

Hi Madhu,

You could use table Maintenance events to achieve your requirement.

Have a look at this URL on how to handle  table maintenance events.

http://wiki.sdn.sap.com/wiki/display/ABAP/TABLE+MAINTENANCE+GENERATOR+and+ITS+EVENTS

I would think Auth Obj S_TABU_DIS would not be of much help as ACTVT '02' is for create, change and delete. So, you may have to create a Z auth object  and control the list of permitted activities for the user. You may want to add the table key fields to the authorization object as it gives more control and granularity, you can avoid this if you are doing a basic check .

Do the authorization check in the Table event "before_save" -> '01'.

Within the Event handler subroutine write your code similar to this.

FORM ztest_before_save.
  LOOP AT total.
    IF <action> = 'D'.

Check for authorization. ->Z authorization object
     IF sy-subrc NE 0. 

     MESSAGE e021(zxx) .
     ENDIF.    

ENDIF.
  ENDLOOP.
ENDFORM.                    "ZTEST_BEFORE_SAVE

There is however one catch though, an error message raised would throw you out of the current dialog ( Sort of teaching them a lesson ) and would  return you to the initial screen.

I Hope this helps.

Thanks,

Venkat.