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:

• 
  
Processing after installation of the CTS
• 
  
Configuration of transport routes in the TMS
• 
  
Setting the system change option
• 
  
Setting the clients

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:

• new SAP Systems are included in the system group

• the roles of individual SAP Systems or clients change.

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:

• Generating basic settings of the Change and Transport System

• Setting the system change option

• Closing foreign requests and tasks

You must specify the installation type of the SAP System on the initial screen:

• Standard installation

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.

• Database copy or database migration

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.

The system landscape contains all the SAP Systems that you have installed. It can consist of several system groups, whose SAP Systems are linked by transport routes.

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):

1. Log on in client 000 in the SAP System that you want to configure as the transport domain controller.
2. Enter Transaction STMS. The dialog box TMS: Configure Transport Domain appears.

(This dialog box only appears if you have not yet configured a transport domain.)

3. Enter the name and a short description of the 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.

4. If your SAP System consists of
multiple application servers, you can choose one server for the TMS.

5. Save your entries. The following actions are performed automatically in your SAP System:

• The user TMSADM is created.

• The RFC destinations required for the TMS are generated.

• The TMS configuration is stored in the transport directory.

• The transport profile for the transport control program
tp is generated.

• The SAP System is configured as a
single system.

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:

1. In the dialog box TMS: Configure Transport Domain, or in the dialog box TMS: Include SAP System in Transport Domain, choose Address.

The address data of your system is displayed. It is used to generate the RFC connections.

2. In the field Target host, use the
F4 help to choose the host name of the application server you would like to use for the TMS.

Choose the application server with the highest availability. This is generally the server used for the enqueue process.

3. Choose Continue.

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:

1. Log on to the SAP System functioning as the transport domain controller.
2. Enter Transaction STMS.
3. Choose Overview
® Systems. The system overview appears.
4. Position the cursor on the SAP System you want to change.
5. Choose SAP System
® Change.
6. Choose the tab Communication.
7. In the field Target host, enter the host name of the application server.
8. Choose RFC connection test to check if the machine name entered is correct.
9. Save your entry and distribute the changed TMS configuration.

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:

• High availability

• High security precautions

• Highest possible release

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.

Use

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:

• the global setting
• the software component of the object
• the namespace or name range

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:

1. In the Workbench Organizer, choose Goto
® Transport Organizer tools.

This takes you to the Transport Organizer tools overview.

2. Go to Administration and start the program Set System Change Option.

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):

• Role of the client: Indicates whether the client is a production, test, training, demo, or Customizing client.

• Changes and transports for client-specific Customizing objects: You can specify for each client whether you want the changes to be recorded. As with the
system change option in the Transport Organizer, changes can also be forbidden here altogether. You can make the following settings:

• Changes without automatic recording
• Automatic recording of changes
• No changes possible
• Changes without automatic recording; no transports allowed

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.

• Changes to cross-client objects: You can specify for each client whether you want to allow changes to Repository objects and/or cross-client Customizing objects.

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:

• Flag that locks the logon procedure. It is set in the target client by the client copy program. This means that no work may be carried out in the target client when client copy is in progress.

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.

• Protection against SAP upgrade means that the client is no longer provided with SAP upgrades. Users can no longer work actively in the client after the system has been upgraded. The flag can only be set for a test client or an SAP reference client (
EarlyWatch). This function is only intended for exceptional cases, when, for example, the basis for an adjustment is needed after an upgrade has been performed. Every "normal" client must be updated by an SAP upgrade, since otherwise data resources from system and Customizing tables required for transactions may not be available. However, you can prevent clients that need to contain certain tables purely for backup purposes (backup clients) from being supplied with SAP upgrades that are not necessary or not wanted. To maintain this flag, you require the administration authorization for the Transport Organizer (authorization S_CTS_ADMIN).

• Restricted permission to execute CATT procedures. CATT (Computer Aided Test Tool) allows you to restart recorded test runs repeatedly. This process changes the database and it is therefore necessary to declare this as a property of the client.

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 can make transports between systems in different domains in the same way as you make transports between systems in different transport groups; RFC is used to transfer transport files between the transport directories involved.
• You can display transport logs of systems in the other domain.
• You can compare versions of Repository objects in systems in different domains.
• Domains are independent administrative units. You can only make changes (such as transport route changes) in the controller of the domain.
• If you need to administrate a large number of systems (more than 50), it makes sense to split the systems into domains; place systems which transport to each other frequently in the same domain. This makes is easier to distribute changes to the configuration, since changes are distributed more quickly in domains that contain fewer systems.
• Transport routes are not distributed between domains. You can, however, configure a route between systems in different domains, but must configure it twice, once in each domain.
• You can choose to configure the Workflow Engine in each domain, or you can use the Workflow Engine of a different domain.

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:

• A system has a 'slow' connection to the network

• The high security level of some systems does not allow file system access by other systems (NFS or shares)

• Different hardware platforms are used

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:

• 
  
Configuring the transport domain: You define which SAP Systems in your system landscape form a transport domain, and which SAP System is to be the transport domain controller.

• 
  
Configuring the transport routes: The 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.

If your system landscape is already set up, you only have to configure the TMS transport domain. TMS takes over the transport routes.

• 
  
Choosing the transport strategy: You can choose how you want to make transports between SAP Systems.
• 
  
Configuring the QA approval procedure: You can use TMS Quality Assurance functions to check changes in the QA system before you transport them to other systems.
• 
  
Configuring the transport workflow: The transport workflow allows you to make speedy corrections to the production system or make transports that do not follow the defined transport routes.

Prerequisites

Before you can configure the transport routes, the following prerequisites must be met:

The transport domain has been configured.

• All SAP Systems involved were included in the transport domain.

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:

• System attributes
• Consolidation routes
• Delivery routes
• Target groups

SAP provides two editors for configuring transport routes:

Graphical editor

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.

• 
  
Hierarchical list editor

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:

1. Log on to the domain controller.
2. Call Transaction STMS.
3. Choose Overview
® Systems. The system overview appears.
4. Choose Goto
® System lists. The screen Display View "TMS System Lists": Overview appears.
5. Choose Display ® Change.
6. Choose New entries.
7. Enter the name and a description for the new system list.
8. Select the new entry.
9. On the left of the screen, choose the node Systems/Clients. The screen Change View "Systems/Clients": Overview appears.
10. Choose New entries.
11. Enter the systems you are interested in and save.

Note that the Client column is not currently used.

12. To exit this screen, choose Table view ® Exit.

13. Distribute the configuration immediately, so that you can use the system list in all your systems. To do this, go to the system overview and choose Extras ® Distribute and activate configuration.

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
	Quality assurance system

An import queue can have one of the following statuses:

	Data is obsolete or does not exist
	Import queue is open All requests released for this SAP System, or forwarded to this SAP System are flagged for the next import.
	Import queue is closed The import queue has an end mark. All requests in the queue before the end mark are imported during the next import. All requests marked after the end mark are marked for the import following the next import. After the import queue has been closed, all the released or forwarded requests for this SAP System after the end mark are sorted.
	Import is scheduled
	Import is running All requests in the queue before the end mark are currently being imported into the SAP System. To display detailed information about the import running, use the Import Monitor. Preliminary imports are not displayed in the import overview.
	Errors occurred during import All requests in the queue before the end mark are currently being imported into the SAP System. However, errors occurred during the import. To find the source of the errors, use the tools described under Monitoring Transports.
	Import terminated An error occurred during the import. You can display detailed information about the source of the error by using the Import Monitor.
	Could not read import queue Error occurred when reading the import queue of an SAP System. Click the status field of the import queue to display a detailed error message.

Change & Transport System

A special type of virtual system that uses a real SAP System to perform actions for the system in a transport directory.

External systems differ from virtual systems in that they have their own separate transport directory.

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

• Configuring the QA approval procedure (determining the QA system and the approval steps)

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.

• Processing the QA worklist

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.

• Displaying the QA history

Using this history you can display the QA activities for a specific period.

Activities

1. When you configure the
QA approval procedure, you determine the QA system, switch on the option Forward after confirmation, and define the approval steps for that system.
2. You
approve or reject requests.
3. You display the
QA history for a selected period.

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:

• It must be the target of at least one consolidation or delivery.
• It must deliver at least one additional system.

To configure the QA approval procedure, you have to be logged on to the domain controller.

Procedure

1. 
   
Configure your QA system.
2. 
   
Determine the approval steps for your QA system.

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:

• It must be the target of at least one consolidation or delivery.
• It must deliver to at least one additional real system.

To configure the QA approval procedure, you have to be logged on to the domain controller.

