Once you have released all the tasks in a change request, you can release the change request itself. At this point, the object list of the change request contains all objects that have been changed by the users involved.
To release the change request, position the cursor on the request and choose Release Directly.
The following occurs when the change request is released:
· The current version of all objects entered in the request is stored in the version database. This means that the sequence of the change requests under which an object is edited corresponds to the various object versions archived in the database.
· If the change request contains repairs, the repair flag for these objects is reset when you release the request, as long as no sub-objects are locked in another change request. If this is the case, the object’s repair flag will be reset only when the last change request is released.
After the repair flag has been reset, the objects are no longer protected from being overwritten by imports into the system.
· When you release a transportable change request, its objects are exported out of the SAP System and copied to an operating system file. The request is also marked for import into the target system.
· The objects entered in the request are unlocked. They can now be changed again.
Any generic table entries (TABU) that do not exist in the original system are deleted in the target system.
In the case of transportable change requests, the overview of transport logs for the request is displayed automatically. The physical data export is generally still in progress at this time and a log cannot yet be displayed.
When the export has finished and you have refreshed the display, you can branch to the logs by double-clicking the export steps.
To ensure a smooth export, the CTS must be correctly installed. This is described in the section Requirements for Working with the Change and Transport System. A detailed log is created for the export and all subsequent import steps. The section Monitoring Transports describes how you can use the log to check whether the transport was performed successfully.
For the system administrator:
For the export, the transport dispatcher program RDDIMPDP must be scheduled in the background in client 000.
The program must be scheduled once in each client. To do this, log on in the appropriate client as a user with administration authorization (S_CTS_ADMIN) and execute the report RDDNEWPP in the initial screen of the ABAP Editor (transaction SE38).
If you export more objects at a later time, you do not need to reschedule the program unless the scheduling information was deleted manually.
For more information, refer to the program documentation of the transport dispatcher program RDDIMPDP and the documentation on the transport control program tp.
A transportable request is not automatically imported into the target system, since this could disrupt work significantly, particularly if the target system is an SAP System used for production operation.
The import must be started by the system administrator at an appropriate point in time. The system administrator can decide whether only particular requests or all requests waiting for import should be imported into the target system. The import is performed with the Transport Management System and is described in its documentation.
For the system administrator:
To import from lower releases (non-unicode systems) with ADO objects, the transport dispatcher program RDDIMPDP must be scheduled as a background job in client 000 and in the target client of the change request import.
The scheduling procedure is exactly the same as for the export.