SAP TMS (Transport Management System) Tutorial

What is SAP TMS?

TMS (Transport Management System) is the SAP tool used to move, manage, control, and copy development objects and customizing settings in an orderly fashion across SAP systems in a landscape, through pre-defined transport routes built on RFC connections.

The transport process consists of two main steps: exporting objects out of the source SAP system and importing them into one or more target SAP systems. TMS stands for Transport Management System and is the user-facing layer that sits on top of the underlying operating-system tools tp and R3trans.

Why do we need a Transport System?

Without a transport system, every change would have to be re-implemented manually in QAS and PRD — slow, error-prone, and impossible to audit. The CTS components plug this gap and play a central role in the overall development and customization environment. CTS stands for Change and Transport System.

CTS is an instrument for:

• Administering and controlling new development requests.
• Managing transports between systems.
• Recording where and by whom each change was made.
• Configuring the system landscape itself.

Overview of CTS Components

CTS is made up of three cooperating pieces, each owning a different layer of the transport problem.

• CTO (Change and Transport Organizer): The main tool for managing, browsing, and registering changes made to repository and customizing objects. It is the central point for organizing development projects. SE01 is the transaction with the extended view used by Basis administrators.
• Transport Tools: The actual transports happen in the back end at the operating-system level using transport tools that are part of the SAP Kernel. The two key programs are R3trans (the data mover) and the transport control program tp (the orchestrator).
• TMS (Transport Management System): The user interface that lets administrators configure transport domains, define routes, monitor import queues, and trigger imports without dropping to the OS.

SAP System Landscape

The system landscape (also known as the SAP System Group) is the arrangement of SAP servers used by an organisation. The recommended setup is a three-system landscape:

1. Development Server – DEV — where developers build and configure.
2. Quality Assurance Server – QAS — where changes are integration-tested.
3. Production Server – PRD — where the business runs day-to-day.

In its simplest form, the transport cycle is the release of new developments or customizing changes from DEV, which are then imported into both QAS and PRD. Import into PRD is gated: it may happen only after integration testing and quality checks have been completed in QAS and the change has been formally marked as passed.

What is Customizing? How does TMS help in Customizing?

Customizing is the process of adapting the SAP system to a customer’s business needs without modifying SAP-delivered code. To perform customizing, users and consultants work through the SAP Reference Implementation Guide (IMG), accessible through transaction SPRO.

Customizing is ideally done in DEV. The Transport Organizer (SE01) is used in conjunction with the IMG to record customizing changes inside a Transport Request, which TMS can then move onwards.

Most customizing changes — though not all — are client-specific: the changes affect only one particular client and are not intended for every client in the system. When a Transport Request is exported, TMS extracts the relevant table entries from the source database and copies them to the transport directory as files. The relevant table entries are locked while the customizing transaction is being used, but they are unlocked the moment the changes are saved to a Transport Request.

Repository and Development Changes

Apart from customizing existing objects, new developments are required in most projects. A development object is any object that is built inside the SAP system. The full collection of such objects, both client-specific and cross-client, is called the Repository.

Development is mostly performed with the help of the ABAP Workbench (SE80), so these changes are also known as Workbench Changes. Typical examples include:

• ABAP Dictionary objects: Tables, Domains, Data Elements.
• ABAP programs, function modules, menus, and screens.
• Documents and application-defined transport objects.

The Workbench is fully integrated with TMS, so every workbench change can be recorded and transported. Most workbench changes — though, again, not all — are cross-client, meaning the changes will be reflected in every client of the target system. Objects transported from the source system overwrite objects in the target system that carry the same names.

Clients and Types of Data in an SAP System

Conceptually, a client is a technically and organisationally independent unit that holds its own set of data — Master Data, Application/Operational Data, and Customizing Data. Clients create separate environments for users from different groups or with different purposes inside the same SAP system, without spinning up a separate database for each.

From the technical side, a client is identified by a 3-digit numeric ID, which is also the value of the table field MANDT for client-specific tables.

Among client-specific data, there are three distinct types:

• User Master Data: Login information including username, password, user defaults, authorization profiles or roles, user groups, and communication details. This data lives in a specific set of tables (the USR* tables).
• Customizing Data: The configuration settings that customise organisational structure and business processes for the implementing company. This data is client-dependent and is stored in customizing tables.
• Application Data: Also client-dependent, and split between master data (such as vendor master and material master — for example, table MARA) and transactional data (such as sales orders, financial documents, and production orders).

Client Customization Options

When a new client is created with transaction SCC4, administrators can choose whether changes recorded in the client are automatically captured in a Transport Request, and whether cross-client customizing or repository changes are allowed at all.

SAP Transport Directory

The SAP Transport Directory is the global transport directory (/usr/sap/trans) — a shared location, residing on the Domain Controller system, used by every member system in a landscape (system group). It contains several subdirectories that are created automatically during installation and is mandatory for setting up the Transport Management System.

