Transport System Concepts SAP BASIS

The Change and Transport Organizers and the transport system deal with topics and concepts, some of which are the same as those used within the ABAP workbench, and some of which are specific to the functions these systems perform. In order to better understand this chapter, the main concepts are introduced in the next sections.

Repository and Development Objects

The Transport Organizer records and controls changes to current or new development objects. A development object is any object created (developed) within the SAP system. The collection of development objects that are either cross-client or client-independent (behave and act exactly the same regardless of logon client) is known as the repository.

Examples of development objects within the repository are as follows:

  • ABAP dictionary objects—tables, domains, search helps, data elements, and so forth
  • ABAP programs, functions modules, menus, and screens
  • Documentation
  • Application-defined transport objects

The Transport Organizer (SE01) is used to manage the repository and development objects changes.


For customers to adapt a SAP system to their business environment, they "customize" it. To perform the customizing of the SAP application, users and consultants use the Implementation Guide (IMG), from which they can access specific customizing transactions. The IMG is accessed by transaction SPRO. The Transport Organizer (SE01) is used in conjunction with the IMG to manage changes by user.

The Two Main Types of Change Requests

There are two main types or categories of change requests, SYST and CUST. SYST changes record a version of the ABAP Objects and general customizing object when the request is released. These changes also lock all the objects in the request, which prevents users from making changes to the objects from the time of change until the release of the request. CUST requests are comprised of client-dependent customizing changes. Each object of a CUST request contains a table key. The key has the client, where the data are stored; the table name, where the data are stored; and the key, which defines what rows of the table are stored in the request. CUST changes do not lock the objects (table rows) at anytime. So it's important that access to customizing changes is controlled properly. The Transport Organizer is fully integrated into the ABAP development workbench and the customizing tools to manage both types of change requests. This integration allows users to access the Transport Organizer functions directly from the ABAP development workbench. It also allows users to jump directly to the IMG customizing objects from the Transport Organizer.

Clients and Type of Data in SAP Systems

As introduced in Chapter, a client is a technical and organizational independent entity or unit within SAP systems. Clients include their own set of data, such as the master data, the customizing data, and the application or operational data. Clients are useful for creating "separated" environments within a single SAP system without the need to use several physical databases. From a technical point of view, a client is defined using a three-digit numeric code, and this client code, is always used as the first field, named "MANDT," and part of the primary key for every SAP table that is client dependent. This means that physically that data are still stored in the same database tables but are separated by the functions within the SAP kernel and the database interface, which restrict the access to only client dependent or cross-client data. The system selects and processes the data according to the client the users are logged on.

Data types in SAP systems and clients

Data types in SAP systems and clients

Among client-specific data, there are the following types:

  • User master data contain the user login information, including the username, the password, the user defaults, the authorization profiles or roles, and other useful and auxiliary information such as user groups, communication, and so on. These data are physically contained in a specific set of tables (the USR* tables).
  • Customizing data contain the configuration settings that made up the actual application implementation of the organizational structure and the business processes for companies implementing SAP. These data are client dependent and are physically stored in tables known as customizing tables.
  • Application data are also client dependent, and normally users distinguish two types: master data or transactional data. Master data, such as material master, vendor master, and so on, are data that are often loaded at the beginning of the project and later changes less often than operational or transactional data, such as posting financial documents, sales orders, production orders, and so on.

Besides the Repository, there is also a type of data, known as cross-client customizing, which are specific data contained in a set of configuration tables and which are valid and shared by all the clients within a SAP system. Only customizing data and repository (workbench) objects are transportable. The system settings prevent user master and application data from being transported. where and how the different types of data are changed.

Where and How Data Are Changed

Where and How Data Are Changed

The Application, User Masters, and Customizing data types exist solely in tables. How then does the SAP system determine if a table's data are transportable or not? This is determined by a few attributes of the table: its class, maintenance settings, and if a table maintenance dialog exists. Tip You can identify cross-client customizing in the IMG by selecting Additional Information | Technical Data, then Client Dependencies. All cross-client customizing will be labeled Cross-Client and client-dependent data by Client-Specific.

Roles Involved in the Transport Process

