Every implementation project will produce a wide variety of developments that will require settings to be stored somewhere. Numerous tables will be created, more often than not holding only a handful of records. This blue print should be implemented very early on in the project...
Description
A solution for "development customizing" is remarkable easy to implement and has enormous advantages. In effect a single table will be created which will hold the "development customizing" settings for the whole implementation. 1 table to control all, set up in a clever way.
Goal and objectives
The goal is overall simplification. If a development customizing table is at hand and everybody knows about it, there is no need to create small tables and the job of maintaining the system becomes a lot easier to do. A streamlined approach to the tables that will be needed on any implementation is also a good way to ensure hard-coding of values can easily be avoided.
The blue print
Base setup
In our project as in any project there will be the need to store "customizing data for development" such as:
- a list of company codes that are relevant for specific processing
- a list of the sales organisations that should be excluded from a certain selection
- a translation table to determine the purchasing group
- logging flags to switch certain logs on and off (in custom build developments)
The concept: ZDEVCUS is itself a transparant (client dependant) table with a generic setup, which can hold information about different object types and field qualifiers.
- The object type is used to identify the development (or group of developments) for which
ZDEVCUSis set up. e.g. "POCREATE" with "Create the PO from the PR - ZUMAPO01". The object type is a 10 character field with it´s description. - The field qualifier is used to identify which field is set up in the specific
ZDEVCUSrecord, e.g. "COCO" with it´s description "Company code". Field qualifiers are 4 characters in size.
Once object type and field qualifier are filled in, the key field can be filled. This is the actual data that ZDEVCUS is containing, e.g. and actual company code.
Transparent table ZDEVCUS can be selected on from any ABAP coding, and it can be maintained via SM31.
When a technical design is worked out, please be aware of ZDEVCUS´s strength following this checklist:
- Number of entries expected in the require table ? (<100
ZDEVCUSvery suitable, <200 reasonably suitable) - Is the data transactional ? (
ZDEVCUSnot suitable) - Is the data not changed very often ? (
ZDEVCUSsuitable) - Is the required data client dependant ? (
ZDEVCUSsuitable) - Would the requirement fit into
ZDEVCUS´s setup ? - Is the creation of a new table and table maintenance justified ?
SM31: shows data entry fields. SE16: shows actual contents
Where ZDEVCUS is used, the actual object-dependant data can be maintained (or displayed) using function module Z_MAINTAIN_DEVCUS.
Taking it further...
Once the idea has established itself (which will be remarkably fast, if it is explained clearly in the beginning) the overall maintainability of the table can be somewhat enhanced by a report.Information about the objects maintained can be maintained on the same table, as meta-data.
Pro's and cons
|
|
Success story
Tables ZUXCUSDAT with IBM, ZTYPE1 and ZTYPE2 with Sony (horrible names, bet hej..), ZU_TVARV with Schlumberger... This approach is available in some form on every serious implementation. Potentially multiple times ! Tables ZHRC_CONTROLS for HRchannels control parameters and ZHRD_CONTROLS for HDdocuments parameters. These tables also include an Active field, a preview of the used field definition (key fields underlines)
MANDT MANDT CLNT 3 Mandant OTYPE ZHRD_OTYPE CHAR 1 Object type OBJECT ZHRD_OBJECT CHAR 14 HRdocuments controls - object key FTYPE ZHRD_FTYPE CHAR 3 Field type FIELD ZHRD_FIELD CHAR 25 Field name ACTIVE ZHRD_ACTIVE CHAR 1 HRdocuments - Active VALUE ZHRD_VALUECODE CHAR 20 Value code, controls settings VALUE_LONG ZHRD_VALUE CHAR 120 Value (long, lower cased)