Describing Software Logistics for AS ABAP based SAP systems

There are several reasons for setting up a multisystem landscape. First, continuous maintenance is required for all SAP systems. Either SAP or the customers trigger such maintenance. Corresponding changes of program code or customizing data might be mission-critical and should be tested beforehand. Second, audits require detailed logging of transport requests. Thirdly, ABAP repository objects work across clients. In other words, changes made in one client immediately affect all other clients of the same SAP system after activation. That is why you should never develop or change customizing settings directly in the production system. Client settings should prevent such changes. This is why we recommend that you use a multisystem landscape. You can operate several SAP systems with one SAP license, although you may only use one of these SAP systems as a production system.

In the following, let us take a three-system landscape as an example of a multisystem landscape. Each of these three SAP systems contains a working client and other clients as required. With respect to the consistency of customizing settings across all of the systems, it would make it easier if these three working clients had the same name (three-digit number).

A three-system landscape facilitates the following recommended process:

• You can carry out the required customizing for the SAP standard processes in the development system. You can also develop your own programs or change existing ones in the development system.

• You then transfer the customizing settings you made, as well as all changes to the repository (developments, corrections, and modifications if needed) to the quality assurance system (also called test system for short) . In the test system, you can check in a stable environment without impacting the production operation.

• After a successful test, all objects and settings imported into the test system can then be transferred into the production system.

The SAP systems in a system landscape must have unique, three-character descriptions, for example, DEV (development), QAS (quality assurance), and PRD (production). These abbreviations, which also occur in other courses, are used internationally in the SAP environment.

The SAP system ID (or for short: SID) always begins with a letter, and it may contain letters and digits. SIDs always consist of three characters. Some SIDs are reserved by SAP. For instance, you cannot use the SID SAP to install an SAP system. You can find more information in the installation guide for the related SAP system type you want to install.

In a multisystem landscape, you use transport requests to transfer changes for repository objects (or newly created objects) and customer-defined customizing settings from one SAP system into another.

The Transport Organizer (transaction SE09) helps you to log

• changes to repository objects and to cross-client customizing as workbench requests
• Changes to the client-specific customizing analogously as customizing requests

Both request types are also combined under the name transport requests.

The development project leader creates a project and activates its integration into transport management, that is the recording of transport requests for this project. Then the leader creates the smallest number of transport requests possible for this project and then assigns the developers to the transport requests. The development project leader is also responsible for the later release of the transport requests once the relevant development is completed.

The development project leader assigns the developer to one or more transport requests. The developers make developments for their transport requests, which in turn are assigned to a project. This may concern creating or changing repository objects or customizing settings. The developers work in the development system.

The testers are responsible for the technical acceptance. This technical acceptance is done in the quality assurance system. The quality assurance system is a copy of the production system so that tests are possible with realistic data and realistic process flows.

The transport administrators are responsible for setting up a transport concept. They carry out imports for the transport requests in a structured manner.

The Transport Organizer automatically creates a task for this transport request for every employee to whom the transport request is assigned. If a developer assigns a newly created or changed repository object to the transport request, the creation or the changes to this repository object are recorded in the task of that person.

Workbench requests are transport requests for transporting client-specific customizing and repository objects.

Customizing requests are transport requests for transporting from cross-client customizing.

Let us consider the changes of repository objects (which lead to a workbench requests) as an example.

If developers edit a repository object and include it in a transport request, then only those developers who are assigned to this transport request can edit the object. For this, an object lock is created.

Every developer who is assigned to the transport request and who edits the object, automatically creates a corresponding entry in the object list of their task. In this way, it is possible to determine later which developer actually edited the object.

Upon release of the transport request, the system deletes the object locks. As a consequence other developers can again edit the objects (and record the changes in a different transport request, the system then locks the objects again accordingly).

During the release of a transport request, the Transport Organizer also creates versions of the repository objects, allowing comparisons of and access to earlier versions of repository objects. This way, you can display and retrieve older versions of repository objects.

Watch this video to learn about the steps in the development process:

Once the development work concerning a testable unit is complete from the point of view of the developers, they release the related task. This action transfers the object list of the task to the transport request. Once all developers have released their task, the development project leader can release the transport request. In this way, a transport request combines customizing objects or repository objects that form a testable unit.

Transport requests may be transportable or local. The Transport Organizer classifies automatically based on the objects contained in the transport request and the configured transport landscape. The system triggers the export only for transportable transport requests after the release. Export means that the system copies the objects of the transport request from the database of the development system into a file on the file system (see the following figure).

The transport of transport requests is divided into Export and Import phases: The objects of the transport request are exported from the development system and then – in a separate step – imported to the target system, such as to the quality assurance system and the production system.

• Export: Once a transportable transport request is released, the customizing objects and repository objects are copied from the source database to a central transport directory at file system level. The system records these steps in transport log of the transport request.
• Import: Import into the target system is in general not automatic, but is triggered by the transport administrator in the Transport Management System (TMS). The customizing objects and repository objects are then copied from the central transport directory at the file system level into the target system database. The import logs, which are created automatically, can then be checked.

The central transport directory is physically in a file system where all SAP systems that belong to the system landscape must have read and write access.