RSRT — BEx Query Monitor for Testing and Debugging

RSRT executes a BW query directly against the OLAP engine without going through any presentation layer. It exposes technical execution details that no frontend shows: the generated SQL statement, whether the OLAP cache was hit, which aggregate (if any) served the request, variable screen behavior, and formula/exception evaluation. The structural fact behind most confusion is that RSRT has its own execution context, controlled through the 'Execute + Debug' option, which can override or ignore frontend personalization, workbook settings, and portal variants. A query that looks broken in Analysis for Office can run perfectly in RSRT, and that gap is diagnostic information in itself, not a contradiction to be explained away.

RSRT sits between data load monitoring and the reporting frontend in the troubleshooting chain. It is reached for when a query returns wrong numbers, times out, or behaves inconsistently between users, and the question is whether the fault lies in the query definition, the InfoProvider data, or the tool displaying it. It is not used to build or design a query, and it is not a substitute for a Fiori analytical app or Analysis for Office when the issue is purely a frontend formatting or navigation problem. Consultants typically move to RSRT after ruling out that the underlying InfoProvider has the expected data, and before escalating to the query designer to change variable defaults or filters.

Turn on BW statistics for the query before testing (this is a query property, not an RSRT setting), run the query once in RSRT with cache enabled and once with 'do not use cache' checked, then browse the relevant BW statistics table in SE16 filtered by the query's technical name and execution timestamp. Compare the runtime and records-transferred fields between the two runs; a large gap points to a cache or aggregate effect rather than a data problem. If an aggregate was used, the debug output in RSRT itself names the aggregate ID directly, which is faster than searching the statistics table for it.

RSRT continues to work the same way on S/4HANA and BW/4HANA for classic BW queries built on InfoProviders or CompositeProviders. It does not apply to native CDS-based analytical queries or embedded analytics content consumed directly through Fiori apps, since those bypass the BW OLAP engine entirely; those are tested through CDS-level tools instead. Where a BW query still sits underneath a Fiori analytical app as its data source, RSRT remains the right tool to isolate query-side problems before touching the app layer.

This is functional BW/BI consultant territory in the first instance; RSRT is a diagnostic tool for someone who understands query design, aggregates, and OLAP caching. A good handover to Basis (for cache infrastructure or memory issues) or to an ABAP developer (for exit variables or custom formula logic) should include the query technical name, the exact debug options used, the generated SQL, and whether the problem reproduces with the cache disabled.

RSA1 is the natural starting point to confirm the InfoProvider and query are active and to check where the query sits in the data flow before testing it in RSRT. RSMO and RSPC are useful upstream when the suspicion is that the underlying data load, not the query, is at fault. RSA3 helps rule out an extraction problem at the source when RSRT shows correct query logic but implausible numbers. Moving from RSRT to the query designer is the natural next step once a variable, filter, or exception aggregation issue has been confirmed rather than a data or cache issue.