The CTO 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

Software is developed in multiple systems simultaneously. Therefore, for large implementation and development projects, SAP recommends using an R/3 System landscape consisting of a minimum of three R/3 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 CTO 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 works with an object must specify a change request in which the object is to be included. The object is then locked for this change request only. Users not assigned to a task within this change request can no longer make changes to this object.

Once the change request is released, all object locks are deleted and the objects are once again accessible to all developers.

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.

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 receiving systems. Thus authorization for this procedure should only be given out with caution.

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

A standard SAP System is shipped with a large number of development classes, to which the R/3 objects in the system are assigned.

You cannot use the development classes which are shipped with the system for your own objects, since only SAP standard objects may be created in them. Therefore, the first thing you have to do when starting to develop is create the development classes, to which your objects will be 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 development classes.

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

Development classes are themselves objects in the ABAP Workbench. When you create a new development class or change an existing one, it is recorded in the Change and Transport Organizer, and the change can be transported into other SAP Systems.