Performing RFC connection checks in NetWeaver BW with SAP TREX

One of the more common challenges related to the SAP NetWeaver BW Accelerator that SAP administrators face is a broken RFC connection between the blades of the BW Accelerator and the NetWeaver BW system itself. To diagnose these problems -- and in many cases repair them -- administrators can look to the SAP TREX standalone administration tool.

In this section, learn how to create and maintain an RFC connection in NetWeaver BW for the BW Accelerator. Find out how to stop RFC connection problems before they arise by ensuring the TREX alert server performs consistency checks of the connection. Also learn how to make sure the BW Accelerator data is consistent with the InfoCube data in the SAP BI system by using the BW Accelerator Data Consistency Check Center.

SAP NetWeaver BI Accelerator, Ch. 5

Table of contents:
Understanding the SAP NetWeaver BW Accelerator
Performing RFC connection checks in NetWeaver BW with SAP TREX
Changing InfoCube metadata in SAP BW Accelerator

5.2 Exceptional Tasks

As an administrator, you should be able to handle not only the tasks that arise during routine operation of the SAP NetWeaver BI Accelerator, but also certain tasks you would need to perform only in exceptional circumstances. Here we review some of these tasks.

5.2.1 Repairing the RFC Connection

If the RFC connection between the BIA blades and the SAP NetWeaver BI system is broken for any reason, the situation can be diagnosed and in most cases repaired using the TREX administration tool. The tool offers full support for creating and editing RFC destinations, pinging hosts to locate network problems, reporting in detail on any issues that arise, and automatically repairing broken connections.

Alerts are color-coded to highlight any that require manual intervention. In general, red alerts indicate an error status that the tool cannot repair by itself, while yellow alerts indicate issues that the tool can resolve automatically. The red alerts indicate situations that require human action. The yellow alerts will be repaired in the next check run if the RFC check in the alert server is activated (where the check runs by default every 5 minutes).

You can create a new RFC destination in the SAP NetWeaver BI system for the accelerator by using Transaction SM59, as described in Section 4.2.2. The connection type is TCP/IP, and TREX runs as a registered server program. The program ID is unimportant because the accelerator overwrites it automatically with a correct ID.

To ensure that you receive sufficient warning of any RFC problems that may arise, you can check that the TREX alert server is configured to perform regular automatic RFC connection checks and to send you an e-mail if a problem is sufficiently serious.

This excerpt from SAP NetWeaver BI Accelerator by J. Andrew Ross is reprinted here with permission from SAP Press; Copyright 2008. Download a pdf of this chapter.

To handle matters related to the RFC communication between the accelerator and the BI system, choose the Connectivity view in the TREX standalone administration tool, as shown in Figure 5.5.

Figure 5.5: TREX Admin Tool, Connectivity View

The view opens to show the Rfc tab with its Current tab showing. The tool indicates any recommended next action by highlighting the relevant button with a different color. In the case shown, the administration tool has not yet connected itself to the BI system, as indicated by the gray (diamond) icon, and the recommended next action is to choose the Connect Admin Tool button.

If the TREX standalone administration tool attempts to connect itself to the BI system, but the required connection data is missing in the accelerator, the tool will show a message highlighted in yellow as shown in Figure 5.6.

Figure 5.6: TREX Admin Tool, Connection Data Missing

The recommended next action is to create a connection. This is indicated by the highlighting of the button you should choose next to create a connection. When you do so, the dialog box shown in Figure 5.7 appears.

This dialog box enables you to create a connection to the specified SAP system on the assumption that a correctly configured RFC destination exists in that system. Within TREX, the connection data you enter in the dialog box is stored in the saprfc.ini file, and the logon data you enter is encrypted and stored in topology.ini.

Figure 5.7: TREX Admin Tool, Create New SAP System Connection

When you set up an RFC destination, you need to specify whether your accelerator connects to your SAP NetWeaver BI system landscape via local gateways or a central gateway (see Figure 5.8). Each TREX instance has one RFC server process, which spawns as many threads as required.

Figure 5.8: Central and Local SAP Gateways

A central gateway between the local gateways on the application servers and the RFC servers in TREX appears to offer simpler traffic flow because each node at either end communicates with only a single node represented by the central gateway but has the disadvantage that this central node is a single point of failure and can be a bottleneck in a heavy load scenario. For this reason, we recommend the use of local gateways for communication with the accelerator.

