Show TOC

BI Content Analyzer ChecksLocate this document in the navigation structure


The check programs determine errors and inconsistencies of the BI Content objects of the BI system. The selection according to which routines the selected objects are handled are made when you assign check types (Settings → Check Execution).

Check types can be grouped by assigning identical job names. Check types with identical job name are executed simultaneously. Some check types can be executed as a Multi Check. Check types have a two-digit ID.

Each check type has at least one subordinate check category. Check categories are used in the BI Content Analyzer to filter the check results in the results area. Check categories have a three-digit ID.


The following tables provide an overview of all check types and their categories.

Type: Object Status- Check (Multi)

Type ID Assigned Check Categories Categ. ID Standard Priority


Object Status: A Version Newer Than D Version

  • Development system: The developer does not see the object version for delivery. Either an old object has been saved in the system as a D version or is not saved correctly due to incorrect system settings.
  • Test system: The tester sees incorrect versions. Either A versions were imported or D versions are activated in the D versions.



Object Status: D Version Newer Than A Version

  • Content activation failed or has not yet taken place.



Object Status: No A Version Available

  • Content activation failed or has not yet taken place.



Object Status: No D Version Available

SND is only executed for development systems because there is no D version in test systems.

  • Writing the D version does not work. The system settings should be checked.



For more information on the various object versions, look in the SAP Library under SAP NetWeaver  → Information Integration → SAP Business Information Warehouse → Data Warehousing → Data Warehouse Management → Business Content (Versions).

Type: Checking for Object Collection Errors (Multi)

Type ID Assigned Check Categories Categ. ID Standard Priority


Object Collection - Collection Error

CCE should be executed for test systems.

  • The object links to an object that does not exist. Not every object can be collected in the data flow, because
    • , due to the assignment to package $t TMP, whose import from the development system failed or
    • the Repository Cache was not updated. In this case, you update the cache using transaction RSOR   → Extras → Repository Cache (DB) → Fill (Objects form Delivery).

    The object collection or activation using transaction RSOR leads to an error message.



Object Collection - Temporarily Saved Objects

COT should be executed for development systems.

  • The object references a locally saved (package $TMP) object. As soon as the object is transported into a new system, the local object disappears.
  • Change the development class of the locally saved object to a transportable development class or ensure that the collected object is not transported.



Type: Checking for Inconsistent Naming Conventions(Multi)

Type ID Assigned Check Categories Categ. ID Standard Priority


Naming Convention Ignored

  • The object does not following the naming conventions for partner and customer namespaces. Under Settings  → Global Settings, determine which of the namespaces is to be checked. In addition: Only when you have released packages for the objects can a naming convention check be done in a customer system. For information on releasing packages, seeReleasing Packages. In this case, you should select the option AND Linking in the Global Settings.
  • Change the object name.



Type: Checking for an Inactive Transfer Structure

Type ID Assigned Check Categories Categ. ID Standard Priority


Inactive Transfer Structures

  • The transfer structure was either changed manually or through the replication of assigned DataSources. As long as reactivation has not occurred (transaction RSA1 → InfoSources), loading of data and the objects that are part of the import failed.



Type: Checking for InfoObjects without an InfoObject Catalog

Type ID Assigned Check Categories Categ. ID Standard Priority


InfoObject without InfoObject Catalog

  • When the InfoObject was created, there was no assignment to an InfoObject catalog. If the assignment has not been done, the InfoObject does not follow the Content standards and is assigned to one of the following standard categories:



Type: Checking for Inconsistent Roles

Type ID Assigned Check Categories Categ. ID Standard Priority


Roles to Which Unavailable Objects Are Assigned

  • A object was deleted but not its assignment to a role. This leads to inconsistencies and collection errors as long as the assignment was not also deleted in transaction PFCG.

    You can use transaction PFCG  → Menu to check the existing object references to the role.  You can check the existence of the referenced object using its name. The transaction RSRT (for query elements) or the report RS_TEMPLATE_MAINTAIN (for templates) can also be helpful here.



Type: Checking for Query Elements with Duplicate GUIDs

Type ID Assigned Check Categories Categ. ID Standard Priority


Query Elements with Duplicate GUIDs

  • A query element is defined by
    1. its technical name, for example 0SBO_C11_Q003, which you enter manually.
    2. the COMPUID (GUID), the unique object key, for example 037OLMX9GF8CK9P23IV2MDO1H, which is generated automatically.

    If queries with identical technical names are generated in different BI systems, these elements have a different GUID. This means that 2 GUIDs exist for the identical technical name during a transport of both objects into a common system.


    System A:

    • Technical name: ABC_Q001
    • GUID : 123456789

    System B :

    • Technical name: ABC_Q001
    • GUID : 987654321

    After transport into system C:

    • 2 objects for the technical name ABC_Q001
    • GUID object 1 : 123456789
    • GUID object 2 : 987654321

    This means that inconsistencies will occur during query executions because the system selects one of the two GUIDs randomly.

  • Within the system landscape, check table RSZCOMPDIR by entering the technical name of the query element in field COMPID. You will see multiple objects displayed for different versions with different GUIDs.

    Try to determine the correct object version using the Content time stamp.

    Now proceed according to SAP Note 541024 and change the technical name of one of the objects.

  • If you are sure which object is incorrect, you can also delete this object using transaction RSZDELETE by selecting a COMPID.

    Deleted objects cannot be restored. Deletion in a development system also has to be exported so that the problem is eliminated in the follow-on system.



Type: Checking for Routines That Refer to Fixed, Programmed Structures

Type ID Assigned Check Categories Categ. ID Standard Priority


Routines with Fixed, Programmed Structures (/BI*/*)

  • If there are references to generated BW-DDIC structures or types such as /BIC/* in routines, it can lead to problems during the transport or during Content installation (RSOR).

    If the referenced structures do not yet exist at the time of import or Content installation because the affected BI object is not active in the system, it could lead to termination.

  • The routines should be programmed dynamically. These dynamic assignments could appear as follows:

    *.. data definitions for internal table and work area

    data: lt_data type ref to data.

    field-symbols: <t_data> type standard table.

    *.. store name of structure (infocube 0FIGL_C01) as string

    constants: c_tabname type rstlogotab value '/BI0/V0FIGL_C012'.

    *.. create internal table and assign it to <t_data>

    create data lt_data type table of (c_tabname).

    assign lt_data->* to <t_data>.