Object Dependencies and Consistency

Dependencies Between Objects

The definition of BW objects can depend on other objects. These dependencies can be:

• Does not depend on other objects

  Example

  InfoObject Calendar Date does not reference any other objects.

• Depends on other objects of the same type

  Example

  InfoObjects that have attributes: The attributes that are entered are also InfoObjects that must exist in order for the InfoObject to be consistent.

• Depends on objects of a different type

  Example

  InfoCubes contain InfoObjects

• Depends on non-transportable objects (local to the system)

  Example

  The DataSource depends on the source system; the source system cannot be transported.

• Depends on objects of a different type that depend on objects that are local to the system

  Example

  The transformation depends on the DataSource, which in turn depends on the source system.

Consistent Requests

In addition to the version concept, the help for creating consistent requests is the second important BW enhancement to the standard transport system.

Object dependencies do not only exist in the BW system. ABAP Workbench objects can also be dependent on one another. For example, a request is inconsistent if it contains a program that accesses a database table that is not exported. When such a request is transported, the table is missing in the target system and the program thus contains syntax errors in the target system. At development you should therefore make sure that all dependent objects are assigned to the same package, or at least to a package in the same transport layer, and that they are included on the same request.

Consistent requests that take object dependencies into consideration are especially important in BW because the metadata objects are activated in the import postprocessing step. If dependent objects are missing in the transport request, this results in errors during activation. These errors are displayed in the log for the transport request.

Creation of a consistent request is more difficult in the BW system than for program objects for the following reasons:

• The (BW modeler) user group that is addressed does not normally handle delivery questions.

• Since they are not transported, it should be possible to create test objects without having to write them in a transport request.

• There is a large number of object types, and the dependency of the objects on one another is complex.

• In addition to the technical dependency, which results in inconsistencies, there are other types of dependency that make it easier to transport an entire scenario.

Therefore the system performs a consistency check immediately before a task or request is released. You can find additional information under Consistency Check when Releasing Transports.

Tools

For the above reasons, there are separate function areas in the Data Warehousing Workbench for transport and for the BI Content activation of objects. These areas work similarly and can be accessed directly with transaction codes RSOR and RSORBCT.

For more information about how the areas work: Collecting Objects.

Individual Object Dependencies

There are the following basic types of object dependency:

• Required

• Has Subobject

• Used By (opposite of Required)

• Send Data To

• Receives Data From/ Belongs to Scenario

There are also some less important dependencies, such as Is Visible In or Scheduled By.

These dependencies are mapped to the grouping modes when the objects are collected.

• Necessary Objects Only: Contains all the objects of the dependencies Required and Subobject recursively.

• In Previous Data Flow: Contains all necessary objects and those of the dependency Receives Data From recursively. Recursiveness regarding the dependency Receives Data From, however, is terminated at the level of the attributes of InfoObjects in order to restrict the number of objects.

• In Subsequent Data Flow: Contains all necessary objects and those of the dependency Sends Data To.

By choosing the context menu entry Collect Optional Objects you can collect objects with the dependency Used By for an object of the object set.

• In function module RSO_<TLOGO>_GET_RELATED, where <TLOGO> is the name of the logical transport object.

• In method IF_RSO_TLOGO_GENERAL~GET_RELATED the class, which you can find in the table RSTLOGOPROP.

  More information about the names of the logical transport objects and table RSTLOGOPROP: Transportable Object Types

  More information: Defining Grouping Mode

Object Dependencies of Selected Object Types

The dependencies of some important object types are displayed graphically below. The figures are limited to the three dependency types Has Subobject, Required, and Receives Data From.

For clarity, not all of the dependent object types are displayed for each object type, and the relationship Sends To is not shown; normally it is the reverse of Receives From.

Staging Objects in the Data Flow

In comparison to the data flow 3.x (see below), the triple transfer rule, transfer structure, and DataSource 3.x were replaced with the two objects transformation and DataSource. The transformation is also included in the update rule. The tuple InfoSource 3.x and communication structure are also combined in the object InfoSource.

The DataSource does not refer to the source system. On the other hand, the source system still has the relationship Sends To with regard to the DataSource (not indicated in the graphic). This relationship is important for collection mode For System Copy (more information: Collecting Objects).

More information about the objects indicated in gray: Special Features of Source System-Dependent Objects.

Staging Objects in the 3.x Data Flow

In this figure, the InfoObject is displayed in two roles: As a component of a structure object and as the target for master data and text load processes.

Note the interaction of the transfer rule, transfer structure and DataSource 3.x: All 3 objects must be transported at the same time in order for the request to be consistent. The same is true for the InfoSource 3.x and the communications structure.

More information about the objects indicated in gray: Special Features of Source System-Dependent Objects.

Process Objects

The process variant is indicated twice since it is used as a container for very different processes; in particular, it is used as a container for both source system-dependent processes in the data part as well as for processes that are not source system-dependent (more information: Classification of Source System-Dependent Objects).

More information about the objects indicated in gray: Special Features of Source System-Dependent Objects.

Reporting and Analysis Objects

The query element object occurs more than once because it is used to transport very different element types, such as queries, calculated key figures or variables. The dependencies of these element types differ.