1. CTS & Transport System
The 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.
2. Data Structure of an R/3 System
Client 000 Client <nnn>
Appl. Appl.
data data
User
User
. . .
Customizing Customizing
Cross-client Customizing
R/3 Repository
3. Types of Adaptation
Customizing
Appl. Appl.
data data
User
User
. . . .
Customizing Customizing
Customizing
Cross-client Customizing
R/3 Repository
Development
Modifications
Customer enhancements
4. Consequences: Software Logistics in R/3
Appl. Appl.
data data
User
User
Different clients for:
Execution
Customizing Customizing
Testing
Cross-client Customizing Productive usage
R/3 Repository of Customizing
Separate R/3 Systems for customer in-house development
and for changes made to the R/3 Repository
DEV QAS PRD
5. TMS: Administering Your R/3 Systems
Delete Approve
Domain Controller
RFC RFC
RFC
Transport Directory
Transport group
Transport domain
6. TMS: Configuring Transport
Routes
Delivery
routes
Consolidation
routes To insert new systems into the
configuration, use drag and drop
Standard To define transport routes, insert
transport arrows and choose type of
transport route
layer Distribute and activate the new
configuration
7. Summary: Setting up an R/3 Transport
Landscape
1. 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 procedure
5. 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.
8. Customizing Procedure
Perform customizing
Settings are assigned to
a Customizing request
Automatic assignment
to a task
Customizing finished? Release task
Release change
request
Export Transport Directory
9. Transport Process: Import into Quality
Assurance
Development Quality Assurance Production
CR1 CR1
Import change request
Buffers: DEV
Fill PRD Data File
Files
QAS CR1
Buffer CR1
CR1
(inactive) PRD (CR1)
10. Development Quality Assurance Production
CR1 CR2 CR1 CR2 CR1 CR2
OK
Set entries active Import both requests
Buffers: DEV
Files
Files
QAS CR2
CR1
PRD CR1, CR2
11. Request Project Import all
1 DEVK900016 DEV_P00001 requests
2 DEVK900018
3 DEVK900020
4 DEVK900023
5 DEVK900002
6 DEVK900033 DEV_P00001
7 DEVK900035
Date/deadline Execution Options
Import
To import a single request,
request
use the other icon:
...
12. Development Quality Assurance Production
OK
TMS QA approval procedure
Editor's Notes
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 operations Client-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 settings The 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 on In 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 create a transport domain, call the TMS from Client 000. To automatically define the transport domain controller as as the current system, choose Tools Administration Transports Transport Management System . As soon as the domain has been created, additional systems can apply for acceptance by the domain. For security reasons, these systems are not accepted until they have been authorized by the transport domain controller. The TMS System Overview displays the various system statuses: Waiting for acceptance by the domain Active System locked for the TMS System not accepted System deleted Technically, TMS can connect systems with different R/3 release statuses. However, SAP does not support any transports between such systems. Because of its central importance, the transport domain controller should run on an R/3 System with a high availability.
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 <transport request>.
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.
