Executing Checking and Conversion Programs 

Use

The BI Background Management, Logs and Tools screen offers you the following checking and conversion programs:

●      Checking and conversion programs after an upgrade to SAP NetWeaver 7.0:

○       Create hash values for scheduler selections (report RSSM_HASH_ENTRIES_CREATE)

After running the report, system performance improves when the same request selections are found. This check is always performed when a new request is to be generated. Without mapping the selections to hash values this can take several minutes.

This report must

○       build fast access tables (reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA)

To improve performance when displaying requests (in InfoProvider administration, for example) and loading data, in SAP NetWeaver 7.0, the administration information for requests is stored in special tables (RSSTATMANPART and RSSTATMANPARTT for InfoProviders and RSstatmanpsa and RSstatmanpsaT for PSA tables). This allows quicker access to the information. These quick access tables are part of the status administration that makes managing requests easier. The reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA write available request information for existing objects to the new tables to enable quicker access. They also fill the status management tool with the existing data. These reports primarily serve to transfer existing data to the new administration tables. The request information for newly loaded requests and objects created after the upgrade is automatically written to the new table.

It might be necessary to execute the reports again after the upgrade if the request status is inconsistent.

It is mandatory that these reports be executed after an upgrade. They are also required in order to archive request administration data.

●      Checking and repair program for InfoPackages

If you are running a BI system as a content development system, inconsistencies might occur between the A and D versions of the InfoPackage and between the shadow version and cross-reference table RSSHIPDVERS. You can display and report this and other inconsistencies of InfoPackages with the report RSSM_SHIPDVERS_CLEANUP.

More information: InfoPackage

Procedure

Executing Checking and Conversion Programs after an Upgrade to SAP NetWeaver 7.0

You are on the BI Background Management, Logs and Toolsscreen (transaction RSBATCH). Perform the following steps in the given order:

...

       1.      To create hash values for scheduler selections, execute report RSSM_HASH_ENTRIES_CREATE:

                            a.      On the Reports tab page, choose Start Hashing.

                            b.      On the next selection screen for the report, select Hash All Requests.

                            c.      Define the number of parallel background processes for processing the report.

                            d.      Choose  Execute.

With the report, internal tables are built for each request. These tables contain the various selections of the request and mark each of them with a 40-character hash value.

The hash values for the selections are stored in the RSSELDONE (field SEL_HASH, data selections) and RSREQDONE (fields META_HASH - miscellaneous meta selections, TCP_HASH - third-party selections, LDT_HASH - InfoPackage texts, RULE_HASH, routines, UIC_HASH - data target selections) tables.

Afterwards entries for each hash value are generated in the following tables:

○       RSHASHCTRL (Control table before hash key for RS*DONE tables)

○       RSHASHDATA (Data for hash encryption)

○       RSHASHMAP (Mapping hash key for InfoPackage ID)

○       RSHASHTYP (Type of hash key)

If a new request is now generated, the system first maps the selections of this request using hash values and then checks whether the new hash keys SEL_HASH and TCP_HASH are already in table RSHASHMAP as a triplet. If this is the case, there has already been a request with these selections and the system transfers the InfoPackage ID from the RSHASHMAP table. If this is not the case, a new InfoPackage ID is generated and entered into the RSHASHMAP table. The six new hash values are entered in the RSHASHCTRL and the RSHASHDATA tables, if they are not already entered. Table RSHASHTYP is for a later version.

       2.      To copy existing administration information into the new administration tables of the status management for SAP NetWeaver 7.0, run the two reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA for all objects (InfoProvider and PSA tables) at least once in the background:

                            a.      On the tab page Reports choose Edit Loadable InfoProviders (for report RSSTATMAN_CHECK_CONVERT_DTA) or Edit PSA Tables (for report RSSTATMAN_CHECK_CONVERT_PSA).

                            b.      On the next selection screen, select the objects for which you want to execute the report.

                            c.      Make the settings for parallel processing.

We recommend that you provide these reports with as many resources as possible.

                            d.      Execute the report in the background.

When you execute check and conversion programs, the system checks the status of all requests for the selected objects, changes or includes entries as required, and deletes the entries for deleted requests.

For large systems with hundreds of InfoProviders (and a similar number of PSA tables) as well as hundreds of thousands of requests, both of these reports can take several hours to run, even if many jobs are executed in parallel.

       3.      To make sure that your BI objects were converted correctly, run the check report RSSM_CHECK_ALL_UPGWRK_DONE. On the Reports tab page, choose Start Check Report.

The report is executed directly and, after the check, shows whether the reports for creating hash values and for building fast access tables executed correctly or if further actions are necessary.

Executing Checking and Conversion Programs if the Request Status is Inconsistent

After an upgrade, you should execute the reports RSSTATMAN_CHECK_CONVERT_DTA and RSSTATMAN_CHECK_CONVERT_PSA again if the contents of tables RSSTATMANPART or RSSTATMANPSA or the status or information for the request were inconsistent. Incorrect traffic lights or deleted requests might still be displayed in the administration of the InfoProvider. Note that the reports should only be executed if there are inconsistencies, and not periodically.

In this case proceed as described above. Specify whether you want to check status management. This check is only recommended if the reports have already been executed. It is also useful if you find inconsistencies in the status management for the requests, for example if the system continues to display deleted requests in InfoProvider administration or displays the incorrect request status even after the reports have been executed.

Checking and Repairing BI Content InfoPackages

You are on the BI Background Management, Logs and Tools screen (transaction RSBATCH).

...

       1.      On the Reports tab page, choose Check/Repair of InfoPackages.

                            a.      If the system is not defined as a content development system, General Checks is defined as the default value in the next selection screen.

If you also want to examine all the InfoPackages in the shadow table RSLDPIOSH, but not in the table RSSHIPDVERS with the report, select Check Shadow InfoPackages.

                            b.      If the system is defined as a content development system, you can select Special Content System Check on the selection screen.

       2.      Execute the report.

The result list shows the A version, D version, and shadow version as well as whether there is an RSSHIPDVERS entry. If this entry is missing, an empty field is displayed. The column Repair to be Performed describes which repair would be necessary.

Once you have performed the general checks, you can hide various symptoms, such as Find shadow InfoPackages without D (and SHIPDVERS entry) from the display by choosing  Set Filter.

       3.      Select the InfoPackages that should be repaired and choose  Repair.

If there are A and D entries, but no RSSHIPDVERS entries, for a D entry, the system tries to find a suitable shadow InfoPackage with an identical name and selection.

After a successful repair, the system displays the suitable shadow InfoPackage in the column Shadow Version of InfoPackage.

If the repair was not successful, the system displays an input-ready field with question marks. You can enter a suitable shadow InfoPackage here. This InfoPackage is entered in table RSSHIPDVERS. If you make no entry and are not in a content development system, the D version of the InfoPackage is deleted. If you make no entry and are in a content development system, a new suitable shadow InfoPackage is created from the A version with a new RSSHUIPDVERS entry.