In the local gateway configuration, each application server communicates directly through an RFC server with every TREX instance in the BIA landscape, and vice versa. As Figure 5.8 shows, this can give rise to a large number of RFC server threads on each BIA host, but no extra administration is required. The administrator simply leaves the gateway option fields blank when setting up the RFC destination. TREX then starts as many RFC server threads as needed.

If a suitable RFC destination does not yet exist in the target SAP system, you can create one, either in Transaction SM59 or in the TREX standalone administration tool.

If TREX does not find a suitable RFC destination in the target SAP system, the tool prompts you (with highlighted buttons) either to enter into TREX the information about an existing RFC destination that is defined in a connected SAP system (see Figure 5.9) and store the information in the TREX topology.ini file or to create a new RFC destination in a connected SAP system (see Figure 5.10). If you create a new destination, you do not need to enter a program ID because TREX generates one automatically for use at both ends of the connection. Again, the information is stored locally in the TREX topology.ini file. As soon as the destination has been created, a "created successfully" information box appears.

Creating a new RFC destination from TREX as shown in Figure 5.10 is equivalent to doing so in the SAP system using Transaction SM59. Both ways of setting up an RFC destination require the same information.

Connecting the TREX administration tool to the SAP system is just the first step. Once the tool has successfully connected, it determines whether all the BIA blade server hosts can communicate correctly with the SAP system. If not, for example, because an application server has been removed from the landscape or added to it, the tool may display information similar to that shown in Figure 5.11, with error details highlighted in red, other unresolved issues in yellow, and a yellow (warning triangle) status icon for the affected system. The problems highlighted in yellow can be solved by the automatic repair capabilities built into the administration tool. In this case, the tool prompts you with highlighting to choose the Repair All button. Because the RFC check runs automatically in the background, you can simply wait to let the repair run, and check that it has done by clicking Refresh as often as necessary, but clicking the highlighted Repair All button can speed up the repair if you are in a hurry.

Figure 5.9: TREX Admin Tool, Add RFC Destination

Figure 5.10: TREX Admin Tool, Create New RFC Destination

Fortunately, the problems shown here were not too serious, and TREX solved them all in seconds, as shown in Figure 5.12. Now the tool shows a green (square) configuration status icon and highlights the connection details in green to indicate that all is well. Generally, the tool offers clear visual feedback in this way to ensure that the administrator knows as exactly as possible what to do next.

Figure 5.11: TREX Admin Tool, Repair Connectivity

Figure 5.12: TREX Admin Tool, Connectivity Repaired

The TREX administration tool includes a great deal more functionality for the automatic repair of connectivity issues, but the user experience is always similar to that illustrated here, and an experienced administrator should have no difficulty with it.

5.2.2 Consistency Checks

To ensure that the data in your BIA indexes are consistent with the InfoCube data in the BI system, you can run a variety of consistency checks. The main launch point for such checks is the BI Accelerator Data Consistency Check Center.

From the BIA monitor, choose Goto _ Consistency Checks. This opens the BI Accelerator Data Consistency Check Center. From this center, you can execute consistency checks, schedule these checks, and view the logs of checks that have run (see Figure 5.13).

Figure 5.13: BI Accelerator Data Consistency Check Center

The BI Accelerator Data Consistency Check Center offers the following tabs from which you can execute the checks:

• Data Comparison
  Enables you to compare the contents of each individual table in an InfoCube with the contents of the corresponding index, record by record. This check is only suitable for relatively small tables and indexes.
• Totals in BIA
  Enables you to check key figure sums internally by executing a query on the BIA index using all key figures. Then the BI system executes a query for each characteristic and navigation attribute occurring in the InfoCube that aggregates over all key figures. All the characteristics and navigation attributes that exist in the InfoCube are then included individually in the drilldown, and the totals are calculated. The system compares the result with the result of the first query. This test checks the completeness of the join paths to the fact tables. If the test shows that the data is incorrect, you need to rebuild the BIA index and its master data indexes.
• Totals in BIA and DB
  Enables you to compare key figure sums on the database against and in the BIA index. The system executes a query for each characteristic and navigation attribute occurring in the InfoCube that aggregates over all key figures on the BIA index and the database. Then it sums individually over all the characteristics and navigation attributes occurring in the InfoCube and compares the results from the database and the accelerator. The runtime of the test can be long. If it shows that the data is incorrect, you need to rebuild the BIA index and its master data indexes.
