Object Dependencies and Consistency 

Dependencies Between Objects

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

...

●      Does not depend on other objects

InfoObject Calendar Date does not reference any other objects.

●      Depends on other objects of the same type

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

InfoCubes contain InfoObjects.

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

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

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

Consistent Requests

In addition to the versioning concept, the help for creating consistent requests is another BI enhancement to the standard transport system.

Object dependencies do not only exist in the BI 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. The table is missing in the target system when such a request is transported. The program therefore contains syntax errors in the target system. During 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 in the same request.

Consistent requests that take object dependencies into consideration are especially important in BI 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.

It is more difficult to create a consistent request in the BI system than for program objects for the following reasons:

●      The (BI modeler) user group that is addressed does not normally handle delivery issues.

●      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.

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: Details.

We recommend that you always use the function area Transport Connection (BI transport system) or the standard transport system to create a transport request (whether you want to transport active objects or delivery versions), and that you do not create transport requests manually. You will only be able to manually create a request with BI objects consistently if you have considerable experience and if you do not have too many objects.

More information about the differences between the BI transport system and the standard transport system: Recording Time for Transports

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 Data Flow Before: Contains all necessary objects and those of the dependency Receives Data From recursively. To restrict the number of objects, recursiveness regarding the dependency Receives Data From, however, is terminated at the level of the attributes of InfoObjects.

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

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

The dependence of BI objects on one another is defined at one of the following two locations, depending on the object type:

■       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 of 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 shown 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 types of elements, such as queries, calculated key figures and variables. These element types have different types of dependencies.