Concept 

Terminology

There are the following essential new terms used in the context of inactive sources:

Term	Meaning
Active version	The database version of a development object used to generate the runtime object
Inactive version	A saved database version of a database object that does not affect the runtime object (even after regeneration).
Inactive object list	The set of all inactive versions of development objects belonging to a particular user. When a user edits a new object, it is added to his or her inactive object list. When a user activates an object, it is removed from the inactive object list. Leaving aside local private objects ($TMP), a user's inactive object list is a genuine subset of all of the objects he or she is working on and that are included in open tasks administered by the Workbench Organizer.

Motivation

The introduction of inactive sources provides developers with a separate local view of the Repository, and is the basis for a "local runtime system".
Changes to development objects can be tested within this local system without disturbing the wider development environment.

The main advantage of this is that the development process becomes seamless. For example, it makes it possible for you to change the interface of a function module without the changes immediately becoming visible in programs that call it. The changes are only visible systemwide once the object has been activated.

Furthermore, the concept avoids redundant program generation of ABAP programs. Previously, the system always generated a new load version whenever you saved a program in the ABAP Editor. The introduction of inactive sources means that the program is not generated until you decide that it is appropriate to activate it.

The introduction of inactive sources is accompanied by a standardization of the working methods of the different ABAP Workbench tools. Consistency is also assured by the main program check that is performed whenever you activate an object.

Concept

§         Objects are always saved as inactive versions.
When you create or change a development object and then save it, an inactive version is written to the database.

§         Inactive objects are included in the user's inactive object list.
Development objects that have been edited and saved are placed in the inactive object list of the developer responsible. Each user has their own inactive object list, which other users cannot access directly. Users always work with their own personal inactive object list.

§         You can link inactive object lists.
If another user changes a development object and saves it, the object is included in his or her inactive object list.

§         The ABAP Workbench tools always take into account the user's inactive object list.
In display mode, the user always sees objects from his or her own inactive object list in their inactive version, but all other objects in their active version (even if an inactive version exists). This particularly applies to navigation within the ABAP Workbench.
In change mode, the latest version is always displayed, regardless of whether it is included in the user's inactive object list or not.
All tools display the current status of the object that you are currently working on. See also Status Display.

§         You can display an overview of your work list and of all inactive objects in the system. See also Overview of inactive Objects.

§         You activate your inactive object list when you choose.
Furthermore, you can decide whether to activate the whole inactive object list or just a part of it. When you activate an object, it is removed from the inactive object list. For further information refer to Activating Objects.

§         Only the active version of an object is used to generate runtime objects.

§         Support in the Workbench Organizer.
All members of a project team can work on a single object that belongs to the change request in which they all have tasks. Consequently, all team members will see the inactive version of an object in display mode, if one exists.
Users without a task in the change request cannot change the object, and therefore see the active version in display mode.
You cannot release a transport request until all of its objects have been activated.