CTS & Transport SystemThe Change and Transport System (CTS) is a tool that helps you to organize development projects in the ABAP Workbench and in Customizing, and then transport the changes between the SAP Systems in your system landscape.

System LandscapePRODQTSTTRNGTESTCUSTSAND

R/3 RepositoryCross-client Customizing . . . UserAppl.dataCustomizingUserAppl.dataCustomizingData Structure of an R/3 SystemClient 000Client

CustomizingDevelopmentCustomer enhancementsModificationsCustomizingR/3 RepositoryCross-client Customizing. . . . UserAppl.dataCustomizingUserAppl.dataCustomizingTypes of Adaptation

R/3 RepositoryCross-client CustomizingUserAppl.dataCustomizingUserAppl.dataCustomizingDifferent clients for:ExecutionTestingProductive usage of CustomizingSeparate R/3 Systems for customer in-house development and for changes made to the R/3 RepositoryDEVPRDQASConsequences: Software Logistics in R/3

TMS: Configuring Transport RoutesStandard transport layer Consolidation routesDelivery routesTo insert new systems into the configuration, use drag and drop To define transport routes, insert arrows and choose type of transport routeDistribute and activate the new configuration

Summary: Setting up an R/3 Transport Landscape1.Make the transport directory available.2.Configure the transport domain controller and define the domain.3.Configuration of the transport program (tp) is done automatically and must not be done at OS level.4.In the TMS: - Include all remaining systems in the domain - Define the transport routes - Define QA approval procedure5. Set the system change options according to the role of the R/3 System.6.Create clients and set the client change options for the production system, development system, and so on.

Release taskRelease change requestSettings are assigned to a Customizing requestAutomatic assignmentto a task

Perform customizing

Customizing finished?ExportCustomizing ProcedureTransport Directory

Transport Process: Import into Quality AssuranceProductionDevelopmentQuality AssuranceDEVQASPRDBuffers:CR1Data FileCR1CR1Import change requestCR1(CR1)Fill PRDBuffer(inactive)FilesCR1

ProductionDevelopmentQuality AssuranceDEVQASPRDBuffers:CR1CR1CR1, CR2Set entries activeImport both requestsCR1CR2CR2CR2FilesCR1FilesCR2OK

. . .

RequestProject1 DEVK900016DEV_P000012 DEVK9000183 DEVK9000204 DEVK9000235 DEVK9000026 DEVK900033DEV_P000017 DEVK900035

Import allrequestsDate/deadlineExecutionOptionsImportrequestTo import a single request, use the other icon:

ProductionDevelopmentQuality AssuranceOKTMS QA approval procedure

*The R/3 System consists of various data types.Certain types of data are only accessible from a particular client. Such data types include business application data (documents, material master records, and so on) as well as most Customizing settings. These settings:Define the customer's organizational structures (distribution channels, company codes, and so on)Adjust the parameters of R/3 transactions to fit customer-specific business operationsClient-specific data types are closely interdependent. Thus, when application data is entered, the system checks whether the data matches the client's Customizing settings. If there are inconsistencies, the application data is rejected. Therefore, application data usually only makes business sense in its specific Customizing environment.In addition to client-specific data, R/3 can have other settings that, once defined, are valid for all clients. This data includes: Cross-client Customizing, such as printer settingsThe R/3 Repository, which contains all objects in the R/3 Dictionary (tables, data elements, and domains), as well as all ABAP programs, menus, CUAs, and so onIn the case of cross-client settings, an ABAP report that was originally developed in a certain client may be immediately usable in another client.*Corresponding to the various data types in the R/3 System, there are various types of changes and adjustments to data.The R/3 System is delivered in standard form and must be adjusted to the customer's requirements during the implementation phase. This procedure is called Customizing. As shown in the graphic, Customizing includes both client-specific and cross-client Customizing data. An R/3 upgrade may require a limited amount of additional Customizing.Unlike Customizing, enhancements or adjustments to the R/3 Repository are not required to operate an R/3 System.To adapt the R/3 Repository to a customer's requirements, the customer can develop in-house software.In addition, customer enhancements can be added to the R/3 Repository. In this case, customer-defined objects are used to complement the SAP delivery standard. The precise locations where enhancements can be inserted are specified by SAP. Finally, R/3 objects such as reports and table definitions can be modified directly. In this case, the R/3 Repository delivered by SAP is not merely enhanced; it is changed. During the next R/3 upgrade, these modifications may therefore need to be adjusted before being incorporated into the new Repository. The adjustment can be a time-consuming process.*Due to the R/3 System features described above, the type and number of clients and R/3 Systems are subject to the following requirements.You should not perform Customizing in the production client. For this reason, every implementation of R/3 requires several clients. For larger R/3 installations, different parts of a Customizing project may need to be tested jointly in a separate client. Production operation ultimately requires yet another, final client.At the technical level, the distribution of these clients (as well as any other clients,) across the R/3 System depends on whether you make changes to the R/3 Repository.If you make changes, the development and production environment must be subdivided and distributed across several different R/3 Systems. Otherwise, ABAP programs that were created in the development client, but still need to be tested, would immediately become available in the production client. This would cause serious security and performance problems.Therefore, if you plan to make any changes to the R/3 Repository, we recommend that you install at least two and preferably three R/3 Systems. You can use the additional R/3 System for mass testing and for quality assurance. In summary:Customizing settings must be transported between clients.Changes to the R/3 Repository must be transported between R/3 Systems.*To configure the transport routes between systems in the domain, use the hierarchical list editor and graphical editor provided by the TMS. Define these settings in the transport domain controller.The transport routes can be either consolidation or delivery routes.For consolidation routes, a transport layer is used, for example to define a route between the development and the quality assurance system. Delivery routes connect systems, for example the quality assurance and the production system. They do not use transport layers.Create transport routes in the graphical editor using drag and drop.After the transport routes have been configured in the transport domain controller, they can be distributed across all systems in the domain. These setting must be activated in all the systems in the domain. This can also be done centrally by the transport domain controller.To enable previous configurations to be reused, you can create versions in the TMS.

