Getting the basics right – Creating the perfect config table (Part 1, The Table)

[Former Member]

When we build our own development we are frequently required to create config tables ourselves and it's easy enough to create something adequate in SE11.  But with the correct settings a custom config table can integrate seamlessly into the standard SAP config tasks.

By a config table I mean a table of mainly static values that is configured and transported through the system landscape.  Here we'll use an example of a new config table with three fields; Sending Country (Domain LAND1), Receiving Plant (Domain WERKS), Surcharge Flag.  Country and plant is the key.

So, into transaction SE11 to create the table.

Give the table a name and description that fit your local development standards.

On the Delivery and maintenance tab,



Delivery class - C, obviously this is a config table after all.  This is used in client copy (particularly if you choose the config-only profile) and while setting values other than C can stop a table being transportable, setting it does not force the table to be so.

Data Browser/Table View Maint. - Set it to ‘Display/Maintenance Allowed', as once we've created this config table we're assuming someone will want to put some settings in it.

Defining the Fields

I've created three new data elements (ZLAND1 with domain LAND1, ZWERKS with domain WERKS and ZSUR_FLAG with domain BOOLE) for my three fields.  We could use standard data elements but in this example I need specific texts to describe the fields.



Foreign keys are import at this point.  If when I generate my maintenance dialog I want the fields to be validated against a check table then I need to define a foreign key.  Also, the foreign key will define the search help for the field.

Click the Foreign key button  and if the domain for the field includes a check table this will be proposed for the foreign key.



Because I've used standard domains with check tables defined I simply accept the proposal and repeat for each field.



Technical settings



Switch on buffering as this is a table with data that changes infrequently.

Set the checkbox for Log data changes.  This means that if the parameter rec/client is set the change history of your table contents will get recorded.

Before you activate your table, set the enhancement category.  Use menu Extras -> Enhancement Category...



For a config table such as this the setting has little meaning, so ‘Cannot Be Enhanced' will do.  It's worth setting as otherwise warning messages are generated every time the table is activated.

Maintenance generator



Authorization Group.  Always use a meaningful authorisation group, by which I mean don't use &NC&.  In CRM there are over 2000 and in ERP over 9000 tables delivered with the &NC& authorisation class (check TDDAT if you don't believe me).  If you use &NC& you will unavoidably have to give authorisation to all of these tables.  And your security team won't like that.  If your config table relates closely to some existing standard config use the same class as that table, or use a customer created class.  It's not necessary to create hundreds of classes, one for each module or workstream is usually enough.

Function Group.  I would always make the function group the same as the table name; no need to create it first the generator will do this for you.  It is possible to use the same function group for multiple tables, but offers little benefit and less flexibility.  Never use a function group containing manually created function modules as regenerating the maintenance modules can delete elements of your manual function modules.

Recording routine.  This is the key to integrating the table into the transport landscape (which, as it's a config table we're keen to do).  Set this to ‘Standard recording routine'.  This will mean that if the client is set for ‘automatic recording of changes' your config changes will be captured in a transport, and also that if the client is set for no config changes your table will be display only.  If this section is greyed out it is because the table has been assigned to package $TMP, the system is smart enough to know that if you can't transport the table definition you should not be able to transport the contents.

 

So, there's our config table defined, and can be maintained in transaction SM30.



What we have is a table with a look and feel consistant with SAP-delivered config and fully integrated into the transport system.  From here we can use other techniques to further integrate our tables with SAP-delivered config.