Manipulating entries in OBJH table

While working on transporting a table maintenance entry recently I came across interesting issue. Normally systems that have a purpose of test/integration/pre-production/production or similar are closed for customizing changes. It is a setting on client level in t-code SCC4 like:

Client Role = "Productive"

Cross-Client Objects Changes = "No changes to Repository and cross-client Customizing objects"

That means that customizing is not allowed to be performed in these systems. Such a systems are called as "non-changeable" systems or "production clients". Change of the customizing is normally only done via transports.

However, a particular customizing (or parameter) table can be set in a way that changes are allowed even in productive clients. To setup the table in that way there is a checkbox called "Current Settings" available in t-code SOBJ (Maintenance Object Attributes). The value is saved in table OBJH (Object: Header) and column OBJTRANSP (Flag for Transport Interface of Maintenance Object). That mean that even changes to client specific objects are not allowed, current settings in the client can be changed. The column OBJTRANSP can have one of these entries:

             No transport

1          Manual transport

2          Automatic transport

3          Transport is not required

 

There has to be a blank value of the column in order to make the table customizable. Only way, how change the column OBJTRANSP is to regenerate the table maintenance view from t-code SE42 or from SE11.

 

Initially, I was not sure what makes the table or not maintained. Only once, I debugged table maintenance view (function group TABLEPROC_<table_name>) I realized that value OBJH- OBJTRANSP is being checked.

More information:

356483 - In test system, behavior of customizing objects which are editable in production i.e. Current Settings

77430 - Customizing: Current settings

Transporting table maintenance view

I have done an activity of generating a maintenance view for table many times. However, even after that I still have some issues while moving the view across the landscape. Issue lays with the transport request that need to be prepared for the move. Normally when the objects are automatically collected into the transport request while they are being created, it should be all fine – all objects should be collected automatically. In case some objects were not stored in to proper developer class but they went to temporary class then they need to be collected manually. As with any manual activity, also this one is prone to errors.

Therefore, I came up with a list of objects that I look for in my transport to make sure all objects are collected before I release it.

 

R3TR     FUGR     <Z_function_group_name>

R3TR     TABL     <Z_table_name>

R3TR     TABU     TDDAT -> table keys: <Z_table_name>

R3TR     TABU     TVDIR -> table keys: <Z_table_name>

R3TR     TOBJ     <Z_table_name>X*

 

Line no 1 FUGR <Z_function_group_name> represents the function group name specified in the table maintenance generator (t-code SE54).

Line no 2 TABL <Z_table_name> represents the table which the maintenance view is generated for.

Line no 3 TABU TDDAT represents Maintenance Areas for Tables means the table Authorization Group that is also specified in t-code SE54. Is can be specified in t-code SE11 -> Utilities -> Assign Authorization Group. Stored in column CCLASS of the TDDAT.

Line no 4 TABU TVDIR represents View Directory itself, all info info given in the t-code SE54 are stored here.

Line no 5 TOBJ represents Definition of a Maintenance and Transport Object of the table involved. X* - can be specified in t-code SOBJ. It depends on particular table type, it can be either:

C        View Cluster

L        Logical transport object

S        Table (with text table)

T        Individual transaction object

V        View

D        Dummy object