Skip to Content

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.

tab1.JPG

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:

Tab2.JPG

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

tab3.JPG

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:

tab4.JPG

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:

tran1.JPG

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

Tran2.JPG

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:

Tran3.JPG

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

tran4.JPG

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:

sobj1.JPG

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

sobj2.JPG

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:

sobj4.JPG

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.

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Gareth Ryan

    May I suggest you change the document title to “Data maintenance of custom tables on production system”?

    The current title suggests you are updating customer master tables in my head.

    Gareth.

    (0) 
  2. Nick Young

    Hi Klaus,

    Great blog, well structured and clear.

    There is one variation on the approach you describe, if the table is given Delivery Class A the same functionality can be achieved (without the need to update SOBJ).  Taking this approach would depend on whether the table needed to be included in a config-only client copy or not.

    Regards,

    Nick

    (0) 

Leave a Reply