The SAP system stores development objects in the R/3 Repository, which is a part of the database. When you complete work on a development object like a program, screen, or menu, you generate a runtime version of the object. This runtime version is stored, along with the object, in the Repository. An application consists of several runtime objects that are processed by the work processes in the R/3 System. In a standard SAP installation, development and live operation take place in separate systems. New applications are created in the development system and transported to the production system. Daily work takes place in the production system which uses run-time versions created in the development system. The division between production and development systems is recommended because changes to an existing ABAP application take immediate effect. To prevent disturbances in daily work flow in the production system, all developments are carried out in development systems designed especially for this purpose.

The Workbench Organizer

You use the Workbench Organizer and the transportation system to move applications from the development system to the production system. The Workbench Organizer also provides version control and tracking. When you work with the Workbench, you will encounter safeguards provided by the Workbench Organizer.

Development in a Team Environment

ABAP allows you to divide work on large projects among several programmers. Consider an accounting application project with an accounts payable module and an accounts receivable module. The ABAP environment helps you create a work area in the system for the project. You can then assign tasks to each programmer and follow his or her work as it progresses.

The tool you use for tracking development projects is called the Workbench Organizer. The Organizer tracks changes to existing SAP development objects and the creation of new objects. If you create a new object, the Organizer asks you for a development class when you try to save the object.

The Organizer uses the development class to determine whether a change request is required. A change request records the changes made to one or more development objects. The $TMP development class contains local objects. Local objects are not transported and so the Organizer does not monitor them.

If you specify a non-local development class, the system prompts you to enter a change request. The system also queries you for a change request the first time you attempt to change an existing non-local object.

When you associate a change with a request, the system creates a task for you under that change request. The organizer creates a task for each programmer making a change under a change request. You can think of a change request as a container of change tasks. Once you associate an object with a change request, the system views the objects as under development. The object is locked and cannot be changed by other users. When you have finished creating or changing an object, you release your task. To transport your changes to a production system, you release the change request that held your task.

You can change the development class and change request associated with an object. For more information about changing the development class of an object, the Workbench Organizer and the transport system, see the Workbench Organizer documentation.