This section is intended for the system administrator who sets up the Change and Transport System (CTS).
To set up the CTS, you require the administration authorization S_CTS_ADMIN.
For information on system roles and on transport control, see Change and Transport System - Overview.
Setting up the system group involves:
You also need to make a number of settings for controlling the transport programs at operating system level.
The CTS is set up once and then only has to be changed if:
If you have requested namespaces from SAP AG for your own developments in the ABAP Workbench, you must install these namespaces in your SAP Systems.
If you have installed your SAP System as a copy of an existing SAP System then you must configure the CTS after installation.
In SAP Systems installed with R3setup from the SAP CD the basic settings for the CTS are generated during the configuration of the Transport Management System. You do not need to perform any processing after installation.
Transaction SE06 provides the following functions for processing after installation:
You must specify the installation type of the SAP System on the initial screen:
The SAP System was installed from the SAP CD using R3setup. It is assumed that the SAP System is running as a correct, delivered version. No adjustments based on corrections or repairs have been made.
If you set up an SAP System that originated from a database copy using this option, problems could arise when you upgrade the system or modify objects with the Transport Organizer.
The SAP System was created on the basis of a copy. R3setup provides utilities to do this. The SAP System needs to be assigned a new and independent role within the SAP system group or outside of it.
Before you connect the new SAP System to the SAP system group, you have to give it a name that has not yet been used in the group.
Do not use an existing system name since this could cause serious conflicts and may lead to the loss of data.
After you decide which clients you need and which roles you want them to have, you need to decide how to distribute them amongst the different SAP Systems. You can set up multiple clients independently of one another in a single SAP System. However, when you configure the data, you must remember that cross-client Customizing settings and Repository objects are identical for all clients in a single SAP System. Changes made in one client apply immediately to all clients in the system.
Three-System Landscape
We recommend a three-system landscape in which each of the central clients has its own SAP System.
This consists of a development system DEV, a quality assurance system QAS and a production system PRD. The development system contains the Customizing client CUST, the quality assurance system contains the quality assurance client QTST and the production system contains the production client PROD.
Make all changes to Customizing data and Repository objects in the Customizing client. When you release the corresponding change requests, they are transported into the quality assurance client. This means that changes to cross-client data only appear in the quality assurance client after the transport. In the quality assurance client you can test whether the transports are complete, or whether any linked changes are missing and are still in unreleased change requests. If the test is successful, the change requests are transported into the production client. The production client is completely separate from the other clients as regards cross-client data.
If you need other clients with additional roles you can set them up in one of the three systems. Set up the development test client (TEST) and the prototype client (SAND) in the development system. Set up the training client (TRNG) in the quality assurance system.
Two-System Landscape
A two-system landscape is an alternative for smaller SAP implementations where little Workbench development takes place.
The two-system landscape does not include a separate quality assurance system QAS. The quality assurance client is also in the development system DEV.
As in the three-system landscape, the production client is completely separate from the other clients. The disadvantage of a two-system landscape is that cross-client data is used in both the Customizing and quality assurance clients. This means that any changes that are made to cross-client data in the Customizing client can affect the tests in the quality assurance client. You can also not guarantee that transports from the Customizing client will be complete. Although all tests in the quality assurance client were successful, errors could still occur after the transport into the production client. This problem is caused by changes being made to cross-client data and then not being transported.