Procedure

1. In the TMS initial screen, choose . The screen Display Transport Routes appears displaying the existing transport routes in the transport domain.
2. Switch to the change mode by choosing Configuration ® Display <-> Change.
3. Position the cursor on the system that you want as the QA system.
4. Choose Edit ® System ® Change. The dialog box Change System Attributes appears.
5. Choose the tab System attributes and under Quality assurance select Delivery after confirmation.

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:

1. Clients that are the target of a delivery or consolidation
2. Clients that deliver to other clients

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.

1. Choose Copy.
2. Choose Configuration ® Distribute and activate.

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:

• At least one approval step must be active for each defined QA system.
• You cannot delete or change the 3 default approval steps. You can only set the approval steps to be active or inactive. The default approval steps are valid for all configured QA systems.
• If you define additional approval steps and have configured more than one QA system, you can determine if the additional steps are to be system-/client-specific (only one QA system) or cross-system/client (global).

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

1. In the TMS initial screen, choose . The screen System Overview: Domain appears.
2. Choose . The screen Display TMS Configuration: appears.

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.)

3. Switch to the change mode. To do this, choose Configuration ® Display « Change.

If you want to add approval steps:

1. Choose Insert row. By default, the new step has the type Approved by user department.
2. You can choose another type using the input help. If you choose another type, you receive the default text for it at the same time. You can edit this text.
3. If you have more than one QA system configured, additional columns are displayed (System and Client). You must use the input help to determine if the additional step is system-/client-specific or global.

4. Mark the approval step in the column Active that you want to process for the requests of the relevant QA system.
5. Save your entries.
6. Distribute the configuration.

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

1. Log on to the SAP System in which you want to reset user TMSADM.
2. Enter Transaction STMS.
3. Choose Overview
® Systems. The system overview appears.
4. Choose Extras ® Reset user TMSADM.

Result

The CPIC user TMSADM is regenerated with the default authorizations.

Use

You have displayed a job list and want to:

• Reset the scheduling of TMS jobs

• Release TMS jobs
• Cancel TMS jobs
• Delete TMS jobs
• Check the status of TMS jobs

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:

• The scheduling data for TMS jobs
• The logs for TMS jobs

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 appears with the relevant data under the tab Schedule.

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 from System appears. You can navigate through the entire job list using the 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:

• Errors that occurred when transport requests were exported
• Errors that occurred when transport requests were imported
• Errors in communication between SAP Systems
• Errors in the CTS configuration

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:

• Date and time

• User name
• TMS function
• TMS message

• SAP System in which the TMS function was triggered
• System name
• Client

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

You can organize, perform, and monitor transports between your SAP Systems using the Transport Management System (TMS).

User actions at the operating system level are no longer necessary, since all the necessary information and functions are mapped in the SAP System.

The Transport Management System offers the following functions:

● Configuring the transport routes using a graphical editor

● Displaying the import queues for all SAP Systems in the transport domain

● Importing all the requests in an import queue

● Importing all the requests in a project

● Importing specific requests

● TMS Quality Assurance

● Transport Workflow

● Transports between SAP Systems without a common transport directory

If an SAP Note is implemented using the Note Assistant, the corresponding transport request is assigned the attribute SAPNOTE. You can use the Transport Organizer (transaction SE09) to check for any transport request whether it contains a SAP Note implementation. If you want to find out all the transport requests that contain SAP Note implementations, use the Transport Organizer Tools (transaction SE03): "Find Requests". Expand the list and look for requests that contain the attribute SAPNOTE.

Make sure you released the request, as well as the tasks under it (the request is the part of the tree directly under the word "Transportable"). Check the action logs using SE09 for errors. If there were no errors, try re-transporting an object by changing it and creating a new request. Before releasing the task or request, go to SE09 and list the request. If the request is listed under "Local", it can NOT be transported to another system.

The problem lies in either the workbench setup, the development class assigned to the objects you wish to transport, or both. Check the workbench setup with SE06->Display. Is your system set as a productive system? If so, change requests usually are not transportable. Try creating a new development class Z000, and choose any transport layer that the system allows you to choose (if your system does not allow you to choose any transport layers, then the workbench is not set up to allow any changes to be transportable). If it allows you to choose several layers, create on new class for each layer, and a new change request for each class. Then go to SE09 and check if your requests are transportable. If they are transportable, try to release one of the development classes (release the task and the request) and check that the files are created.

