The Correction and Transport System
Changes created in the development system must somehow be moved, then incorporated into the test system, then subsequently moved and incorporated into the production system. The SAP Correction and Transport System (CTS) serves this purpose and is the vehicle by which SAP moves objects such as programs, screens, configurations or security settings from one system to the next. Additionally, the CTS ensures consistency between systems by maintaining log entries for any attempted or completed activities. If used correctly, the CTS creates an effective and standardized procedure for managing and recording changes made to the system while providing an excellent mechanism for integrating either newly created objects or existing objects that have been altered to meet the customer’s needs.
Release Changes in CTS
As a user of the CTS it is important that you become highly knowledgeable about its capabilities (i.e. changing objects, incorporating them into other systems and optimal use of existing error prevention methods). With new releases of SAP it is sometimes the case that terminology may need to be changed to better reflect the purpose of specialized utilities or to show the expansion of utility functionality. Such is the case within the CTS. Upon installing the newer 3.0 and higher releases of the system, version 2.x user will find that the correction control utility originally referred to as correction/repair," is now called task.
Additionally, where a transport, previously moved objects in release 2.x, is now the change request in version 3.0 and higher. Although, for the sake of simplicity, here is focus on terminology specific to software releases 3.0 and higher, learning the differences in the terminology used from one system release to the next can benefit you greatly if you intend to work with various system releases.
Another change that you may wish to note is that from release 3.0 and up, the ABAP/4 development workbench includes the workbench organizer for managing software development objects. More importantly however, is that SAP recommends that the workbench organizer be used, as it has the added advantage of being fully integrated into the ABAP/4 development workbench.
CTS Transaction Terminology: Release 2.x versus 3.0 (& up)
Release 3.0 (& up) Release 2.0
Workbench Organizer (SE09) Correction and Transport System
Customizing Organizer (SE10)
Transport System (SE01)
Change Request Transport request
-Transportable - Consolidation request (K transport)
- Customizing request
Transport request Transport request
-Transport Originals -Transport with change authorization(C type)
-Transport of Copies - Transport without change authorization (T type)
- Development/Correction -Correction request
- Repair -Repair request
Change Request Transport
-Client Dependent customizing
-Client Independent customizing
IMG Tools -> Customizing
SE09 and SE10 transactions to use Only SE01
SE06 Setup workbench organizer SE06 Setup workbench organizer
The process of integrating objects moved using the CTS is called migration. Migration involves two aspects of the CTS’s functionality, namely the correction control system and a transport system As objects are migrated from the development environment to the test environment (ideally) and finally into the production environment. The correction control system uses tasks to record changes in the development environment. The transport system uses change requests to move objects from development system to other systems. Using SAP’s correction and transport tools, table data such as configuration and application data, can be moved from one system to another and from one client to another client in any given system.
Once a SAP object has been changed, it is referred to as a "repair. SAP designed the system in such a way that all the changes for any SAP object are automatically recorded. Always the system generates the repair requests for you and after the repair is done to the object it is entered automatically to the repair editor by the repair process. After all the steps to the repair process is done you can release the repairs from the source SAP system database. Later in this chapter we will find more about repairs and how to release the change requests.
Please note that in this chapter the release 3.0 and higher terminology will be used to address the CTS. In the CTS process, after the objects are created or changed in the development environment, a task is assigned to those objects. To automatically generate the tasks in the system, the recording for the individual client should be on in T000 table. It has to be done manually by executing transaction SCC4 and changing the client attributes there as shown in chapter 9. Many objects can be assigned to a single task. It is always recommended to place all the related objects in one task. A change request consists of one task or number of tasks. After the task is released from the system, all the objects from the task get transferred to the change request editor. The second step is to release the change request and export all the objects to the data directory and co files directory of the system. The third step is to use the system level SAP command TP in the target system to move the object from one system to another or one client to another. The TP command is executed in the operating system level to import a change request to the target system. It is very important to remember that objects can be directly transported using change requests. When the change recording is not on for a client as we have seen in chapter 9 the change request screen does not pop up for the users automatically; so some times developers put their objects directly in the change request editor to transport objects.
Components of the R/3 CTS system:
The CTS system is actually made up of various components, which allow for the movement of objects and help to maintain comparable and up-to-date changes from one system to the next. Here is a list of the components you may encounter while using the CTS to perform various tasks.
-Tasks, Change requests and Repairs
- Correction system or Workbench Organizer
- Transport System
- Development class
- Transport layer
- System types in the CTS pipeline.
- Repository objects
- Customizing objects
- Unix file systems in the transport process
- Important SAP delivery class and table types and tables in the CTS process
- Programs in the CTS process
- Version Management
- TP and R3trans program
Overview of Task, Change Request and Repair:
TASK: Corrections and repairs are recorded in tasks and transported using the change requests. It can control changes to internal components of the system that includes data dictionary objects, ABAP/4 programs, screens, CUA definitions, and documentation. The task can register and can keep the documentation of all the changes to the system objects. Once the objects are locked the system prevents parallel changes to the system objects. For existing objects, the system ensures that only a single original copy of each object exists. The previous version of an object can be restored and two versions of the objects can be compared. The CTS system asks for a change request number (if the recording is on in that client) whenever a customizing change is done or a new object is created with a development class other than $TMP (local object development class). A task is automatically created under a change request. User has to release the task first to release the change request. The user can be able to create or modify the object only after he or she opened a task. Opening a task registers the change with the system. Once the user releases a task, the objects in task get transferred to the change request.
After the unit testing in customizing master client is completed, a task is released to its change request. After a task is released, it can no longer be modified. If the user wants to modify the same objects, which were included in the released task, he has to create a new task. A task cannot be deleted after it is released. The attributes also cannot be changed. All the objects in the tasks should have a development class other then $TMP (local objects development class); otherwise those objects cannot be transported.
More... Downlaod this Book