The functions of the Change and Transport Organizers allow developers and project team members to have the organization and coordination of individual or team development projects. Within the environment of the organizers and transport system, there are three points of view concerning the roles of individuals in charge of controlling and managing the system:

  • The team leaders or project managers are responsible for creating change requests and assigning them to team members (developers or customizers). As we will see in following sections in this chapter, the system will create a task for every customizer or developer, which will record the additions or modifications they do in the system. The project manager is usually in charge of releasing the change requests for transport to other systems. With the quality assurance process and the transport workflow, the team leaders can also be assigned the role of approving transports.
  • The developers and/or the people doing the customizing work are in charge of creating or correcting development objects as well as customizing the system, and thus will create the change requests or use common change requests in a project. (Project managers and team leaders or authorized personnel should approve and release change requests.) Releasing the change requests actually performs the export phase of a transport. When doing this, the project team should also check the log of the export phase as well as inform the administrator of the status and possibly request that the administrator make the import.
  • The SAP system manager or transport administrators set up the transport systems, perform or schedule the imports, check the result of imports, and finally inform the developers or customizers. Administrators have to work both at the SAP application level and sometimes at the operating system level using the transport control program (tp). Since the introduction of the STMS, the most common transport functions, including imports, are performed within SAP.

SAP System Group

With the CTO, SAP has established a safer and more controlled environment for the development work among SAP systems. An important concept for the whole process is the SAP system group, which is a group of related SAP systems, each with its own database (its own SID) and its own role in the development and implementation process. Normally, the SAP system group is defined by a common configuration of the TMS (configuration tables) and a common configuration at the operating system level where the group of systems share the transport directory (/usr/sap/trans). Transports can still be performed when directories are not shared. However, in such cases, administrators must either configure specific RFC connections and transport domains or manually copy the export and import files into the corresponding transport directories of the target systems and use special functions of the tp program to perform imports.

Within the Transport Management System, a SAP system group creates a transport group, which shares a configuration file TP_DOMAIN_<SID>.PFL, where <SID> is the three-letter system ID, located in the common transport directory. A SAP system group is also referred to as a SAP system landscape. Within a system group there will be one production system. This is important as it relates to SAP licensing. SAP licenses by installations or system group. Within SAP licensing allowances, an installation can have at most eight SAP systems and only one production system.

Transport Layer

A transport layer is used for grouping all the development objects that will always use the same transport routes within the same development system. Transport layers are assigned to all the objects that come from a specified development system. Grouping objects is a central concept for the Transport Management System and is a requirement to create a transport layer before any development project can start. Normally there is no need to have more than one transport layer within a SAP system group, except in those cases where there is more than one development system.

Transport Routes

The transport routes are used for defining the different routes that exist between two systems within the same system group. There are two types of transport routes:

  • Consolidation routes link a source system, such as the integration (development) system, with a target system, such as the consolidation (quality assurance) system. Every consolidation route is assigned to a transport layer. A consolidation route defines where a change request goes after export from the development system.
  • Delivery routes are used for linking a source system, such as consolidation (quality assurance) systems, with a target system such as the recipient (productive) systems. The delivery routes are not assigned to a transport layer, but every object that arrives at a consolidation system via a consolidation route (transport layer) that is also the source of a delivery route is automatically sent to the specified target system using the delivery route. The delivery route defines where change requests go after import into the consolidation system.

Consolidation routes are related to the export of change requests. When a request is exported from SAP, it follows a consolidation route to the target system. Delivery routes are related to the import of requests. As the request is imported into the quality assurance system, the change request will be added to the import buffer of the productive system. Since release 4.x, any system from the group can be the source of a delivery route, which allows complex transport routes to be established among a group of SAP systems. If no consolidation route is assigned to a transport layer, or if the transport layer does not exist for the system where objects are modified or repaired, then these modifications are considered local and therefore cannot be transported to other systems.

well-defined transport and development strategy within a systems group, including the configuration of the transport routes, is extremely important for SAP system implementation and support. The configuration of the transport system is used for managing and automating the process of distributing the development or customization objects among the systems belonging to a group. Configuration is also very important when planning an upgrade project in a systems group, because modifications must be made in several systems and then transported among the various systems to be upgraded.

