Setting Up the Transport Management System (TMS)

The following list provides an overview of what has to be considered before, during, and after installation of an SAP system.

External systems External systems are like virtual systems. This means that they are accessed using a communication system. However, for this type of SAP system, a separate transport directory is also defined.

To set up your SAP system landscape, it is sufficient to start with an existing SAP system as a development system. The quality assurance and production systems are not required at this stage. All future SAP systems can be represented at this stage as "virtual" systems. You also need to create a transport directory at file system level for all SAP systems. This directory is required for the TMS.

The SAP profile parameter DIR_TRANS has to point to the path of the transport directory. For Linux and UNIX, the default path is /usr/sap/trans. For Microsoft Windows, the default path is\\$(SAPGLOBALHOST)\sapmnt\trans or \\$(SAPTRANSHOST)\sapmnt\trans.

The subdirectories required in the common transport directory include (among others):

• EPS: download directory for SAP Support Packages (Electronic Parcel Service).
• actlog: information about SAP user per transport request and transport task.
• bin: configuration files for tp (TP_<domain name>.PFL) and TMS (DOMAIN.CFG).
• buffer: transport buffer file for each SAP system, indicating which transport requests are to be imported in which sequence.
• cofiles: command or transport request information files, which include information on the transport type, object classes, required import steps, and post-processing exit codes.
• data: data part of the exported transport requests.
• log: transport logs, trace files, and statistics.
• sapnames: information about transport requests per SAP user.
• tmp: temporary data and log files.

Transporting enables you to synchronize customizing and development in multiple SAP systems, through the transfer of changes from the development system to subsequent SAP systems. Transports along the transport routes must occur in only one direction.

As mentioned above, transporting requires a transport directory to enable SAP systems in the SAP system landscape to store and access various data files, command files, and log files.

Physically, objects in a three-system landscape are transported in three steps:

1. All objects in a (transportable) transport request, that are to be released, are exported by being copied from the database of the source system to the transport directory.
2. These objects are imported from the transport directory into the database of the quality assurance system. Here, they are tested and validated.
3. After testing and verification, the objects can be imported from the transport directory into the database of the production system.

Depending on the size of an organization and the scope of its SAP implementation, there may be many different individuals carrying out customizing and development projects. Some will be involved in customizing specific application areas, others may be involved in the development of new ABAP programs, others in the QA testing and acceptance of changes. There can be hundreds or even thousands of changes that have to be transported through the SAP systems in the landscape. The transport of these changes will be done using the functions of the TMS.

The concepts behind TMS are as follows:

• Centralized configuration of Change and Transport System (CTS) for all SAP systems.
• Centralized management of transport requests, especially the import process.
• Transport strategy based on predefined transport routes.

The purpose of the TMS, accessed via transaction STMS, is to centrally control the propagation of changes through the SAP system landscape based on predefined paths. This is designed to ensure the consistency of the SAP repository and the contents of the customizing tables in all SAP systems in the landscape. All necessary activities can be done from within the SAP system (using the SAP authorization concept) and there is no need to manually execute scripts at operating system level.

With TMS you are able to perform the following activities:

• Define the SAP system role within an SAP system landscape or transport domain.
• Configure the transport routes, using either an editor or delivered standard configuration settings.
• Configure the transport tool program's (tp) parameter profile.
• Display the import queues of all SAP systems in the transport domain.
• Define quality assurance and approval procedures in the QA system.
• Schedule the import of transport requests in an import queue.
• Perform transports between SAP systems without a common transport directory.
• Handle transport proposals of developers.

TMS enables SAP system administrators to centrally manage the transport configuration of multiple SAP systems by defining transport domains, assigning transport domain controllers, and defining transport routes.

A transport domain consists of all SAP systems that you plan to manage centrally. Within the transport domain, all SAP systems must have unique SAP system IDs (SIDs). Only one of these SAP systems is identified as the (transport) domain controller.

An SAP system landscape is a set of SAP systems that share customizing and repository objects via transported transport requests. A typical landscape is made up of, but not limited to, a development, a quality assurance, and a production system. In most cases, the SAP system landscape and the transport domain are made up of the same SAP systems, but it is not uncommon to have multiple system landscapes within one transport domain.

Examples of a single transport domain with multiple system landscapes include:

• A multinational company may have separate landscapes for each subsidiary. DE1, QA1, and PR1 may be the landscape for the Asian implementation, and DE2, QA2, and PR2 may be the landscape for the European implementation (see the figure "What is an SAP System Landscape?"). Even though they are separate system landscapes, both can still be controlled centrally in one transport domain.
• An SAP customer may have multiple system landscapes for different kinds of SAP systems. DEV, QAS, and PRD may be the landscape for the SAP ECC systems, while DBW, QBW, and PBW may be the landscape for the SAP BW systems. Again, separate system landscapes are controlled centrally using one transport domain.

