Configuring the Transport Domain and Transport Routes in STMS

Explanation

Once a Basis consultant understands what TMS does conceptually, the next step is configuring it in a live landscape. This is done primarily through the STMS transaction, which provides the graphical interface for managing the transport domain configuration, system overview, and transport routes. The first system installed in a landscape is usually configured as the Domain Controller. During this initial setup, TMS generates the domain configuration and RFC destinations used to communicate between systems for transport-related operations (checking queues, triggering imports remotely, and reading system status). Every additional system that joins the domain (for example, QAS and PRD) must be included via a domain-join process: the new system generates a request to join, which the domain controller administrator approves. This creates the necessary trusted RFC connections and distributes the domain configuration to the new system. After all systems are part of the domain, transport routes must be defined. The two most common route types are Consolidation routes and Delivery routes. A consolidation route defines how changes move from a source system (typically DEV) into a target system, consolidating multiple developers' changes for a given transport layer. A delivery route then defines how those consolidated changes move onward, for example from QAS to PRD. In the simplest and most common three-system landscape, this results in a straightforward DEV to QAS consolidation route and a QAS to PRD delivery route. Transport layers are an important underlying concept: they group objects (such as custom development packages) so that TMS knows which consolidation route to use when a transport request containing objects in that package is released. Standard SAP objects typically use the SAP transport layer and are not usually transported by customers; custom packages are assigned to a customer-defined transport layer, such as Z or Y-prefixed layers, at package creation time. More complex landscapes may include multiple parallel tracks—for example, separate paths for urgent hotfixes versus standard releases—using additional groups or route configurations, though this adds complexity and must be carefully documented to avoid confusion about which path a given request should follow. In S/4HANA on-premise and private cloud editions, the STMS-based configuration process is essentially unchanged from ECC, since it is the same underlying Basis technology. In SAP's public cloud offerings, direct STMS-based transport configuration is generally not exposed to customers in the same way, since SAP manages much of the underlying technical landscape; customers instead work with higher-level change and transport tools aligned to the cloud operating model. Consultants should verify the specific deployment's supported tooling rather than assuming STMS-level access is universally available. After configuration, it is essential to verify the setup: check the system overview in STMS to confirm all systems show correct RFC connectivity, and review the transport route graphic to ensure the visual representation matches the intended DEV-QAS-PRD flow before allowing any real transport requests to flow through it.

Code example

* Illustrative sequence of steps performed via STMS transaction (not code, but a configuration procedure)1. On the intended Domain Controller system, run STMS.   - TMS detects no domain exists and offers to create one.   - Confirm system name and accept domain controller role.2. On each additional system (e.g., QAS, PRD), run STMS.   - System detects it is not yet part of a domain.   - It sends a request to join the domain to the controller.3. On the Domain Controller, go to Overview > Systems.   - Approve the pending join request for each new system.   - TMS distributes the updated domain configuration automatically.4. On the Domain Controller, go to Overview > Transport Routes.   - Switch to change mode.   - Use the graphical editor to draw a consolidation route: DEV -> QAS (assign a transport layer, e.g., ZDEV).   - Draw a delivery route: QAS -> PRD.5. Save and distribute the configuration (Configuration > Distribute and Activate).6. Verify via Overview > Systems that all systems show green RFC status.

Real project scenario

During a landscape refresh project, a company adds a new sandbox system that must never send transports directly to production. The Basis team configures it as a standalone system in the transport domain with no consolidation or delivery route pointing to QAS or PRD, ensuring developers can experiment freely without any risk of accidentally releasing sandbox-only changes into the regulated release path.

Common mistakes

• Defining a delivery route directly from DEV to PRD, bypassing QAS testing entirely. • Forgetting to distribute and activate the configuration after changing transport routes, leaving systems with outdated route information. • Assigning custom development packages to the SAP-reserved transport layer instead of a customer-specific layer. • Not verifying RFC connectivity after domain changes, leading to import failures discovered only when a request is stuck in the queue. • Assuming public cloud SAP systems expose the same STMS configuration screens as on-premise systems.

Best practices

• Always model transport routes to mirror the approved change management path (DEV to QAS to PRD), never skipping the QA stage. • Use meaningful, documented transport layer names tied to specific applications or teams for traceability. • After any route change, verify with the graphical transport route display before considering the task complete. • Restrict who has authorization to modify transport domain configuration, since it affects the entire landscape's change delivery. • Periodically review the system overview for RFC connectivity issues, especially after system renames, IP changes, or OS-level network changes.

Interview angle

A common intermediate-level question is to describe the difference between a consolidation route and a delivery route, and to explain what a transport layer controls. Interviewers may also probe whether the candidate understands that route configuration changes must be explicitly distributed and activated, since forgetting this step is a frequent real-world troubleshooting scenario.