Extended Transport Control

Extended transport control, available since v4.5x, allows multiple clients of a system to be defined in a transport route in STMS. Without it one client is defined per system in STMS. Before extended transport control, operating system scripts, using the tp program, were used to import into multiple clients of a system. With extended transport control, all the clients of a landscape can be defined in a transport route within STMS. Extended transport control is enabled by setting the parameter CTC = 1 in the TMS configuration. It is accessed by transaction STMS. Overview | Systems and then choosing the desired system and selecting SAP | Display in the application menu. The parameter can be fixed in the Transport Tool tag.

Change Requests

A change request or transport request is a list in the system containing the objects to be transported and information on the purpose of the transport, the transport type, the request-category, and the target system. A change request is made up of one or more tasks or change tasks. When a change request is created, either manually or automatically, the system assigns a number to it automatically, known as the change request number. The format of this number is normally <SlD>K<number>, for example, DD1K900030, where DD1 is the system identification (SID), K is a keyword, and the number is automatically range generated by the system, which starts at 900001 and does not need to be maintained by the system administrators.

When using the Transport Organizer, providing it has been correctly configured, the target system and the type of transport are assigned automatically. The change requests record all modifications made to development objects or to the customizing settings. The development objects from the ABAP workbench and customizing are recorded in different request types. When the changes have been made and the change tasks have been released, the list of objects is complete and the change request can be released. Transportable change requests are released to the transport system, which exports the objects and keeps a record of the transport in logs. When a change request is released, a transport log is automatically created.

A change request becomes a transportable change request, also known as a transport request, at the time of export. At the time of export, the SAP system copies the objects and table entries of the request to a data file and writes a descriptor file, called a cofile. The export then adds the request to the buffer of the target system. To display and check change requests, use the initial screen (request overview screen) from the Transport Organizer. To access this screen, from the main menu tree, choose Tools | Administration | Transports | Transport Organizer (or call transaction SE01 from the command field). Figure shows an example of Transport Organizer initial screen. Click on the check boxes to delimit your criteria for displaying change requests and press the Display button.

Transport Organizer main screen

Transport Organizer main screen

Let's review the two main types of change requests:

  • Workbench requests, which contains repository objects and cross-client customizing (customizing for all clients). These requests are in charge of recording changes to the Repository, that is, ABAP workbench objects. Within workbench requests, we can distinguish another two types: local or transportable. The difference is that the local ones do not need to have a target SAP system. Whether a workbench request is local or transportable is determined by the package it belongs, because it is in the package definition where the transport route is set. A transportable request will always belong to a package that has a transport layer assigned to it. A local request will always belong to the $TMP package, which is not transportable. Within workbench requests there are also Not Assigned and Unclassified requests. Both of these types are requests have no changes assigned to them.
  • Customizing requests, which contain objects that belong to client-specific customizing. According to the client settings, these types of requests are automatically recorded when users perform customizing settings. The system also assigns automatically the target system according to the defined transport layer. There are other types of requests, which are also managed from the Transport Organizer, such as the transport of copies or the so-called relocations, which can be used to perform special transport functions with packages or with a collection of change requests. These types are described in the Transport Organizer section, later in this chapter.


A task or change task in the Transport Organizer is a list of objects that are created or modified by a user. Within the organizer, tasks can be either development, correction, or repair tasks. Tasks are held individually by single users. A change request, on the contrary, can contain tasks belonging to different users. Tasks are not transportable by themselves, but only as part of a change request. Tasks also have a task number, which uses the same number range as change requests and is consecutive. This means that you cannot distinguish tasks from change requests by their numbers.

If you want to search just for tasks within requests, from the initial Transport Organizer screen, select Request | Find Requests. In the request type, make sure to check only the entries belonging to Tasks and uncheck the rest. Enter other selection criteria, such as username, date, and status, and click the Execute button on the application toolbar. The system will show the list of change requests in hierarchical form, with tasks located one level lower than change requests. You can view tasks by clicking on the + folder sign. Another option is to select the Transport Organizer Tools icon on the application toolbar (transaction code SE03) and then select some of the reports to find tasks and requests within the Requests/Tasks folder.