• Random Queries
  Enables you to checks for consistency by executing random queries, reading the data once from the database and once from the accelerator. The results should be the same. However, they can differ if the InfoCube data has been changed between execution of the query on the database and in the accelerator. You can verify the results as described later in this section. To repair the index, you need to rebuild it.
• Index Existence
  Enables you to checks whether indexes have been created for all the (relevant) tables in the star schema for the InfoCube. The test is very fast. If an index is missing, the BIA index needs to be rebuilt.

As an alternative to working from the BI Accelerator Data Consistency Check Center, you can run some fast index checks from the BIA monitor. Or you can run the more thorough checks in Transaction RSRV, to check that the indexes are complete and consistent.

To execute one or more sets of automatic BIA index checks in the BIA monitor, choose Index Checks _ BI Accelerator.

This offers the following further options:

• Index Checks Schedule/Deschedule
  Toggles the index checks schedule on or off.
• Execute/Display/Change checks
  Displays a dialog box inviting you to flag the check set or sets you want to run, and then execute (see Figure 5.14). Once the checks have run, the results are displayed. In the run shown in Figure 5.15, 11 checks ran smoothly, and no red or yellow alerts were generated.

Figure 5.14: BIA Monitor, Execute Index Checks

Figure 5.15: BIA Monitor, Execute Index Checks

The default set of index checks currently includes three checks. Check 1 looks at the size of delta indexes for BIA indexes, check 2 compares the size of InfoCube fact tables with their fact indexes, and check 3 looks at the relation between tables and indexes. The checks run quickly and provide useful information about performance and consistency. They can also be found and run in the analysis and repair environment (Transaction RSRV, see Section 5.2.6).

To execute selected elementary or combined checks in Transaction RSRV, drill down in the check set tree displayed on the left side of the screen to find the accelerator checks that you wish to run and double-click on them. This causes their names to appear on the right side of the screen (see Figure 5.16). Alternatively, you can drag them to the right and drop them there. Then, for each check on the right, you need to set the relevant parameters (this generally means specifying the InfoCube or InfoCubes to be checked). To do this, click on the lines at right to open a dialog box (see Figure 5.17) where you can enter the required values. When you are ready, choose Execute and wait for the results (see Figure 5.18). These are displayed as a detailed list with a colored icon for each line to show at a glance whether all went well.

Figure 5.16: Transaction RSRV, Select Checks to Run

Figure 5.17: Transaction RSRV, Dialog Box for Parameter Entry

Figure 5.18: Transaction RSRV, Check Results

When to Run Checks: A Matrix

With so many checks, so many indexes to check, and so many possible reasons to run a check, it may seem impossible to follow a regular plan here. However, a little preparation can help. Draw a matrix with checks and reasons to run checks as its columns and rows, and then fill it out for yourself in view of your index landscape and your own priorities.

Table 5.1 shows a possible matrix. Here the 6 consistency checks listed below the matrix are numbered in the column heads and mapped to the 13 reasons to run checks listed in the rows. Check 1 is a query load generated by the RSTT trace tool described in Section 5.4.3, and checks 2–6 are listed with brief descriptions in Section 5.2.2.

As an example of how to read this matrix, the dots in it specify that after a roll-up or a change run, you plan to run the checks 2–6, and after hardware changes or performance shortfalls, you plan to run checks 1, 4, and 5.

The pattern of dots in this matrix is just an example, and as an administrator, you should plot your own matrix. Ideally, you should also insert more detail, for example, by adding a line specifying how often in the routine case you plan to run the check and a line indicating approximately how much time on average the check takes to run.

This check compares the contents of each individual table with the contents of the corresponding index, record by record. It is only suitable for tables or indexes that do not contain a large amount of data, such as dimension tables, certain S tables, and X and Y tables. Fact tables are normally too large for this check. If a table contains 10,000 records or more, it is not checked.

This check first executes a query on the BIA index, which is aggregated using all key figures, then includes all the characteristics and navigation attributes that exist in the InfoCube individually in drilldowns, and calculates the totals. The results are now compared to check the completeness of the join paths to the fact tables.

This check executes highly aggregated queries and compares the results from the database with those from the BIA index. For large InfoCubes, the runtime may be long.

This test checks whether all the (relevant) indexes for a given InfoCube have been created on the BIA server. Its runtime is very fast. If the test reveals that an index is missing, the BIA index needs to be rebuilt.

This check executes random queries without persisting them. The system reads the data once from the database and once from the accelerator, and then compares the results. If the results differ, an error message is output.