One-System Landscape
We do not recommend a one-system landscape containing all central clients in a single SAP System. Joint usage of hardware resources and cross-client data places serious restrictions on how a single system operates. In particular, once the system is used productively, you can no longer develop in it, unless you stop productive operation for the development and test phases.
Prerequisites
You have decided which system should be the Transport Domain Controller.
Procedure
To configure a system as the transport domain controller (and thereby configure a new transport domain):
(This dialog box only appears if you have not yet configured a transport domain.)
The name of the transport domain may not contain blank characters. You cannot change the name of the transport domain afterwards without reconfiguring the domain controller and thereby the entire transport domain.
Result
The configuration of the transport domain is now complete for this SAP System. The initial screen of Transaction STMS shows that this SAP System is now functioning as the domain controller of the transport domain.
Prerequisites
When you configure the TMS in an SAP System for the first time, you can specify the application server to be used for all TMS functions.
Procedure
To specify the application server:
The address data of your system is displayed. It is used to generate the RFC connections.
Choose the application server with the highest availability. This is generally the server used for the enqueue process.
The application server chosen is used for the TMS functions after the TMS configuration.
If the SAP System has already been included in the transport domain, you can still change the address of the application server at any time.
To change the address of the application server:
Prerequisites
To configure and maintain the transport domain, you need the authorization S_CTS_CONFIG contained in the profile S_A.SYSTEM.
Process Flow
First, you must decide which SAP System you want to configure as the transport domain controller.
You can only carry out all the activities relevant to the entire transport domain, such as configuring transport routes or configuring RFC connections, in the domain controller. We therefore recommend configuring the transport domain controller in an SAP System with the following attributes:
The transport domain controller should normally be configured in a production system or quality assurance system.
The resulting system load is low for the SAP System configured as the transport domain controller of a transport domain. Only if the TMS configuration is changed or if there is an error does the load on the domain controller increase for a short period.
When you have decided which system is to function as the transport domain controller and have configured it accordingly, you can include all additional systems in the transport domain.
The system change option controls whether Repository objects and cross-client Customizing objects are modifiable or not.
The system change option does not affect client-specific Customizing changes. To set whether these changes can be made or not, go to Client Control.
You can make more precise settings for Repository objects: each Repository object is in a software component and a namespace or name range. For a Repository object to be modifiable, all the following settings need to be set to modifiable as well:
You can set the Repository objects in a particular software component to Modifiable, Restricted modifiability or Not modifiable. Restricted modifiability means that you can create Repository objects in this software component as non-original objects only.
Restricted modifiability is the same as Modifiable for packages.
You can set the Repository objects in a particular namespace to Modifiable or Not modifiable.
The SAP System logs this activity. Choose Log to display the settings log.
Prerequisites
To set the system change option, you require the administration authorization in the CTS. It is contained in the delivered standard authorization S_CTS_ADMIN.
Procedure
To set the system change option, proceed as follows:
This takes you to the Transport Organizer tools overview.
The Global setting option allows you to determine whether objects from the Repository or client-independent Customizing are globally modifiable or not.
Only if the global setting is set to modifiable, can you set the system change option of the software components and the namespaces and name ranges.
By choosing Edit ® Namespaces modifiable and Edit ® Own namespaces modifiable, you can set the namespaces and name ranges to Modifiable for all objects or for your own objects.
If you want to change the objects in your customer name range, set the software components LOCAL and HOME and the customer name range to Modifiable. This customer name range includes, for example, all reports beginning with Z or Y.
If you want to create or edit local objects in your SAP System, you must set the software component LOCAL and the customer name range to Modifiable.
You can use the Transport Organizer to record all changes to Customizing settings in change requests and mark them for transport.
The transport of Customizing settings to another SAP System is prepared. You only need to release the change request.
However, it is not always a good idea to record every single change made to the system. That is why many SAP Systems have a test, training, or demo client in addition to the production client. Recording changes is not appropriate here. In extreme cases, this could even result in unintentional transports that could destroy the target client.
To meet these sometimes contradictory requirements, you can assign each client appropriate attributes, which you can maintain in table T000 (transaction SM30):
The setting selected for a client applies only to changes to its client-specific Customizing settings, not to client-independent settings. The changes made to client-independent Customizing settings are recorded together with the changes to Repository objects and do not require a client-specific entry in table T000.
In a production client, client control does not influence the current settings (Customizing activities that can be accessed directly from the application menu). You can always change these settings in a production client; they are not recorded in Customizing requests.
Different request types in the Transport Organizer allow you to distinguish between the two modes. Changes to cross-client Customizing objects and to Repository objects are recorded in Workbench requests; changes to client-specific Customizing objects are recorded in Customizing requests.
If you use only Customizing requests, you make sure that the results of a Customizing project can be transported to the target client of another system without affecting other clients there.
In contrast, no guarantee can be given that the results of transporting Workbench requests will be restricted to one client. In this case, the import must be checked to establish whether it includes any cross-client objects. If such objects are found, we recommend that you adjust the corresponding settings in the source and target systems in order to assess the affect on all other clients.
Other features that affect the client are:
Only the users SAP* or DDIC are permitted to log on. Other regular users are warned with a corresponding message when they attempt to log on.
Use
If you have configured multiple transport domains (see Transport Management System - Setting Up a System Landscape) and want to make transports between systems in different domains, you can use domain links to link the two domains.
Prerequisites
There must be a permanent network connection between the systems in the two domains, similar to the connection between systems within the same domain.
The domain controller systems in both domains must have SAP Release 4.6C, or higher.
If you cannot operate a permanent RFC connection between systems in the two domains, you can use external systems to make transports between the two.
Functions
You use the Transport Management System (TMS) to model and manage your system landscape. It provides tools for configuring your system landscape, as well as for organizing, carrying out and monitoring transports.
Configuration of a System Landscape
All SAP Systems that are subject to the administration of the TMS form a transport domain. This is usually all SAP Systems in the system landscape. Certain system settings are the same for all systems within a transport domain, such as the transport routes. To achieve this, one SAP System in the transport domain has the reference configuration, with all other SAP Systems in the transport domain taking copies of this reference configuration. The system with the reference configuration is known as the Transport Domain Controller; only in this system can you make changes to the reference configuration. Each time you change the reference configuration, you must distribute the new configuration to all systems. The TMS automatically generates RFC connections between the systems in a domain so that they can communicate.
When you install an SAP System, a transport directory is set up for it. The CTS uses this directory to store transport data. In most cases, all SAP Systems in a transport domain have a common transport directory. However, there are situations where this is not possible, for example:
TMS supports multiple transport directories within a transport domain. The systems that share a common transport directory form a transport group. Data is exchanged between the systems using the RFC connections of the TMS.
Transport domain A: This transport domain has one transport group. This means that all the systems access a common transport directory.
Transport domain B: This transport domain has several transport groups, each of which shares a transport directory.
All systems in Europe share a transport directory; this is transport group 2. All systems in Asia share a transport directory; this is transport group 3. Together, transport groups 2 and 3 form a transport domain (transport domain B).
When you configure an SAP system landscape, it is usually the case that not all SAP Systems are available right from the beginning. The TMS allows you to define placeholders, or virtual systems. These take the place of systems that you want to include in the landscape at a later date. In this way, you can model the complete system landscape and make the settings for the CTS as soon as you have configured the TMS in one system. The virtual system is replaced when you install the real system.
If you administrate your SAP Systems locally in different locations, for example at head office and in different branches, it may be a good idea to configure several different domains. If you want to make transports between systems in different domains, you can use domain links to link the two domains. The data is transported between the domains using the RFC connections of the TMS, in the same way as transports are made between different transport groups.
If there is no permanent network connection between systems in different domains, you can use external systems in the TMS to make the transports instead. The transport data is exchanged using a transport directory that can be accessed by both domains, or by using a data volume. External systems offer fewer functions than domain links; for example, transport logs in a different domain can only be displayed using domain links.
When you configure your system landscape, you first have to configure the transport domain. Only then can you configure the transport routes. For more information, see Configuration of the TMS.
Making Transports
You can use the Transport Management System to organize, carry out and monitor your transports. You no longer need to execute tp commands at the operating system level. You can start and monitor all imports from every system in the transport domain. The TMS uses the RFC connections that were created automatically when the transport domain was configured to display all information on the requests that are waiting for import.
When you make an import, the TMS starts the transport control program tp in the target system. This program imports the data that was earlier exported from the database of the source system. If the two systems do not have a common transport directory, the TMS copies the necessary files into the transport directory of the target system before the import.
If you want to schedule an import for a particular point in time, the TMS schedules a background job in the target system. This is then executed at the time you chose.
If the import accesses another system in the domain, you need to authorize yourself in this system. Even if there is a test system in your domain with free authorization for all users, imports into the production system can only be made by users with special authorizations.
After you start or schedule an import, you can monitor the process from each system in the domain. All imports are logged, so that you can see which transport requests were imported into a system at which time.
Before you can work with the Transport Management System (TMS), you must configure it in all SAP Systems in your system landscape.
The TMS configuration includes:
If your system landscape is already set up, you only have to configure the TMS transport domain. TMS takes over the transport routes.
Prerequisites
Before you can configure the transport routes, the following prerequisites must be met:
Functions
The configuration of the transport routes is managed in the SAP System that serves as the transport domain controller, and can be distributed to and activated in all other connected SAP Systems in the transport domain.
The transport route configuration consists of:
SAP provides two editors for configuring transport routes:
The SAP Systems and their transport routes are displayed graphically.
You can position and link the SAP Systems together by clicking and holding the mouse.
The SAP Systems and their transport routes are displayed in a tree structure.
Use
The import overview can quickly become very complicated if a domain contains a large number of systems, or if the overview involves multiple domains. A particular user may only be interested in a certain group of systems (for example, an administrator may only make imports for certain systems). To help these users, you have the option of reducing the import overview to a predefined group of systems.
Procedure
To create a system list:
Note that the Client column is not currently used.
You do not need to distribute the configuration if you only want to use the system list in the controller system. System lists are distributed automatically when you distribute changes to the TMS configuration.
Result
You have created a system list that you can select in the personal settings in the import overview.
The TMS import overview shows the current status of the import queue for each SAP System in the transport domain. To access the import overview, call Transaction STMS and choose The following system types exist:
.
|
| Virtual system |
|
| External system |
|
|
|
An import queue can have one of the following statuses:
|
| Data is obsolete or does not exist |
|
| Import queue is open |
|
| Import queue is closed |
|
| Import is scheduled |
|
| Import is running Preliminary imports are not displayed in the import overview. |
|
| Errors occurred during import |
|
| Import terminated |
|
| Could not read import queue |
Use
TMS Quality Assurance increases the quality and the availability of the production systems by letting you check requests in the QA 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.) If a check for an approval step is not successful, the entire request cannot be approved.
Rejected requests are not imported into the delivery systems of the QA system.
If you reject requests, there is the risk that errors may occur when they are imported into the delivery systems. This is a result of the requests containing objects that are referenced from other requests. It is safer to correct an error using a subsequent transport (see Transport Strategy in the CTS).
Integration
In the TMS transport route configuration, you determine which system is the QA system, and which approval steps should apply to this system. You configure the QA approval procedure by performing these two steps. All the requests that are then imported into the QA system are included in the QA worklist.
You can go from the TMS Import Overview to the QA Worklist where you have to check the requests for each approval step.
You can only import all requests into the delivery systems if all the requests ready for import have been checked (which means approved or rejected).
If all the requests for a project and target clients are checked, you can import them even if requests for other projects and target clients have not been checked yet.
Prerequisites
Your system landscape contains at least one QA system from which there are configured delivery routes into other systems.

