Data maintenance of custom tables on production system

Szenario

You want to create a custom application, which needs a customizing table with different content on development, quality and production servers. Therefore you want to maintain the table content directly on all systems without transport requests.

Example

You have to create several monitoring reports with e-mail messages to different receivers. On development system all messages should be sent to the developer, on quality system to a tester and on production system to the assigned users.

Defining a new customizing table

Define a customizing table. In menu Delivery and Maintenance set Delivery Class to C and Data Browser/Table View Maint. to X.

Design the table information you need. Don’t forget to put the client as 1st key field, because it is much easier to maintain client dependent data on a production system than client independent data.

In this sample I have created a shorthand symbol named service for the different reports, but the report name itself also might be a good idea for the 2nd key field. As a 3rd key field  I have added a sequence number to inform more than one receivers for each service (report) on production system.

Last I have added the smtp address as a non-key field:

In the Technical Settings it is important to set the Log data changes flag for data tracking: 

Then the Enhacement Category has to be selected and the table can be activated.

Generating the Maintenance View

In Utilities(M) menu the Table Maintenance Generator must be called to create the maintenance view for the new table. For our requirement, there should be option no, or user, recording routine selected:

After finishing the view generation, we are able to maintain the table data in transaction SM30.

Creating a Parameter Transaction

For security reasons transaction SM30 shouldn’t be available for the majority of users in a production system. Therefore we should create a parameter transaction in SE93:

We have to set Transaction to SM30 and to mark the Skip initial screen checkbox:

Now in Default Values table at the bottom we can select screen field names from a dropdown list and pass values to them. For table maintenace we need field UPDATE and set the value to X and field VIEWNAME with value of our new table name:

If we have need for a 2nd parameter transaction for display purpose only, screen field name UPDATE has to replaced by name SHOW:

Role Administration

This or these new customer parameter transaction(s) must be assigned to new or existing roles for all users, that need to use the new transaction(s). This role updates have to be transported into development, quality and production systems.

Allowing maintenance on production system

Now we have prepared all for authorized users to maintain our new table on production system, but production client will still deny table changes. To avoid this, we have to call transaction SOBJ and choose the maintain option:

After ignoring the cross-client warning we can press the Position button

to position on our new table.

Then we mark the line with the new table and doubleclick it. In the attributes the checkbox Current Settings has to be marked:

Then we have to save this setting, which also needs to be transported to production system

Remark

After generating the table maintenance view anew, the Current Settings option may be lost. Then you have to call transaction SOBJ again to correct it.

Watching table updates

Report RSVTPROT can be used to watch all table updates from users and also by transport requests.