DEPENDENCIES OF DICTIONARY OBJECTS XV

DEPENDENCIES OF DICTIONARY OBJECTS"

During development, you sometimes need to change an (active) object already used by the system.

Such changes are supported in the ABAP Dictionary by separating the active and inactive versions.

The active version of an ABAP Dictionary object is the version that the components of the runtime environment (for example ABAP processor, database interface) access. This version is not initially changed.

An inactive version is created when an active object is changed. The inactive version can be saved without checking. It has no effect on the runtime system.

At the end of the development process, the inactive version can be made the active version. This is done by activation. The inactive version of the object is first checked for consistency. If it is consistent, the inactive version replaces the active one. From now on, the runtime system uses the new active version.

The above example shows how the object status changes. An active structure contains three fields. A field is added to this structure in the ABAP Dictionary. After this action, there is an active version with three fields and an inactive version with four fields. During activation, the active version is overwritten with the inactive version. The inactive version thus becomes the active version. After this action there is only the active version with four fields.

The information about a structure (or table) is distributed in the ABAP Dictionary in domains, data elements, and the structure definition. The runtime object (nametab) combines this information into a structure in a form that is optimized for access from ABAP programs. The runtime object is created when the structure is activated.

The runtime objects of the structures are buffered so that the ABAP runtime system can quickly access this information.

The runtime object contains information about the overall structure (e.g. number of fields) and the individual structure fields (field name, position of the field in the structure, data type, length, number of decimal places, reference field, reference table, check table, conversion routine, etc.).

The runtime object of a table contains further information needed by the database interface for accessing the table data (client dependence, buffering, key fields, etc.).

Runtime objects are created for all ABAP Dictionary objects that can be used as types in ABAP programs. These are data elements, table types and views, as well as structures and tables.

If an object that is already active is modified, this can affect other objects that use it (directly or indirectly). These objects using another object are called dependent objects. On the one hand, it might be necessary to adjust the runtime objects of these dependent objects to the changes. On the other hand, a change might sometimes make a dependent object inconsistent.

For this reason, the dependent objects are determined and activated (if necessary) when an active object is activated. The active versions of the dependent objects are activated again. In particular, new and inactive versions of objects using the changed object are not changed.

Example: When you change a domain, for example its data type, all the data ele ments, structures and tables referring to this domain must be activated again. This activation is automatically triggered when the domain is activated. This ensures that all affected runtime objects are adjusted to the changed type information.

If an ABAP Dictionary object has a table as dependent object, its database object as well as its runtime object might have to be adjusted when the dependent object is activated. The method used here will be discussed in the next unit.

Changing an ABAP Dictionary object might also affect its dependent objects. Before making a critical change (such as changing the data type or deleting a field) you should therefore define the set of objects affected in order to estimate the implications of the planned action.

There is a where -used list for each ABAP Dictionary object with which you can find all the objects that refer to this object. You can call the where-used list from the maintenance transaction of the object.

You can find direct and indirect usages of an ABAP Dictionary object with the where-used list. You also have to define which usage object types should be included in the search (e.g. all structures and tables using a data element). You can also search for usages that are not ABAP Dictionary objects (e.g. all programs using a table). The search can also be limited by development class or user namespace.

If an object is probably used by several objects, you should perform the search in the background.

The Repository Information System ABAP Dictionary is part of the general Repository Information System. It helps you search for ABAP Dictionary objects and their users.

The where-used list for Repository objects can be called from the information system. The information system also enables you to search for objects by their attributes.
In addition to the object-specific search criteria (e.g. buffering type for tables), you can search for all objects by development class, short description or author and date of last change.

The object lists created by the Repository Information System are entirely integrated in the ABAP Workbench. They permit you to navigate directly to the maintenance transactions of the objects found.


RELATED POSTS