You can leave all other values unchanged. If the results are the same as from the check, you need to rebuild the BIA index.

When queries are executed in hierarchies, the hierarchy nodes are expanded to the relevant leaves and the expansion saved in a temporary index in the accelerator. The hierarchy buffer manages expanded hierarchies according to an LRU (least recently used) algorithm.

This check compares the definitions of each of the table indexes in a BIA index with the current versions of the database tables. It checks whether the number, name, and type of the table fields in the database match the definition for the index on the BIA server. If you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BIA index.

The system checks the logical index of a BIA index. The logical index contains the metadata for the BIA index, such as the join conditions and the names of the fields, and may change if the InfoCube is changed. If you do not specify an InfoCube, the system executes the test for all InfoCubes that have a BIA index.

The system checks whether BIA indexes contain indexes that have the status unknown. This only occurs in exceptional cases when the Commit Optimize call terminates during indexing. Because in this case it is not clear whether the previously indexed data is available, the affected indexes are rebuilt in repair mode.

Displaying and Changing a Check Set
To display an existing check set, select it from the input help for the Check Set ID field (see Figure 5.20). You can change the parameter values of the selected check set and save it again. The Check Set ID stays the same.

You can download a pdf of this chapter. You can also visit SAP Press to purchase a copy of SAP NetWeaver BI Accelerator.

Recommended best practice is to regularly check the data in your accelerator and compare it with the data in the database. You can do so from the BIA monitor by choosing Goto _ Consistency Checks, which opens the BI Accelerator Data Consistency Check Center (see Figure 5.13 shown earlier).

To minimize the system load and runtime for the consistency checks, use the following hints in a three-step approach:

1. Check the facts
The fact indexes usually contain the most data and therefore take longest to check. To reduce the runtime of the check Totals in BIA and DB, set the Drilldown with InfoObject Only option to a characteristic with few attributes such as CALYEAR (see Figure 5.19).

Figure 5.19: Data Consistency Check Center, Totals Tab in BIA and DB

If the InfoCube contains many key figures, you can reduce the load on the accelerator by reducing the number of key figures. If the runtime of this check is still too long, try reducing the percentage of data to be checked. A key figure overflow occurs during the check if the key figure type cannot contain the sum of all values.

2. Check the completeness of the star schema indexes
These indexes can be very large, and we do not recommend a regular completeness check because it is too expensive.

Instead, use the Totals in BIA check to find incorrect or missing records in the fact tables. Execute all joins of the extended star schema, and compare the results as a complete aggregation on the fact table. This acts like a filter because if there are incorrect or missing records in one of the indexes, the result of the aggregation on the fact table is different from the reference result.

Again, if the InfoCube contains many key figures, you can reduce the load by reducing the number of key figures, and if a key figure overflow occurs, you can reduce the percentage of data checked.

3. Check data consistency in complex situations

You can check the BIA data using random queries with complex conditions. The performance of this check depends on the performance of the query in the database. If your database still has aggregates for the InfoCube you want to check, then some of the randomly generated queries can be processed efficiently in the database, and in this case the performance of the check will be better.

For the details behind these hints, see SAP Note 1095886.

Master Data and Transaction Data
We now look one by one at the consistency checks available in the analysis and repair Transaction RSRV.

In some situations, the content of the indexes of the BIA index may differ from the content of the corresponding database table. This may be the case if requests have been deleted from the InfoCube or if an InfoCube has been compressed.

The runtime of the check depends on the number of characteristics and attributes and on the size of the fact table. If the test shows that the data is incorrect, you need to rebuild the BIA index and the master data indexes.

The results can be different if the data of the InfoCube is changed between execution of the query on the database and in the accelerator.

To verify the results, execute program RSDRT_INFOPROV_RANDOM_QUERIES with the following parameters:

• InfoProvider: Name of the InfoCube
• Number of queries: 10
• Starting value: Same as used by the random generator
• Trace comparison: X

This check verifies whether all temporary indexes in the hierarchy buffer contain correct data. If the hierarchy buffer contains incorrect entries, do not delete the hierarchy buffer but send a customer message to SAP Service. If you urgently need to continue work, you can delete the entire hierarchy buffer, but this will make it harder to troubleshoot the error.

Metadata

If a table definition has been changed, the system deletes the old index, creates a new index with the current definition, and fills it. All BIA indexes that use this index are set to inactive and become unavailable for reporting during this time. The period of unavailability depends on the size of the table that needs to be reindexed.