When development work starts, usually a system administrator, a development leader, or a project manager creates a change request to define tasks for all users involved in the project. Modification of objects and the creation of new objects that are registered as tasks belong to the change request. Once users finish working on their tasks, they must release them. Only when all tasks under the same change request are released can the change request be released and exported. It is important to distinguish between the release and export of a change request. The release of a request relinquishes locks and creates a new version for SYST type requests. Before the release of all the tasks, the request must be documented.

Development Teams

The method of grouping tasks together in a common change request is what makes the process of having several users working in the same development project possible. The system uses the authorization object S_TRANSPRT to protect the Change and Transport Organizer functions and S_CTS_ADMI for the administration and management of the transport system. To define tasks and requests for other users, a project leader must have the authorization S_CTS_PROJEC.

Developers or people in charge of customization need the authorization S_CTS_DEVELO to work at the task level. There are some standard superuser profiles containing these authorizations. Superuser profiles are profiles that describe a superuser for the system. Objects included in tasks or requests become locked against other development work on the same objects until the requests have been released. If this occurs, the lock is removed from the objects. Users on the same team can display and change the objects of other users working on the same project sharing the same change request.

Packages (Formerly Development Classes)

A package (formerly known as development class) is a way of classifying objects belonging to the same development project, or, in other words, for grouping repository objects that are functionally related. Every repository object in the system is assigned a package. The packages are objects themselves and, apart from grouping together related objects; also include the consolidation route for the objects belonging to the package. The packages form the main structure on which the ABAP workbench is based to start development work and can be also used to control the naming of the objects.

Packages are based on a hierarchy with a primary container for all the development objects that are grouped together and share the same system, customer delivery status, and transport layer. Packages can be maintained using the Object Navigator (transaction SE80), using transactions SE21 or SPACKAGE. As of SAP Web Application Server, "nesting" of packages is possible. Nesting allows packages to have other packages embedded in them.

Version Management

Both the ABAP workbench and the organizer provide a version management facility for all the development objects in the system. With version management, users can compare the current version of an object with previous versions; this enables developers to display or restore previously released versions of objects. To display the version for a particular object, first locate your object by navigating through the change requests and tasks of the Transport Organizer. Click on the object to select it, and from the menu select Object | Versions. With this facility, administrators have the ability to monitor the development work by seeing what has been modified when and who did it.

Version management is very useful for developers and also very important when performing upgrades, because it allows users to compare previous programs or customercreated programs or tables with those of the new SAP release. Developers can check or create versions from SE80, then select the object Utilities | Versions | Version. The system stores all versions of objects; they would occupy a lot of space. However, the SAP system stores them in the form of delta sets. This means that the system actually has one full version and the differences with the other versions. One version state is rebuilt by applying the deltas over the full version.

  • To view code of another SAP system, use the Remote Compare pushbutton.

This is helpful when doing SPAU/SPDD adjustments during maintenance or troubleshooting problems.

Requests Documentation

In order to have complete control over the development process, the Workbench Organizer system requires that the developers write some structured documentation for each request. The documentation screen appears automatically when releasing a task. To display a task or change request associated documentation, just click, select the transport request (double-click) and the Documentation tabstrip within the screen for displaying requests.

Repairs and Original Objects

An object original is a key concept in the Transport Organizer and the transport system, and a correct understanding of it will help you understand the inner workings of the software logistics around SAP systems. SAP repository objects are held in the table TADIR. This table includes the field SRCSYSTEM, indicating the source system for the object. The source system is the attribute that is used by the system to determine whether the object is original or not. An original object is a development object (table, report, form, screen, etc.) that has been created in the system in which you are working. When you receive your system and install it, you do not have any original objects in your own system: all objects contained in the repository have been originally created at SAP. When the development team members create new reports, tables, or other development objects, then they have originals, as long as they work on them in the same system in which they were created.

