ABAP: Generic customizing table with reader class
ABAP: Generic customizing table with reader class
If there is a need for new customizing parameters in customer projects, we usually create tables, views, view clusters, access routines and so on. What if we used one single table for this? We would have an unique access module and could store as many parameters as we want using an access key.
I used this approach for many years in a mid-range implementation with about 3000 Users. It makes the developing more straightforward when it comes to use settings stored in the database. After 4 years, about 250 different parameter keys accumulated in our generic table. In case we have special requirements such as proper validation of values against domains or check tables, we continue using normal customizing features, but in case of simple setup parameters, the generic table is very helpful.
ZP_GENCUST_DEMO_STRUCTURE)ZP_GENCUST_DEMO_MULTIPLE)There are two (identical) sets of customizing tables: ZDB_GENCUSTHD ZDB_GENCUSTIT and ZDB_GENCUSTHD2 ZDB_GENCUSTIT2. The latter ones are tables with no transport link. They are intended for maintaining directly in the production system (for example, if material numbers, customer codes, address numbers ore anything else concerning master data is to be stored). The others are normal customizing with link to the transport system.
I recommend creating two view clusters, for each pair of tables one. See the example here:
We also created parameter transactions (based on SM34) to quickly maintain the data.
The header table contains the following fields:
The item table has the following:
The reader class is instantiated by a factory:
settings_reader =
cond #(
when input = abap_true
then zcl_gencust_factory=>get_main_nocust( parameter_purpose )
else zcl_gencust_factory=>get_main( parameter_purpose ) ).
As shown in the example, there are two options: instantiate the customizing variant (ZDB_GENCUSTHD ZDB_GENCUSTIT) or the non-customizing one.
Reading the values
data(settings_value) = settings_reader->single( plant ).
The read methods implement the return pattern, thus they return an object that can be used to get the value that has been read, but also to determine if a value exists or not.
if settings_value->is_ok( ).
cl_demo_output=>display( |Value found: { settings_value->get_value( ) }| ).
else.
cl_demo_output=>display( settings_value->get_error( ) ).
endif.
Refer to the ZP_GENCUST_DEMO* reports to learn more about how to use the features