TMS concepts: domains, groups, layers and routes

Every change that reaches Contoso Motor Co.'s production system travels in a transport request. The machinery behind that is SAP's Change and Transport System (CTS). Developers and consultants meet the Transport Organizer, where requests are created and released. Release managers and Basis administrators meet the Transport Management System (TMS), reached with transaction STMS, which defines where requests may go and imports them. Underneath, the operating-system programs tp and R3trans do the actual export and import work.

Contoso's new SAP S/4HANA landscape has three systems: development CMD, quality assurance CMQ (test client 100, training client 200) and production CMP. Luis, the cutover and release manager, owns the transport calendar; the Basis team owns the TMS configuration. This lesson gives you the vocabulary both of them use.

Domain, controller and transport directory

A transport domain is the set of SAP systems that TMS manages centrally. Every system in it needs a unique system ID (SID), and the default domain name is DOMAIN_ followed by the SID of the first system configured. That first system becomes the domain controller automatically. The controller holds the reference configuration of systems and routes and distributes it to every other system, which keeps a copy. SAP's training material names production, as a highly available and well-secured system, as a good choice. A backup domain controller, which must be a real system on the same release, can take over if the controller is down.

Systems talk to each other through RFC destinations that TMS creates automatically, using a technical user called TMSADM in client 000.

Requests themselves travel through the transport directory, a shared file-system directory pointed to by the profile parameter DIR_TRANS. Its subdirectories matter when you read logs: data holds the exported content, cofiles holds control files, buffer holds one import buffer per system, and log holds the logs. Systems that share one directory form a transport group. Export and import are copies, not moves: after a release goes live, the same objects exist in CMD, CMQ, CMP and the directory.

Transport layers and routes

Routes tell TMS where a released request goes next. A consolidation route runs from the system where changes are made (the integration system, CMD) to the system where they are consolidated and tested (the consolidation system, CMQ). Every consolidation route carries a transport layer; in fact a transport layer is simply the name of a consolidation route. A delivery route then runs onward, from CMQ to the delivery system CMP. Delivery routes have no names: whatever was imported into CMQ is queued for CMP.

How does an object find its layer? Every repository object belongs to a package, and each package names a transport layer. Customer packages start with Y or Z; Contoso's order-to-cash enhancements live in package ZCMC_SD, which uses the standard layer. SAP's standard layer is named Z plus the development SID, so Contoso's is ZCMD; customizing also follows the standard layer. A separate layer named SAP covers SAP-delivered objects that the customer modifies. Objects in a package with no transport layer, or whose layer has no route, can only be saved as local objects in package $TMP or in local requests, and they will never leave CMD.

TMS offers standard configurations (single system, development and production, three systems in a group) that set these routes in one step,. A virtual system is a placeholder for a system that does not exist yet; routes and import queues can be modeled before the real system is installed. Contoso used one for CMP while production was still being built, so requests released during the build were already queuing for it. TMS also offers an optional QA approval procedure, configured on the QA system, that keeps requests inactive in the production queue until they are approved. You will meet it in lesson 3.