In a 3-system landscape, the requests from the development system are imported into the QA system. There, the requests are checked and the approved requests are forwarded to the production system.
Functions
You determine which system is the QA system, switch on the option Forward after confirmation for this system, and define which approval steps are valid for this system.
After a system has been configured as the QA system, the QA worklist is built. You then have to check the requests in these views for the individual approval steps.
Using this history you can display the QA activities for a specific period.
Activities
Use
Before you can process request with respect to the TMS Quality Assurance, you must configure the QA approval procedure.
Prerequisites
Ensure that your system landscape and/or transport domain is set up so that there is at least one development, one quality assurance, and one production system.
The system you want to configure as the QA system must have the following attributes:
To configure the QA approval procedure, you have to be logged on to the domain controller.
Procedure
Use
To perform quality assurance measures in the TMS, you must first configure the QA system.
Prerequisites
The system you want to configure as the QA system must have the following attributes:
To configure the QA approval procedure, you have to be logged on to the domain controller.
Procedure
You can only set Delivery after confirmation for the whole system. If you use Extended Transport Control, then all clients with the following attributes become QA clients in the system:
Under Procedure you can determine the approval steps. You can also set and change the approval steps in the domain configuration. The step Approved by system administrator is the active default setting.
Result
You have configured the QA system. After the configuration, the QA worklist is built. All the requests that are then imported into the QA system are included in the QA worklist. You can only import completely approved requests into the delivery systems.
Use
You want to determine approval steps for QA systems.
Note the following rules:
Prerequisites
You have configured at least one QA system.
To determine approval steps for the QA systems in the domain, you have to log on to the domain controller.
Procedure
. The screen System Overview: Domain
. The screen Display TMS Configuration: Under the tab Management you see how many QA systems are configured and who made the last change and when.
Under QA Approval Procedure you see the names of the configured QA systems and which steps exist. (If the transport routes are client-specific, the column Client is also displayed. If several QA systems are configured, the column System is also displayed.)
If you want to add approval steps:
Result
You have defined the approval step that is valid for your QA systems.
Use
If you want to reset user TMSADM to the default, or if the configuration of this user was damaged, then:
Procedure
Result
The CPIC user TMSADM is regenerated with the default authorizations.
Use
You have displayed a job list and want to:
Procedure
To perform the relevant action, proceed as follows:
Resetting the Scheduling of TMS jobs
In the job list, mark the job(s) whose scheduling you want to reset, and choose
.
Releasing TMS Jobs
In the job list, mark the job(s) that you want to release, and choose
.
Canceling TMS Jobs
In the job list, mark the job(s) that you want to cancel, and choose
.
Deleting TMS Jobs
In the job list, mark the job(s) that you want to delete, and choose
.
Checking the Status of TMS Jobs
In the job list, mark the job whose status you want to check, and choose
. In the status bar, you can see the result of the check.
You have displayed a job list and want to see: Procedure
Displaying Scheduling Data
Position the cursor on a job in the list with the scheduling data you want to see and choose
. The dialog box Job Information from System
Displaying the Logs
Position the cursor on a job in the list with the log you want to see, and choose
. The dialog box Job Log from TMS
icons.
If you want to display the logs of jobs in other systems, you need the administration authorization for background processing. For more information, see Background Processing.
To display job logs in other systems, you must first log on to the relevant system. The logon screen of the system is displayed automatically.
Alerts
Various situations can lead to errors when you are working with the Change and Transport System (CTS). The system administrator must react to these errors to ensure the stability and consistency of the SAP System.
To support the administrator, the Transport Management System (TMS) records CTS errors and provides tools that can be used to display and process these situations, known as alerts.
Among others, the Transport Management System records the following alerts:
You can display the alerts in both the CCMS Alert Monitor and the TMS Alert Viewer. On the initial TMS screen you can specify the default alert display by choosing Extras ® Settings ® Standard Alert Display.
Tools
CCMS Alert Monitor
The CCMS Alert Monitor is activated automatically when the TMS is configured. It replaces the TMS Alert Viewer, which is now only needed in special cases (for example, for special analyses). The CCMS monitor organizes alerts by system and topic. You can use this tool to display and process alerts.
Alerts are recorded in the system where they occur and then sent to the transport domain controller. This lets the system administrator monitor all systems in the transport domain centrally from the domain controller.
You do not need to make any additional changes to the configuration of the Computing Center Management System (CCMS) (such as maintaining central system groups) to be able to monitor TMS alerts in multiple systems. The TMS communication interface is used to send alerts to the CCMS in the domain controller system.
TMS Alert Viewer
Unlike the CCMS Alert Monitor, the TMS Alert Viewer is organized chronologically, and displays all actions for the selected system, not just errors. However, the Alert Viewer does not let you process these actions.
The TMS Alert Viewer only retains a certain number of actions in the display. If you want to display older actions, choose Edit ® History +/- to include more entries.
It can take some time to include older actions in the TMS Alert Viewer.
The TMS Alert Viewer records and displays all the actions which you perform with the Transport Management System. You can display this information using the Alert Viewer. To do this, call Transaction STMS and choose Monitor ® TMS Alerts ® TMS Alert Viewer. The following information is displayed: The following functions are provided in the Alert Viewer:
|
| Success messages are also displayed beside TMS error messages and warnings |
|
| Limits the display to errors and warnings or just errors |
|
| Includes any non-displayed actions in the list |
|
| Displays detailed information about a user if the user is known in the SAP System where the Alert Viewer was started |
|
| Displays the TMS Alerts of another SAP System in the transport domain |
If you click a message, the TMS Alert Viewer: Error Message dialog box appears with additional information on the message. You can navigate through the messages in this dialog box using
. Choose
to display the relevant online documentation.
The following functions are available in the dialog box TMS Alert Viewer:
|
| Displays the original message |
|
| Displays the long text, if it is available |
|
| For tp errors, the information written by tp to StdOut is displayed |
feedcat.net promotes your content, measures audiences
and reduces the load on your server resources!