Change and Transport System:

Change and Transport System (CTS) is a tool that helps you to organize development projects in ABAP Workbench and customizing, and then transport the changes between the SAP systems in your system landscape. As well as ABAP objects, you can also transport Java objects and SAP-specific non-ABAP applications in your system landscape.

The CTS records all changes in change requests. The changes in change requests can be linked together logically, or can be completely independent of each other. Developers in a team can use a common request.The change request is then used to copy the changes from this client to other clients or systems. This automatic procedure is known as a transport. Transports of changes by the CTS allow you to develop in one environment, test your development work in a test environment, and then, if the tests are successful, use it productively.
A SAP transport is a package which is used to transfer data from one SAP installation to another. This data can range from a simple printer driver to a whole SAP client. It can be considered as an “update”, with the only difference being that SAP transports are made by the SAP users themselves. Transports can also be used to transfer data from external applications.

TP – “The Transport Tool”. This program coordinates the complete import and export of program and table changes made within the SAP system in order to transport them through the complete System Landscape. TP is a transport program and R3trans is a tool for transport. So here TP uses the R3trans for transport. TP means It is calls to R3Trans only. R3Trans is moving the transports.
R3trans – This is the tool, that does the real work for TP. TP controls the import and export of changes and R3Trans does them using scripts, that were generated from tp.

TP controls the process and calls several tools, like R3TRANS but also e.g. DDIC-Activation. Also R3trans sets a return code which shows whether or not the transport has succeeded. Details on transports can be viewed in the log file. Other return codes are not set by R3trans itself but point to errors, such as segmentation faults.

Return codes are as follows:

0: No errors or problems have occurred.
4: Warnings have occurred but they can be ignored.
8: Transport could not be finished completely. Problems occurred with certain objects.
12: Fatal errors have occurred, such as errors while reading or writing a file or unexpected errors within the database interface. A critical error has occurred, probably not caused by the contents of the request. You must inform your system administrator.(indicates import cancelled, program cancelled due to job, Import cancelled due to object missing, import cancelled due to object not active).
16: Situations have occurred that are normally not allowed.
18: Indicates import cancelled due to system down while import, due to user expired during import, due to insufficient roles and authorization.

Transport Layers: All development projects developed in the same SAP System and transported on the same transport routes are grouped together to form a transport layer. Before you start the first development project, you create a transport layer in the TMS transport route editor. This transport layer is assigned to the development system as its standard transport layer. Objects delivered by SAP belong to the transport layer “SAP”. Other transport layers are generally only needed when new development systems are included in the system group.

Transport Route: Transport routes are used to define in which target system you want to consolidate change requests and which SAP systems are forwarded this information automatically. All the development projects developed in a same SAP system and transported using the same transport route are grouped together to form transport layer.

There are two types of transport routes. First you set up consolidation routes, and then you set up delivery routes.

1) Consolidation routes:
To make your changes transportable, set up a consolidation route for each transport layer. Specify your development system as the starting point (source) of these consolidation routes. Specify the quality assurance system as the transport target (in a two-system landscape, specify the production system as the transport target).
Any modified objects that have a consolidation route set up for their transport layer are included in transportable change requests. After the request has been released the objects can be imported into the consolidation system.
If you make changes to objects which have no consolidation route defined for their transport layer, then the changes are made automatically in local change requests (or in Customizing requests without a transport target). You cannot transport them into other SAP Systems.You can set up one consolidation route only for each SAP System and transport layer.

2) Delivery routes:
After you have imported your development work into the quality assurance system, you then want to transport it into your production system. You may even want to transport it into several SAP Systems (for example, additional training systems). To do this, you have to set up delivery routes.
Delivery routes have a source system and a target system.
You can set up several delivery routes with the same source system and different target systems (parallel forwarding). You can also set up delivery routes in sequence (multilevel forwarding).

Below diagram explain the above concept of routes.

SAP Transport directory:
It is the global transport directory (/usr/sap/trans), which is actually a shared location (residing in the Domain Controller System) among all the member systems of a landscape (system group). It also contains certain subdirectories, that are created automatically during the installation of the SAP system.

Transport Domain Controller:
Transport domain controller is a system which has trans directory, and in which the total landscape is designed and maintained.Transport Domain {Centralized Configuration Data}. A transport domain consists of all SAP systems jointly administrated through the TMS, Transport paths are centrally configured on the domain controller. Very simply, a transport group consists of one or more systems that share a common transport directory.

Transport group:
The SAP system containing the same transport directory are called to be in same transport group.That means in your three system landscape is having individual directory concept then there are three transport group in your system landscape. and if you are having concept of common transport directory in your system landscape then there is one transport group in your system landscape.

While transporting the option comes to select the option,below is explanation of each option:

1. Leave Transport request in queue for later Import: This check box causes the requests to be imported again in correct order with the next import of all requests.
2. Import Transport requests again: This also imports the transport request if it has already been imported.
3. Overwrite originals: It imports objects if the objects are the originals in the target system. The object directory entry determines the SAP system where the original version of an object is
4. Overwrite objects in unconfirmed repairs: It also imports objects, if they were repaired in the target system and the repair is not yet confirmed.
5. Ignore Non-permitted transport type: It imports the transport request if this transport type was excluded by particular settings in the transport profile.
6. Ignore Non-permitted Table Class: It imports data records of a table even if the delivery class of the table does not permit the data records to be imported
7. Ignore predecessor relations: If you want to import all the requests for one or several projects, but additional requests from other projects exist for which there are dependencies .This option
is switched off by default, which means the predecessor’s relationships will not be damaged.
8. Ignore Invalid Component Version: This option is used to avoid component mismatch issue.

Types of transport change request:

1) Workbench Request: Workbench requests are cross-client. Changes done in one client are automatically reflected in all other clients.
2) Customizing Request: Customizing requests are client specific. The changes will not be reflected in other clients. For e. g a change done in ECC Dev system will not be reflected in other clients in the same ECC Dev system. We have to do a client copy using T-code SCC1. You can see the client number next to this type of request.
3) Transport of copies: Transport of copies option is available in each SAP system. This is a type of transport similar to customizing and workbench with its different behavior. We can use transport of copies to move your object(which may already be locked under your workbench or customizing TRs) to a specific target, you create a transport of copies by including the object or any other tasks and then you can release this even if your object is locked under any other TR, also another scenario like, when we need to export certain table contents, or when we need to include objects from a released transport request.

Leave a Reply

Your email address will not be published. Required fields are marked *