The transport directory is the location where all changes are saved as files after they are released from DEV. It then acts as the source for changes that are subsequently imported into QAS and PRD. For this reason, the directory must be shared correctly across every system in the landscape.

On Windows, for example, the shared directory location can be reached using:

\\<SAPTRANSHOST>\sapmnt\trans

Here SAPTRANSHOST — the Domain Controller system’s address — is defined in the hosts file of every SAP system in the landscape. The Domain Controller is one system in the landscape that acts as the overall controller for change management and transport. It is chosen by the team of system administrators out of D / Q / P on the basis of availability and the timing of installation.

Main Subdirectories

• cofiles: Change Request Information files containing the full details and commands for each transport.
• data: The actual values and data payload to be applied as part of the change.
• log: Transport logs, traces, and statistics — your first port of call when a transport fails.
• EPS: Download directory for advanced corrections and support packages.

Other Subdirectories

• bin: Configuration files for tp (the Transport Program) and TMS, including the central TPPARAM file.
• olddata: Old exported data kept for archival or eventual deletion.
• actlog: Action logs for every request and task.
• buffer: Transport buffer for each system, declaring which transports are pending import.
• sapnames: Information about transport requests made by each user.
• tmp: Temporary and data log files.

Setting up the Transport Directory and TPPARAM

One of the key prerequisites when configuring TMS is setting up the transport directory and the transport parameter file.

• The directory must be shared properly among every system in the landscape, and every participating system must be listed in the global configuration file TPPARAM (the transport parameter file), located in the bin subdirectory of /usr/sap/trans.
• If a system entry is missing from TPPARAM, copy another system’s stanza and adjust the values (System ID, host name, and so on) to match.
• At installation time the transport directory and its subdirectories are created automatically, including an initial template of TPPARAM.

Operating System Tools: tp and R3trans

Underneath TMS, two operating-system programs do the heavy lifting: tp (the transport control program) and R3trans (the data mover).

tp – The Transport Control Program

• tp is the SAP program used by administrators for planning and performing transports between systems, as well as for SAP system upgrades. The CTO and TMS both call it under the hood.
• tp uses other tools and utilities to perform its functions — most importantly it calls R3trans. On top of that, it controls the correct sequence of exported and imported objects so that the target system is never left with mismatched dependencies.
• tp lives in the standard runtime directory of the SAP system: /usr/sap/SYS/<SID>/exe/run. It is copied there automatically during installation.
• As a prerequisite, the global tp parameter file TPPARAM must be maintained, listing at minimum the hostnames of every system participating in the transport process.
• tp is primarily used for performing imports into target systems. It works through import dispatchers — RDDIMPDP and RDDIMPDP_CLIENT_<nnn> — that must be scheduled as background jobs in every system where imports take place. If those jobs are ever deleted, report RDDNEWPP can re-schedule them.
• These jobs are event-triggered: tp sends a signal (an event) to the R/3 system and the job starts. The events are named SAP_TRIGGER_RDDIMPDP and SAP_TRIGGER_RDDIMPDP_CLIENT.

R3trans – The Transport Program

• R3trans is the SAP transport program that physically moves data between different SAP systems. It is rarely called directly; instead it is invoked from tp or by the SAP upgrade utilities.
• tp orchestrates the transports and generates the control files that R3trans consumes, but it does not connect to the database itself. All the database-level “real work” is performed by R3trans.
• R3trans supports moving data between systems running on different operating systems and even on different databases, which is what makes heterogeneous SAP landscapes possible.

Key SAP TMS Transactions

The following T-codes are the day-to-day tools a Basis administrator uses to operate the Transport Management System.

T-code	Purpose
STMS	Main TMS entry point — domain configuration, transport routes, import overview.
STMS_IMPORT	Direct access to the import queue of the current system.
SE01	Transport Organizer (extended view) — manage and release transport requests.
SE09	Transport Organizer for workbench requests.
SE10	Transport Organizer for customizing requests.
SCC4	Client maintenance — configure whether a client allows transports and changes.
SPRO	SAP Reference IMG — the entry point for all customizing activities.
SE80	ABAP Workbench — development environment for repository objects.

Best Practices for SAP TMS

A disciplined TMS process keeps changes flowing without surprises in production. The following habits are worth adopting from day one.

• Stick to a single transport direction (DEV → QAS → PRD). Never let changes flow backwards or skip QAS.
• Release transport requests in dependency order. If TR-B references objects added by TR-A, TR-A must enter the import queue first.
• Use descriptive short texts on every TR so a future reviewer can identify the change without opening the contents.
• Schedule RDDIMPDP background jobs on every system the moment it joins the landscape — without them, no imports will run.
• Mount the transport directory consistently across every host; mismatched paths are the single biggest cause of failed imports.
• Treat return codes above 0 as defects, not warnings. Investigate, document the root cause, and only then re-import.

FAQs