For example, you have a report program called ZRSP0001 that was created in system DD1 This means that the system owner (the source system) of the report is DD1. If you make modifications to this program in system DD1, you are making a correction to the program. However, suppose you transport this report to system PP1 without changing the source system or system owner of the object. Then, if anyone in system PP1 tries to modify the program, he or she will be making a repair to the object, because among the properties or attributes of the program, there is one (SRCSYSTEM) that says that the original system for that object is DD1 and not PP1. This is exactly the case when anyone tries to modify original SAP objects in his or her system.

Those object modifications are always repairs because the originals are at SAP systems, where they were developed. The objects' original location is a security measure to ensure that development objects remain consistent for all systems in which they are used, thus preventing parallel work on the same objects and ensuring that an original of each object exists in only one system. Corrections and development work can normally only be carried out on original objects in the original system they were created. This is a key concept because it makes a fundamental distinction between a correction/development task and a repair task:

  • If you modify an object in a system in which it was not created, then you are making a repair task.
  • If you modify an object in a system in which the object was created, then you are making a development/ correction task.

Note There are procedures to make objects appear as originals even if they were not created in the same system where they are being modified. That is one of the purposes of the relocations. The next sections describe in detail the procedures for handling repairs and change requests and how to change the system owner of a particular object. You can easily find whether a particular object is original in the system you are working. To do so, find the object by navigating either in the Workbench Organizer or by means of the Object Navigator (transaction code SE80) or directly from the ABAP Editor (transaction code SE38).

From the ABAP Editor you can see the original by choosing Goto | Object Directory Entry. The Original System field shows clearly the system in which the object was originally created. Notice that table entries do not have this field, because inserting or updating table entries is allowed in any system.

Object Directory EntryObject-Directory-Entry

System Types

Depending on the size of your SAP implementation (number of users and business modules to deploy) and the projects planned, you will install several SAP systems that serve different purposes in your system group. Normally, the implementation of SAP R/3 in a company requires the installation of several systems (meaning a different SID, which implies a different database server), each of which will serve a particular function.For instance, normally one system is used to carry out development and customizing work; this is later transported to the productive environment, which is the real system where end users connect and do their work.

Sometimes, though, you also need another system for testing special functions or new modules without affecting either the production or the development environments. The first distinction to make is that there are two perspectives when talking about system types:

  1. The perspective of their function—what they are used for in our installation: development, production, testing, training, quality assurance, and so on
  2. The perspective of Transport Organizer and transport system settings— consolidation, integration, recipient, special development systems The transport system allows a complex group of SAP systems to be set up.

For instance, you can set up several systems for distributing the development projects among them. You can also transfer special development work to another system, or you can finish and freeze the development work and make the transport system automatically distribute it to several other systems. Of course, if the needs are not so demanding, a classical three-systems landscape—one for development, one for quality assurance, and another for productive operation—will suffice to organize development and testing and productive operation. System types can be set to special change options to protect them from unwanted development or modifications. To do this, the Transport Organizer includes a utility that allows administrators to set the system change options.

System Change Options

With the System Change options, the project leaders or administrators decide how to set up the systems for new developments or customizing, ensuring the integrity of the systems. The available options are suitable for different types of systems and directly affect the functions allowed in the Transport Organizers and transport system. In order to reach and set the system change options, the user must have all the authorizations for the Workbench Organizer.

To reach the system change options screen, enter transaction SE06 in the command field, and then click on the System Change option button on the application toolbar. Alternatively, you can also get to the System Change options from the Transport Organizer tools (transaction SE03). On this screen, you will see a collection of functions and utilities to perform special transport tasks. The Set System Change Options function is located in the Administration folder. Open the folder and double-click on the Set System Change Options line.

Set System Change Options screen

Set System Change Options screen

The system displays two column tables, one for software components and the other one with the name ranges or namespaces for different types of objects. In order to enable modifications on any type of objects, you must first select the Global Setting option to indicate whether the objects from the repository or client-independent customization can be modified. You can only change System Change options in the name ranges when the Global Setting option is set to Modifiable. If you want to modify the Global Setting, just make sure you are in Change mode. If not, just toggle between Display and Change by clicking the Display/Change button in the application toolbar. If you want to enable modifications in any of the name ranges, just select the check box under the Modifiable column.

