New transport interface in extended table maintena (SAP Library

New transport interface in extended table maintenance (view maintenance)

Description

The transport interface for extended table maintenance has been changed in 3.0A (view maintenance, SM30).

In addition to the manual transport option, which exists since 2.0, there is now an automatic transport interface where all the changed entries are taken over into a change request to be specified when you save the object.

This new function is always active for client-independent objects and objects of delivery class "S". For client-specific objects it is active when required by teh client (see Changes and transports for client-dependent objects on the client table maintenance screen).

In addition, the new function can be deactivated for individual objects using the Transaction "Generate table maintenance dialog" (SE54; field Recording method).

Software/hardware requirements

You have to carry out the actions described in the following only if you have created your own table maintenance dialogs using the program RSVIEWGN or Transaction SE54 before Release 3.0. For the objects delivered by SAP, these actions have already been performed, i.e., no action needs to be taken.

Due to the changed transport interface for extended table maintenance, the generated components of the table maintenance dialog also had to be changed and must be re-generated.

If you have your own routines in your table maintenance dialogs to include other tables maintained via individual modules, you have to make minor changes in these modules.

Actions required

1. Re-generate the table maintenance dialog for customer objects (objects not delivered by SAP).

We recommend that you use the program RSVIM30A to re-generate the table dialog. You can pass on tables or views or function groups to this program via selection options. Specify the tables or views or function groups for which you have created your own table maintenance dialogs using the program RSVIEWGN or Transaction SE54 before Release 3.0. For more information about the program RSVIM30A please refer to the program documentation.

2. Transport the objects generated subsequently

If you have several SAP Systems, you need to distribute the generated objects from within the original system. The objects changed by the program RSVIM30A are logged automatically in a change request (for details refer to the program documentation). You can transport this request to the other systems.

If you do not have separate FORM routines in your table maintenance dialogs to include other tables maintained via individual modules, all the required actions are now completed.

However, if you have used such routines, you have to edit the routines and transport them. You need to perform these actions for all the tables or views for which Table TVIMF contains entries for the events 10, 11, and/or 12.

FORM routine for entering additional tables in the change request (event "10" - after generating the header entries of the change task (E071))

Because of the introduction of the new transport object R3TR VDAT and the enhanced functionality of the transport object R3TR TABU it is no no longer necessary (or may even cause problems) to list the tables that belong to the maintenance object (SM30 object) individually in the change task. The logical connection will be lost afterwards and is cannot be derived from the change task.

Therefore please use the new option to assign the additional tables in the maintenance object definition list (Transaction SOBJ) to the respective maintenance object. The logical connection is thus retained.

Actions:

Delete the TVIMF entry when the event 10 occurs.
Call up the transaction "Generate table maintenance dialog (Tools -> ABAP/4 Workbench -> Development -> Other tools -> Gener.tab.maint.dialog). Choose Environment/> -> Events.
If you do not need the coding of the FORM routine any longer, delete the routine using the ABAP/4 editor.

Include the additional tables in the maintenance object list (Transaction SOBJ).

Note:

You can still use your own FORM routines to transport tables that are not specified in the maintenance object list. However, a separate header entry (R3TR TABU) is then required for these tables in the change task. The connection between these objects cannot be seen from the change task. If you wish to do this, you have to change the FORM routine so that it generates only R3TR TABU entries for the tables that are not in the maintenance object list. The entries cannot be written directly to the change task (the routine FCOMMAPPEND(RDDCORRD) was previously used for this); you now merely have to fill the global internal table VIM_CORR_OBJTAB . This table has the structure E071. For more details refer to the example below.

FORM routine to append the keys of additional table entries for a table or view entry (Event "11" - after changing a key entry in the change task (E071K))

This routine appends the key entries for the additional tables that belong to an entry of the maintenance object to the internal table CORR_KEYTAB (structure E071K ). Previously the additional table was entered as a master object (CORR_KEYTAB-MASTERTYPE = 'TABU'. CORR_KEYTAB-MASTERNAME ='......'. This is now required only for those additional tables that are not included in the maintenance object list.

However, the maintenance object must be specified as a master object for those tables that are included in the object list. This has already been carried out in the global variable E071K, i.e., after initializing the CORR_KEYTAB with E071K (CORR_KEYTAB = E071K), the assignments for CORR_KEYTAB-MASTERTYPE and CORR_KEYTAB-MASTERNAME can be deleted.

You can also assign the global variables MASTER_TYPE or MASTER_NAME.

Actions:

Change the FORM routine as described above.

FORM routine to append the keys of the additional table entries (Event "12" - after changing the key entries of the change task (E071K))

This routine appends the key entries for the additional tables, which do not necessarily belong to an individual entry of the maintenance object, to the internal table CORR_KEYTAB (structure E071K).

The same applies as for the FORM routine at event 11.

Transport the changes

If you have several SAP systems, you have to distribute the changed FORM routines from within the original system.

Example:

Maintenance object: View AROTA01

1. View definition in the dictionary

Table	Comments
T9AR_TA1	Primary table, changeable
T9AR_TA1T	Text table for primary table, changeable
T9AR_TA1S	Secondary table, changeable
T002	Secondary table, not changeable
T002T	Secondary table, not changeable

2. List of maintenance object description (Transaction SOBJ):

Table	Comments
T9AR_TA1	contained in view
T9AR_TA1S	contained in view
T9AR_TA1T	contained in view
T9AR_TA2	not contained in view

3. Additional table to be maintained (not included in the list):

T9AR_TA3

4. FORM routines for the transport interface:

Routine to enter additional tables in the change request
(Event "10" - after generating the header entries of the change request (E071))


*--------------------------------------------------------


*   FORM E071_AROTA01


*-------------------------------------------------------


* Filling VIM_CORR_OBJTAB with additional objects.  Only

* objects that are NOT listed in the object description

* list (SOBJ) are to be included here.

* In this case, only Table T9AR_TA3 is relevant.

 -------------------------------------------------------*


FORM E071_AROTA01.

  VIM_CORR_OBJTAB = E071.

  VIM_CORR_OBJTAB-PGMID    = 'R3TR'.

  VIM_CORR_OBJTAB-OBJECT   = 'TABU'.

  VIM_CORR_OBJTAB-OBJ_NAME = 'T9AR_TA3'.

  VIM_CORR_OBJTAB-OBJFUNC  = 'K'.

  APPEND VIM_CORR_OBJTAB.

ENDFORM.

Routine to append the keys of additional table entries for a table or view entry
(Event "11" - after changing a key entry of the change task (E071K))


*---------------------------------------------------------


*   FORM E071KS_AROTA01


*---------------------------------------------------------


* Filling CORR_KEYTAB with the key entries of the

* additional objects that belong to the current view

* entry.  When the call is executed, this entry is in the

* corresponding work area.

*---------------------------------------------------------


FORM E071KS_AROTA01.

DATA: RC LIKE SY-SUBRC, RC_SAFE LIKE SY-SUBRC VALUE '1'.



* 1. Additional object: T9AR_TA2 (included in

*    object list):

* Build up CORR_KEYTAB entry (E071K):

* 1.1 Initialize with E071K (global settings)

  CORR_KEYTAB = E071K.

* or:

* CORR_KEYTAB-TRKORR     = E071K-TRKORR.

* CORR_KEYTAB-PGMID      = TRANSPORTER.    "R3TR

* CORR_KEYTAB-OBJECT     = TRANSP_OBJECT.  "TABU

* CORR_KEYTAB-MASTERTYPE = MASTER_TYPE     "VDAT

* CORR_KEYTAB-MASTERNAME = MASTER_NAME     "e.g.AROTA01

* 1.2 Specify individual object name

  CORR_KEYTAB-OBJNAME = 'T9AR_TA2'.

* 1.3 Determine object keys to be transported

*     depending on the current view entry and

*     enter them in CORR_KEYTAB...

  LOOP AT IT9AR_TA2 INTO T9AR_TA2

       WHERE KEY1 EQ AROTA01-KEY1.

    CORR_KEYTAB-TABKEY = T9AR_TA2-KEY1.

* ...The object key has been determined.  Use a central

*    FORM routine to update the table:

    CLEAR RC.

    PERFORM UPDATE_CORR_KEYTAB USING CORR_ACTION RC.

    RC_SAFE = RC * RC_SAFE.

    IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

      EXIT.

    ENDIF.

  ENDLOOP.

  IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

    SY-SUBRC = RC. EXIT.

  ENDIF.



* 2. Additional object: T9AR_TA3 (NOT included in

*    object list:

*    - Build up CORR_KEYTAB entry (E071K):

* 2.1 Fill fields with individual values

  CLEAR CORR_KEYTAB.

  CORR_KEYTAB-TRKORR     = E071K-TRKORR.

  CORR_KEYTAB-PGMID      = 'R3TR'.

  CORR_KEYTAB-OBJECT     = 'TABU'.

  CORR_KEYTAB-OBJNAME    = 'T9AR_TA3'.

  CORR_KEYTAB-MASTERTYPE = 'TABU'.

  CORR_KEYTAB-MASTERNAME = 'T9AR_TA3'.

* 2.2 Determine object keys to be transported

*     depending on the current view entry and

*     enter in CORR_KEYTAB ...

  LOOP AT IT9AR_TA3 INTO T9AR_TA3

    WHERE KEY1 EQ AROTA01-KEY1.

    CORR_KEYTAB-TABKEY = T9AR_TA3-KEY1.

    CORR_KEYTAB-TABKEY+4 = T9AR_TA3-KEY2.

* ...The object key has now been determined.  Use a

*    central FORM routine to update the table:

    CLEAR RC.

    PERFORM UPDATE_CORR_KEYTAB USING CORR_ACTION RC.

    RC_SAFE = RC * RC_SAFE.

    IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

      EXIT.

    ENDIF.

  ENDLOOP.

  IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

    SY-SUBRC = RC. EXIT.

  ENDIF.

  SY-SUBRC = RC_SAFE.

ENDFORM.

Routine to append keys of the additional table entries
(Event "12" - after changing the key entries of the change task (E071K))


*---------------------------------------------------------


*   FORM E071KA_AROTA01


*---------------------------------------------------------


* Filling CORR_KEYTAB with the key entries of

* the additional objects that cannot be assigned

* to an individual view entry.

*---------------------------------------------------------


FORM E071KA_AROTA01.

DATA: RC LIKE SY-SUBRC.

* 1. Additional object: T9AR_TA2 (included in

*    object list):

* Build up CORR_KEYTAB entry (E071K):

* 1.1 Initialize with E071K (global settings)

  CORR_KEYTAB = E071K.

* or:

* CORR_KEYTAB-TRKORR     = E071K-TRKORR.

* CORR_KEYTAB-PGMID      = TRANSPORTER.    "R3TR

* CORR_KEYTAB-OBJECT     = TRANSP_OBJECT.  "TABU

* CORR_KEYTAB-MASTERTYPE = MASTER_TYPE     "VDAT

* CORR_KEYTAB-MASTERNAME = MASTER_NAME     "z.B.AROTA01

* 1.2 Specify individual object name

  CORR_KEYTAB-OBJNAME = 'T9AR_TA2'.

* 1.3 Determine object keys to be transported

*     and enter in CORR_KEYTAB ...

...... Individual coding, the view entries can be

...... taken from the internal table TOTAL.

  CORR_KEYTAB-TABKEY = T9AR_TA2-KEY1.

* ...The object key has now been determined.  Use a

*    central FORM routine to update the table:

  CLEAR RC.

  PERFORM UPDATE_CORR_KEYTAB USING CORR_ACTION RC.

  RC_SAFE = RC * RC_SAFE.

  IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

    SY-SUBRC = RC.  EXIT.

  ENDIF.



* 2. Additional object: T9AR_TA3 ( not in object list

*    - Build up CORR_KEYTAB entry (E071K):

* 2.1 Fill fields with individual values:

  CLEAR CORR_KEYTAB.

  CORR_KEYTAB-TRKORR     = E071K-TRKORR.

  CORR_KEYTAB-PGMID      = 'R3TR'.

  CORR_KEYTAB-OBJECT     = 'TABU'.

  CORR_KEYTAB-OBJNAME    = 'T9AR_TA3'.

  CORR_KEYTAB-MASTERTYPE = 'TABU'.

  CORR_KEYTAB-MASTERNAME = 'T9AR_TA3'.

* 2.2 Determine object keys to be transported

*     and enter in CORR_KEYTAB ...

...... Individual coding, the view entries can be

...... taken from the internal table TOTAL.

  CORR_KEYTAB-TABKEY(4) = T9AR_TA3-KEY1.

  CORR_KEYTAB-TABKEY+4 = T9AR_TA3-KEY2.

* ...The object key has now been determined.  Use a

*    central FORM routine to update the table:

  CLEAR RC.

  PERFORM UPDATE_CORR_KEYTAB USING CORR_ACTION RC.

  RC_SAFE = RC * RC_SAFE.

  IF RC NE 0 AND CORR_ACTION EQ PRUEFEN .

* in check mode exit when a sub-object is not

* included in the correction (RC <> 0)

    SY-SUBRC = RC.  EXIT.

  ENDIF.

  SY-SUBRC = RC_SAFE.

ENDFORM.

Changes in procedure

To maintain the data, proceed as follows:

1. Data maintenance
Changed entries are taken over into a change request to be specified.

2. Editing the change request
Choose the transport mode (Table view -> Transport), and enter the number of the change request. Add entries to the order or delete entries that you do not want to transport.

Carry out the second step after you have completed the activities, i.e.,immediately before you release the change task to the change request. Since all changed entries are logged, you cannot forget anything. In particular, you can also transport table entry deletions.

Of course you can still work as before using the manual transport interface. However, you cannot transport deletions this way.

Planning

To facilitate editing of change requests, it will be possible to go from the display of request contents (for example, in the Workbench Organizer) directly to the maintenance transaction for the respective object.