Click on the request, hit Shift+F6 (Change), and change the target system to a SID other than the source system. If your system won't let you change it to a SID that works, you are either trying to transport from the wrong system, or you need to redo your system landscape.

This should be done by a consultant during installation, and should not be changed after installation. If you really want to do it yourself, release all locked objects, log onto client 000 with DDIC, go to SE06, choose the landscape you want (usually 2- or 3-system group, and press Create. Tell the system which SIDs do which roles, and the rest is set up automatically.

Re-import the request, and then delete it from the buffer. If you cannot re-import (because, for instance, it is a very old request, and you do not know if re-importing will overwrite newer object), you can delete the entries directly from the file /usr/sap/trans/buffer/SID. This of course is not a "real" solution, but it does work (the "real" solution maybe would involve further editing of the E070, E071, or E070C tables, but I don't know).

They need to be reassigned to a development class before they can be transported. Create a development class (or use an existing one) and test to make sure its objects can be exported and imported successfully.

If none of the tasks in the request have been released, the entire task/request can be deleted. Before deletion, however, you should check to make sure that the related objects are either changed back to the state they were in before the change that resulted in their being linked to the change request.

Look in the tables TLOCK, E070, E071, and E070C. Sometimes, data in these tables can become orphaned, and may need to be processed manually (this is rarely necessary).

You can backup and delete old transport files every once in a while. Directories to be backed up and deleted in the /usr/sap/trans directory include: data, cofiles, log, olddata, EPS/out, EPS/log, and put/*. Note that SAP-delivered files can be deleted without backup; this includes directories such as put/exe, put/tools, and EPS/in.

You can access the request overview in the Transport Organizer by choosing Own requests in the request query dialog box or by choosing:

Tools ® ABAP Workbench ® Overview ® Transport Organizer

The request overview is displayed in the form of a hierarchical list and is organized according to the categories "Transportable" and/or "Local". If you only have change requests belonging to one of the categories, only this category will appear.

The configuration of the transport routes in the SAP System determines whether changes to objects during modification adjustment are recorded in a local or transportable change request. You cannot and must not change these settings during the upgrade. In all cases, the change request can still be used for automatically transferring modifications to a subsequent system. For this procedure, the change requests are not released in the normal way, but handled specially.

Do not change the configuration of the transport routes in your system group during the upgrade.

The client copier can copy a client into another system, which can be on a different platform. You can change the client number.

You are no longer required to transport clients before you can copy them between systems. You can make a remote copy instead. You may still want to use the transport tool for the following reasons:

· There is no LAN connection.

· The data is to be buffered.

So the transport functionality is still supported.

All languages in the source system are transported according to the settings of the transport tool. All languages are selected by default.

Codepage conversions are performed automatically, as far as technically possible.

Procedure

A client transport comprises three steps

1. Client export (SCC8)

1. Choose Administration ® System administration ® Administration ® Client admin. ® Client transport ® Client export.

2. Select a copy profile.

Up to three transport requests are created, depending on the selected copy profile and the existing data. The transport request for texts is e.g. only created if the source client contains customer texts.

...

Transport	Description
KO	cross-client data
KT	client-specific data
KX	texts and forms

The data export is performed automatically asynchronously. The output of the export includes the names of the transport requests that are to be imported.

The data export is asynchronous and still runs if SCC8 has already finished. Do not run any other client copy tool before the data export is finished. You can check the status of the export with the transaction SE01. Display the logs for the request KT.

2. Import transport requests into the target client (STMS)

Choose one of the transport requests of the client transport in the Transport Management System (TMS). The other transport requests belonging to this client transport are then automatically added in the correct order.

Import these transport requests into the target client.

3. client import postprocessing (SCC7)

You need to perform postprocessing activities to adapt the runtime environment to the current state of the data.

Choose Administration ® System administration ® Administration ® Client admin. ® Client transport ® Import editing.

Client import postprocessing is always necessary and must be performed in the target client after the import of the transport requests.

It may be technically possible to start the transaction SCC7 in the source client, but you should not do so because it may cause data loss. You should protect the source client from overwriting by the client copy tools by choosing protection level 1 in transaction SCC4.

Do not use the same client as the source for several copies or client transports at the same time.

Ensure that the data export has finished before another client copy or client transport, by examining the export log of the transport request.