You can either set up each option individually to Modifiable or Not Modifiable, or from the Edit menu you can select subsets, for example, Software Components Not Modifiable, Own Namespace Modifiable, and so on. System Change options can also be set using special command options of the transport control program tp. For example, to set the system to objects cannot be changed in system DD1, as a sapdd1 user you can issue the command: tp lock_eu DD1.

Functions of the Systems

The type, function, and number of systems are a matter of factors such as budget, size of implementation, critical needs, and so on. However, even in the smallest installations a second system is almost a must, because it is really not a good practice and not recommended by SAP to do the customizing or development work in a productive system.From the point of view of the Transport Organizers and the transport system, the function of the systems as described previously is not really needed. What the Transport Organizer needs in the settings is to know which objects can be modified in every system, which system contains the original of the object, and how these changes should be transported to other systems.

Usually development or customization is not carried out directly in productive systems, because the risk of problems is high: a wrong program, a change in a table structure, or an incorrect customization can cause total system unavailability. However, where there are several systems available, the developers can isolate their work from real production work, minimizing the risk of impacting the productive work of the end users. When the development work is completed and tested, the new or modified objects and programs can then be transported. This object transport can further be tested for integration purposes in another system, or, if that step is not necessary and tests were successful, development objects can be transferred directly to the productive system.

From the point of view of functionality, a training system is often needed as well, although often a different client in the development or test system would normally suffice. If training is going to be intensive, for many users and parallel sessions, then an additional system could be the most convenient option. This training system could be built by performing a copy of the production system. Sometimes, it is also convenient to install a sandbox system for administrators.

Development Systems

As the name says, the development systems are where the development work takes place. Normally, the development is carried out for your own objects, making these objects originals from these systems. The development system is also used for customizing work, which includes functions to create automatically transportable change requests. From the point of view of the Transport Organizer, the development system is the integration system for the packages defined for your own objects. Original SAP objects can also be modified in these types of systems.

You should only do modifications to SAP objects when you need to change the functionality or you receive indications from SAP (OSS or hotline) to correct a bug. If this is the case, then you are making a repair. Hint OSS note 170183 details many types of modifications. In development systems, if repairs are permitted, the System Change option is normally set to enable modifications on all name ranges, including both customer and SAP objects.

Production Systems

The production system is where the end users enter real business data and where the actual business processes run. The production system only contains released versions of your development work. No development takes place in this system, or better, no development should be made in this system. Set the System Change option for your production system to Not Modifiable in the global settings. The production system is normally the consolidation system for your own packages and receives transportable change requests with your own development work from the development system.

If for any critical reason you need to perform repairs to the production system, then temporarily change the global settings of the System Change option to Modifiable to allow modifications in the required name range or namespace.

Test Systems

Test systems, normally known as quality assurance systems, are used to test the new developments and the customizing settings. Also, they can be used as distribution points of new developments. This does not mean that tests are not performed on the development system; what happens is that test systems often use real data for the integration tests.

Test systems are useful both for preparing the productive environment and for testing new developments with real data after the beginning of production. Often in SAP implementations, not every module or application becomes productive at once; it's a phased project where some applications become productive before others. When tests are validated, the development objects or customizing work can be transported from the test system to the productive environment.

System and client settings enforce strict adherence by SAP users that development and customizing is done only in the development system and not in the quality or production systems. This initialization is done at system setup before users are allowed in. Note that the global system change setting is done in SE06. The client role, changes to client-specific objects, and cross-client object changes are done in SCC4.

A Simplistic SAP Landscape

A Simplistic SAP LandscapeA Simplistic SAP Landscape

Table shows a simplistic SAP landscape where there is only one client in both development and quality. In a typical landscape, the development system will have multiple clients. For these clients different SCC4 setting should be used. For example, for a sandbox client you might have "Changes without automatic recording" and "No changes for Repository and Cross-Client Customizing Objects." Nonetheless the global system setting for test and production systems should always be "Not Modifiable."

The production client role allows some activities not allowed in other systems. Some transactions allow data to be changed within a transaction whereas on test systems a change request is needed.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status