SAP Transports

While consultants and developers create and release transports in DEV, the Basis administrator manages the import side, using the TMS (transaction STMS) to import queued transports into target systems, in sequence, at controlled times, and to verify each import’s result.

• Import transports into QAS and then PRD via STMS.
• Maintain the correct import sequence (dependencies matter).
• Review import logs and return codes for errors.
• Configure and maintain transport routes and the domain controller.

A transport is two files and a queue entry, and knowing that removes most of the mystery.

A transport request has a number in the form of the system ID followed by a K and a serial number, and it contains tasks, one per developer or consultant who worked on it. Tasks are released first, then the request.

Releasing exports two files to the transport directory: a cofile holding the control information and a data file holding the objects. Those files are what physically move between systems, and a landscape sharing one transport directory needs no copying at all.

Two kinds matter. A workbench request carries repository objects: programs, tables, CDS views, and it is client independent. A customising request carries configuration, which is client dependent, so importing it affects a specific client.

The import queue in STMS is an ordered list per target system. Order is the thing to respect: requests are released in a sequence for a reason, and importing out of that sequence applies an older version of an object over a newer one.

Every import produces a return code: 0/4 are success/warnings, while 8 or higher indicate errors that need investigation. Reading import logs and resolving errors (often missing dependent transports or object conflicts) is everyday transport administration.

The practical reading: 0 imported cleanly. 4 imported with a warning, and the warning is usually a generation issue or a repaired object, which is normally acceptable and worth a glance. 8 means objects were not imported, and the transport is partially applied, which is the dangerous state. 12 and above mean the import itself failed.

An 8 is the one to act on. Something is in the target system in a half-changed state, and the fix is usually to correct the cause and reimport rather than to move on.

Half an hour across a development and a quality system, and it makes the mechanism concrete.

1. Make a small configuration change in development and note the request number it is recorded on.
2. Release the task, then release the request. Both steps are needed.
3. Open STMS and look at the import queue for the quality system. The request is there.
4. Import it and read the log. Note the return code.
5. Check the change is present in the target client. If it is not, and the return code was 0, the change was probably client dependent and imported into a different client.
6. Make a second change and release it, then import the second before the first. Compare the object state. This is the overtaking problem, and doing it deliberately once teaches why the queue order matters.

Controlled, scheduled imports (rather than ad-hoc) and strict sequence discipline keep QAS and PRD consistent and changes traceable. Good transport administration is much of what keeps a landscape stable.

The practical shape in most landscapes: imports into quality assurance run frequently or on demand so testing is not blocked, and imports into production run on a schedule, in one batch, after approval. That difference exists because a production import is a change to the system the business is using, and batching it makes the change reviewable and the rollback discussable.

• How often production imports run. Weekly is common. More often is more responsive and gives less time to test. Emergency route defined separately, and used rarely.
• Who approves. Somebody who knows what is in the request rather than somebody counting them.
• Whether a single transport directory is shared. Shared is simpler; separate needs files copied and is required where systems are isolated.
• Quality gates. Whether a request can reach production without having been imported and tested in quality assurance first. The answer should be no, and enforcing it is configuration.

Every landscape needs a way to fix production quickly, and the difference between a controlled one and an improvised one is whether it was designed before the emergency.

The right shape is the same route, accelerated: the change is still made in development, still transported, still recorded, and the approval and testing are compressed rather than skipped. That keeps the systems consistent, which is the whole point of the transport path.

The wrong shape is a change made directly in production. It fixes the incident and leaves development and quality assurance holding different code, so the next ordinary transport overwrites the fix and the incident returns, usually weeks later when nobody connects the two.

Where direct production change is unavoidable, the discipline is to reproduce it in development immediately and transport it through, so the landscape converges again. Recording that as a task rather than intending it is what makes it happen.

Firefighter access belongs to this conversation: elevated rights granted temporarily, logged, and reviewed afterwards. It exists so that emergencies do not require somebody to hold permanent excess privilege.

A recurring surprise is that a change made in development does not appear in the target system even though the transport imported cleanly. Usually the object was never in a transport.

Configuration is recorded on a customising request automatically, if the client allows changes and is set to record them. A client configured as not recording produces changes that exist locally and never travel.

Repository objects, programs, classes, tables and CDS views, go on workbench requests, and they are client independent, so they affect every client in the target system.

Master data does not travel. Materials, customers, vendors and users are data rather than configuration, and moving them between systems is a data load or a client copy, not a transport.

Some configuration is deliberately not transportable, including several settings intended to differ per system, such as certain logical system names and interface endpoints. Those must be maintained directly in each system, which is correct and catches people out.

The check when something is missing is straightforward: find the object and ask which request it is on. If the answer is none, the question is why the change was not recorded rather than what went wrong with the import.

• Importing out of sequence, inconsistencies result.
• Ignoring high return codes from imports.
• Ad-hoc, unscheduled imports into production.

• Importing a queue without reading return codes. An 8 scrolls past and the system is now partially changed.
• Releasing a request with an open task. The task's objects do not travel.
• Changing configuration directly in production to fix something urgently. The next transport from development overwrites it, and nobody remembers why it broke again. See system logs and user administration for the related administration areas, and spool administration for another queue that needs watching.

Importing a queue is mechanical, and designing the transport route, approval and schedule so changes reach production safely is the part you do in the course.