A transport domain contains at least one transport group. A transport group consists of one or more SAP systems that share a common transport directory. The following figure shows the relationship between a transport domain and a transport group.

TMS supports several transport directories within a single transport domain. A directory that manages all data to be transported between SAP systems. This might be the case, for example, for the multinational company mentioned above where each subsidiary may have its own (local) transport directory. Or, it could be a transport domain containing a landscape that has a DEV system with its own transport directory, and QAS and PRD systems sharing a common transport directory, for security reasons. In this case, the transport domain would consist of two transport groups.

To add a new SAP system to an existing transport domain, you must perform configuration activities both on the new SAP system and on the transport domain controller.

Each additional SAP system must apply to the transport domain controller for inclusion to the transport domain. As the configuration of the TMS can only be done on the transport domain controller, the transport domain controller must confirm inclusion for each SAP system. The initial screen of transaction STMS at the applicant system indicates if the SAP system is waiting for inclusion in the transport domain.

The description of the transport domain is stored in the file DOMAIN.CFG in the bin subdirectory of the common transport directory. All other SAP systems connected to this transport directory read the file DOMAIN.CFG during STMS initialization to identify the transport domain controller and transport group address.

When an SAP system has been configured for the TMS and has been approved in the transport domain, you'll find a newly created user TMSADM in client 000 and generated RFC destinations required for the TMS.

The SAP systems within a transport domain communicate with each other using Remote Function Calls (RFCs). RFC communication requires user IDs to access target SAP systems. When SAP systems are added to a transport domain, the necessary RFC destinations and user IDs are automatically configured by the TMS tool. The transport domain configuration settings are distributed throughout the transport domain using RFC communication.

Changes to the transport domain configuration are made on the transport domain controller system, and are then distributed to all SAP systems in the transport domain. Each time you make a change on the transport domain controller system, a dialog box is displayed asking whether to distribute the change. You can distribute several changes in one distribution process.

When SAP systems are initially added to the TMS configuration, the system user TMSADM is configured with limited authorizations. This user is used when distributing and activating the TMS configurations.

There are two types of RFC destinations created by the TMS:

• TMSADM@<SID>.<domain name>
• TMSSUP@<SID>.<domain name>

The user TMSADM is inserted as a system user in the TMSADM@<SID>.<domain name> destination, but there is no RFC user inserted into the TMSSUP@<SID>.<domain name> destination. Therefore, if you try to execute a function that goes beyond the limited authorizations of the TMSADM user, for example, scheduling an import, TMS uses the TMSSUP destination. As a result, the target SAP system prompts you for credentials of a user that does have the necessary authorizations.

If the SAP system that is acting as the transport domain controller fails, no changes can be made to the TMS configuration. Therefore, SAP recommends that you configure a backup domain controller that can take over the function of the transport domain controller when required.

It may also be necessary to move the transport domain controller to another SAP system. In this case, you must activate the backup domain controller. Then, the backup domain controller becomes the transport domain controller, and the transport domain controller becomes the backup domain controller.

To check the current status of the transport domain configuration for each SAP system in the transport domain, access the TMS System overview. From the TMS initial screen, use the menu to choose Overview → Systems. In this overview, you can also see whether the configuration is up to date, and whether any errors occurred when distributing the configuration.

The transport control program tp requires a transport profile. This profile provides information on establishing a database connection for all SAP systems in the transport domain, as well as other technical information on performing the transport process. TMS generates and manages this transport profile as a part of the transport domain configuration.

To display the tp parameters of an SAP system, call transaction STMS. From the menu, choose Overview → Systems. Mark one SAP system and choose SAP System → Display. Choose the tab Transport Tool. From the menu, choose Goto → tp Parameters. This displays the parameters in TP_<domain name>.PFL, as well as the default value of other parameters used by the programs tp and R3trans. If a parameter is not specified in the TP_<domain name>.PFL file, a default value will be used. Global parameters override defaults. Local parameters override global parameters. For example, you can specify a global parameter value for all but one SAP system, if a local parameter applies to that SAP system.

Transport routes indicate the role of each SAP system and the flow of transport requests. The transport routes are what actually define your SAP system landscape.

Transport routes define the flow of the transport requests from one SAP system to the next. These routes are called either Consolidation or Delivery routes.