If the logical index has been changed, the system deletes the old index and creates a new index with the correct definition. The system temporarily sets the BIA index to inactive, and the index is unavailable for reporting during this time.

5.2.3 Check Sets for BIA Indexes

From the BI Accelerator Data Consistency Check Center, you can create and schedule check sets. To access the center from the BIA monitor, choose Goto_Consistency Checks. This displays the Data Consistency Check Center (see Figure 5.13 shown earlier). On this screen, you can schedule and run checks of the index data on the BIA server, view the logs of checks that have run, and group certain checks to form check sets.

Procedure for Creating a New Check Set

To create a new check set, follow these steps:

1. Give the check set a description.
2. Specify the InfoCubes corresponding to the accelerator indexes for which the check set is to be executed. Input help is available.
3. Specify the maximum degree N of parallelization for background processing, if the checks are to run in background. The system starts up to N simultaneous dialog processes, with one for each InfoCube.
4. If necessary, set the indicator to deactivate an accelerator index for queries if errors occur. If this indicator is set, the accelerator index is inactivated (so that it cannot be used for queries) as soon as the check set reports incorrect data in the accelerator index. This prevents the accelerator from using incorrect data for reporting. In some circumstances, a check can report incorrect data even though the data is correct. Then deactivation is unnecessary, but it is still better than using incorrect data for queries.
5. If you want an e-mail to be sent if an error occurs (if incorrect data is reported), enter the address of the recipient in the relevant field.
6. If the check set is to be executed immediately after the roll-up of new requests to an InfoCube, set the relevant indicator. The check set is then still part of the process (this is relevant for integration into a process chain), but the lock on the process is no longer valid so that other processes are not interrupted. The check set is not executed for all InfoCubes, but only for the InfoCube for which the data was rolled up.
7. If the check set is to be executed immediately after the change run, set the relevant indicator. As before, the check set is still part of the process, but the lock on the process is no longer valid. The check set is only executed for the InfoCubes whose accelerator index was adjusted in the change run.
8. Each tab in the screen controls a test, as described in Section 5.2.2. Select the checks you want for your check set, and select the relevant options.
9. Save the check set. A check set ID is allocated and displayed.

Figure 5.20: Display a Check Set

To delete a check set, select it, choose Delete, and confirm at the prompt.

Executing a Check Set
To execute a check set, just select it, and choose Execute. The checks are executed in the dialog (and not in parallel). If you have just created the check set, you do not even have to save it. When the check is complete, the system displays the results in the application log.

To schedule a check set, choose Schedule. This opens the Start Time dialog box. Here you can schedule the check set to run once or periodically in the background. You need to save your entries to set the schedule. The name of the scheduled job is BW_TR_RSDDTREX_INDEX_CHECK.

You can also execute a check set by using program RSDDTREX_INDEX_CHECK.

To do this, you need the check set ID, or you can select the check set from the input help. You can also use this program to add a check set to process chains. To call the logs, choose Logs.

5.2.4 Index Repair Programs The following are the index repair programs:

• Delete and rebuild all BIA indexes
  This repair first deletes and then recreates and fills all the BIA indexes in the accelerator. This is an extremely drastic action that can put your accelerator under full load for many hours and will make it unavailable for user requests during that time. In exceptional circumstances, if a critical error occurs, you may need to execute this action for a successful restart with consistent data, but before you run it you should consider the consequences carefully.
• BIA index adjustments after InfoCube activation
  If an InfoCube is changed, for example, by adding a key figure, the accelerator does not automatically adjust the BIA index because the adjustment may take a long time (see Section 5.2.5). This repair writes information about any changes to the log and makes the required changes in repair mode. If you execute this repair, we recommend that you run it as a background job.
• Rebuild all master data indexes of a BIA index
  We strongly recommend that you do not execute this repair. It deletes and rebuilds all master data indexes of a BIA index. These master data indexes are used by other BIA indexes, so the repair may result in terminations or poor performance during query execution. This repair also requires various data loading processes to be locked. The repair is only for use in cases where there is incorrect data in the master data indexes of a BIA index. Such problems are serious. If you find such a problem, you should open a customer message. SAP service will analyze the problem, determine which index contains incorrect data, and rebuild the index using a program that is not released for general use. As of Support Package 18, this repair is no longer available in Transaction RSRV.

You'll find more downloadable excerpts from books by SAP experts in our SAP chapter download library.