*The steps for setting up a transport landscape are summarized below.To set up an R/3 transport landscape:Make a transport directory available to every R/3 System that will be transporting. The TMS allows a local transport directory for every R/3 System.To configure the TMS, define the transport domain controller.In the TMS:Include all remaining systems in the domain.Define the transport routes.Set the system change options according to the role of the R/3 System.Create clients in every R/3 System and set the client change options (production system, development system, and so on).

*When a Customizing transaction is executed and the settings are saved, the settings are recorded by the Customizing Organizer.These changes are assigned to a change request. Either this request already exists (although it need not yet have been released) or it is created by the user.In this change request, the changes are saved in the user task. This assignment of changes occurs automatically using the user name.As soon as the required settings have been made, you can release the task. When a task is released, documentation can be created to describe the type of change and the reasons for it.After all tasks belonging to a request have been released, the change request can be released. Normally, with this release, the objects are exported to the transport directory, in whichever form they exist in the database at that specific time.Both during the export and during the concluding import into the target system (using the TMS), you should check the transport. The Transport System reports errors using return codes:0 signifies an error-free transport step. 4 is a warning.8 or greater signifies an error that requires postprocessing.*Using TMS from within R/3, the second step in the transport process is importing all requests listed in the import queue of the quality assurance system (QAS). TMS starts the transport control program tp at the operating system level. After the successful import into the quality assurance system, the requests are placed in the import buffer and import queue of the production system (PRD), where they are inactive at first.*All thoroughly tested and verified requests that have been imported into the quality assurance system are ready for import into the production system (PRD). Using TMS, you can import all requests (or just the first set of verified requests) listed in the production system import queue in the correct sequence. To ensure that production activities in PRD are not disturbed, ensure that errors and their corrections are imported in the correct order. *To prevent change requests from being imported unintentionally, SAP recommends closing the import queue to set the end mark before performing the import. To import all requests in the present queue, choose Queue Start import. A dialog box is displayed: enter the target client and choose Continue. Imports can be started from any R/3 System in the transport domain. If you start the import from another R/3 System in the transport domain, a logon window from the target system is displayed. After providing valid logon information, TMS starts the transport control program tp in the target system.Parameter Execution determines whether TMS starts tp synchron or tp asynchron. In the latter case, tp continues working in the background so that your session is not blocked for the duration of the import. As long as the import is running, this is indicated in the import overview. After the import, the queue is opened again automatically by removal of the end mark.After change requests have been imported, they are marked for import into subsequent systems. If a QA approval procedure is configured, all requests are set inactive. The transport route configuration specifies which change requests are automatically forwarded to which target systems. If an import is started with some inactive requests, this is detected by the TMS and the import is rejected.This complete import (Import all) ensures that objects in earlier change requests that were corrected in subsequent change requests are replaced by the corrected objects during import. Thus, the incorrect objects do not affect your productive environment. For each system, you can deactivate complete import with tp parameter NO_IMPORT_ALL.To import single requests, use tp import .*The TMS QA approval procedure increases the quality and the availability of the production systems by letting you check requests in the quality assurance system before they are delivered to subsequent systems. The system for which the QA approval procedure is activated is called the QA system. When the QA approval procedure is activated, transport requests are only forwarded to the delivery systems if all the QA approval steps are processed for each request in the QA system, and each request has been approved. (When you configure the QA system, you determine how many QA approval steps have to be processed for each request.) The request is only aproved if all the approval step checks are successful. You can only import completely approved requests into the delivery systems.Rejected requests are not imported into the delivery systems of the QA system.