A consolidation route is an "export/ import" route. In a standard three-system landscape, the consolidation route typically proceeds from the development system (where the transport request is exported from) to the quality assurance system (where the transport requested is imported into). Consolidation routes have transport layers in order to be addressed.

A delivery route is an "another import" route. In a standard three-system landscape, the delivery route is specified between the quality assurance system and the production system. This is because there is no additional export from the quality assurance system, but another import in the production system. Delivery routes have no names.

All repository objects are grouped into logical units called packages (formerly: development classes). The definition of each package contains an assignment to a transport layer. The transport layer is the "name" of a consolidation route. Repository objects, via the assignment to the package, inherit this transport layer assignment.

All SAP delivered objects are assigned (according to their packages) to the transport route SAP.

Customizing objects (and others) are not grouped into packages. They follow the transport route for the standard transport layer. This standard transport layer is named Z<SID> by default. The SID is the SAP system ID of the development system.

SAP System Roles within Transport Routes

In the context of transport routes, an SAP system may play the following roles:

Integration system

The source of a consolidation route, that is the SAP system where changes originate and are assigned to transport requests.

The SAP system where customer changes are integrated with the SAP standard, customer developments and modifications take place.

Consolidation system

The target SAP system of a consolidation route.

Delivery system

The target SAP system of a delivery route.

Source System

The source SAP system of a delivery route.

If you have a more complex landscape, you need to configure more transport layers and transport routes. You also need to reroute certain objects away from the standard transport routes, for example, if a separate training system exists and there are certain programs that are to run there, but you don't want those programs getting into the quality assurance system or into the production system.

If the standard configurations delivered by SAP don't meet your landscape needs, TMS has editors that allow you to maintain the landscape.

The graphical editor delivers a visual drag and drop interface, where the SAP systems in the transport domain can be positioned and linked using the mouse. This is the default editor in the Transport Routes area of transaction STMS.

To create transport routes, click the appropriate SAP systems from the node area, and drop them in the display area (by clicking again). To create a transport route between these SAP systems, from the screen Change Transport Routes, choose the Add Transport Route button. The mouse pointer becomes a stylus. Using the stylus, draw a line connecting the two SAP systems between which a transport route is desired. In the Create Transport Route dialog box, enter the required information for either the consolidation or the delivery route. In case of a consolidation route you need to assign a transport layer. You can create the transport layer right here. Finally, save your changes.

The following figure shows a more complex SAP system landscape.

When a transport request is released and exported from the development system (in the figure above: S4D), the import buffer for the suitable consolidation system (for example, S4Q) is populated. The import buffer is a list of transport requests waiting for import. Once the transport request is imported into the consolidation system, the import buffer for all delivery systems (for example, S4P) is populated.

With the QA approval procedure , the buffer of the delivery systems is populated but the entries are flagged as inactive. In other words, the transport requests can't be imported until the responsible person flags the transport request as approved, which results in activating the entries in the delivery systems' buffers.

TMS Quality Assurance increases the quality and the availability of the production systems by letting you check transport requests in the QA system before they are delivered to subsequent SAP systems. The SAP system for which the QA approval procedure is activated is called the QA system. When the QA approval procedure is activated, a transport request will only be imported into the delivery system(s) if all the QA approval steps are processed in the QA system and the request has been approved. When you configure the QA system, you determine how many QA approval steps have to be processed for each transport request.

The figure above shows you how to activate the QA approval process from the graphical editor and how to define the approval steps.

Once you have configured the TMS, there are some tests that you can perform to verify that there are no technical problems with the TMS configuration:

As the transport domain controller communicates with other SAP systems in the transport domain using RFCs, you should check the RFC destinations between the SAP systems in the transport domain. To do this, from the System Overview screen of the STMS, select an SAP system from the list and use the menu to choose SAP System → Check → Connection Test. This verifies communications in both directions, to and from the transport domain controller.

Exports physically write files into the file system level. Imports read and update these files. Therefore, you should verify that the transport directory is available and has the appropriate file system level permissions. To do this, from the System Overview screen of the STMS, use the menu to choose SAP System → Check → Transport Directory. This action creates, reads, and deletes a file to the most important subdirectories of the transport directory and returns a report on the success or failure of all subdirectories. If you receive any errors, the appropriate corrections need to be made at the file system level.

Because exports and imports are physically executed by the operating system level program tp, you should verify that the tp program and its parameter configuration are consistent. To do this, from the System Overview screen of the STMS, use the menu to choose SAP System → Check → Transport Tool. This executes tests verifying the tp interface, the transport profile, the RFC destinations, as well as the connection to the databases, and returns a report of the results.