General Development Organization

Use the Transport Organizer of the ABAP Workbench to make modifications and facilitate customer development. The following sections introduce you to the concepts behind the Transport Organizer. For more information, see Transport Organizer.

Transport Organizer

The Transport Organizer is an integral part of your software development environment. It supports customer modification of SAP software by:

Allowing for ordered development by multiple users (with competing accesses) in a distributed development environment
Providing distribution logic for automatic distribution of the software that has been developed

Note

Changes in the SAP namespace are not recognized when the Transport Organizer has been disabled and are reset at upgrade. Therefore, please ensure that the Transport Organizer is activated before making any modifications. You can activate the Transport Organizer from transaction SE03 using Administration → Set system change option. To do this, you need administration authorization for the Change and Transport System.

Software is developed in multiple systems simultaneously. , for large implementation and development projects, SAP recommends using a system landscape consisting of three SAP Systems:

One system should be used for development (enhancements to the standard, evaluations...)
A second for testing and quality assurance, and
A third system as a production system.

Within this kind of landscape, transports must take place between systems. These transports are automatically created and scheduled by the transport system. The transport paths, as well as the properties of the individual systems, are stored in system tables.

A project that several employees are working on simultaneously is represented in the Transport Organizer by a single change request to which several tasks refer. Each task is assigned to a single project member.

The change request collects the contents of these tasks. It can only be released (for transport) when all tasks that refer to it have been released themselves, that is, when all project members have completed their work. Once a change request is released, the system automatically begins to export all of its objects.

The first user who starts work on an object has to specify a change request where the work will be recorded. The object is then locked exclusively for this change request. The object cannot be changed by other users who do not have a task in the change request.

Object locks are deleted when change requests are released. The objects can then be edited again by all developers.

Repairs

Every software object in a distributed SAP development environment is uniquely assigned to its original system. In its original system, an object cannot be overwritten by transport from another system.

This localization principle makes a special kind of correction necessary, called a 'repair'. Repairs are changes to objects whose original is found in a system other than the one currently being worked in. Repairs, for example, can become necessary when an error is discovered in an object which urgently needs to be corrected.

Whenever a customer or a consultant makes changes to SAP objects (in other words, carries out a modification), these constitute repairs since the original objects belong to SAP systems. If a change is assigned to a repair that has been released, it is not overwritten at release upgrade.

Repairs and corrections can be combined in the same request. They are assigned to local or transportable change requests in accordance with the data in the transport control tables.

In customer developments or changes to the SAP standard, repairs and corrections are entered in either local or transportable requests. If your changes are automatically assigned to local change requests even though you want to transport them into other systems, you need to change your system configuration.

Assigning Authorization

The fact that changed objects are collected in requests and transported into the next system once they have been released almost automatically ensures system consistency. However, it must still be possible to change transport requests manually, for example, to stop certain objects from being transported. Manual alteration of change requests can lead to inconsistent data in receiving systems. Thus authorization for this procedure should only be given out with caution.

For more details on assigning authorizations in the Transport Organizer, consult the Authorizations section of the Transport Organizeronline documentation.

Packages

To ensure a structured system and to enable you to keep an overview of objects, the objects in the ABAP Workbench are organized as packages. A package is a group of development objects which logically belong together.

A standard SAP System is shipped with a large number of packages, to which the objects in the system are assigned

You cannot use the packages which are shipped with the system for your own objects, since only SAP standard objects may be created in them. When development work starts, you must first create a package to which the new objects are assigned. You then need to establish thematic divisions for the objects you want to create. For each theme or application, you then create one or more packages.

Whenever you create a new object in the ABAP Workbench, the system asks you to which package it should be assigned.

The packages are themselves objects in the ABAP Workbench. When you create a new package or change an existing one, it is recorded in the Transport Organizer, and the change can be transported into other SAP systems.

Developer:	Authorization to release a task to a request
Development coordinator:	Manual adjustments to a request Creating a new request, creating a new task for a project member, releasing a request (exporting the objects in the request)
System Administrator	Importing the exported objects into the target system