Designing and Configuring Near-Real-Time Data Flows: RDA, Direct Access and Open ODS Views

Explanation

Implementing operational reporting requires deliberate configuration choices at the DataSource, DTP, and InfoProvider levels, plus operational monitoring practices that differ from classic batch chains. For Real-Time Data Acquisition (RDA), the DataSource must support delta extraction, and a Data Transfer Process is configured with the real-time acquisition option rather than a standard full or delta load. A daemon is assigned to one or more real-time DTPs; the daemon is a background process that wakes up at a configured interval (for example every 5 or 15 minutes) and triggers extraction into the PSA and onward into the target DataStore Object. Unlike a process chain that runs once and finishes, the daemon keeps running continuously during its scheduled active window, so operations teams must monitor it distinctly from standard chains, watching for daemon status, missed intervals, and extraction errors that could silently accumulate backlog. A key design decision is which target layer receives RDA data. It is common to land RDA deltas into a dedicated 'operational' DataStore Object (often write-optimized or standard, depending on requirements) that is queried directly or exposed through a CompositeProvider that also references historized data, so users see both current-minute detail and longer-term context in one query. Because RDA still persists data physically, query performance on the operational layer behaves like normal BW reporting, but the aggregation and update logic in the transformation must be lightweight enough to keep pace with the acquisition frequency; complex routines or heavy lookups in the transformation can cause the daemon interval to fall behind, effectively degrading the promised latency. Direct Access takes a different path: instead of persisting data, a VirtualProvider (BW) or an Open ODS View / CompositeProvider configured for direct access (BW/4HANA) issues a request to the source system at query runtime. This requires the source DataSource or extractor to support direct access, and it is essential to apply tight selections (for example a specific sales order or a bounded date range) because the query effectively becomes a live remote call. Uncontrolled direct access queries with broad selections can generate significant load on the operational source system and produce poor response times, since there is no BW-side aggregation or indexing to help. For this reason, direct access is generally reserved for detail-level, highly selective lookups rather than broad analytical aggregation. Troubleshooting in this space differs from classic chains. For RDA, checking the daemon's runtime status and reviewing PSA request logs for the specific real-time DTP is the first step when data appears stale; a stalled daemon or a source system connectivity issue are common root causes. For Direct Access, poor performance is usually diagnosed by checking whether the query selections are properly restrictive and whether the source system extractor itself is efficient, since BW has no control over source-side processing time. In S/4HANA landscapes, teams must also decide whether a requirement is better solved via embedded analytics (CDS views reading live tables) instead of BW Direct Access, since CDS-based reporting avoids remote RFC-style calls and can leverage HANA's calculation engine directly; BW Direct Access remains relevant primarily when the data must be blended with other BW-modeled content.

Code example

* Illustrative pseudo-configuration notes for a real-time DTP (not executable ABAP)* 1. DataSource: ZDS_SALES_ORDER_ITEM (delta-enabled)* 2. Create DTP: source = DataSource, target = DSO ZDSO_SO_OPER*    - Extraction Mode: Real-Time (Delta)*    - Assign to Daemon: ZDAEMON_SALES_RT* 3. Daemon settings (via daemon maintenance):*    - Run interval: 15 minutes*    - Active window: 06:00 - 20:00* 4. Transformation ZDSO_SO_OPER:*    - Keep rule logic minimal (direct mapping, simple lookups only)*    - Avoid expensive ABAP routines that could delay daemon cycles* 5. Reporting layer:*    - CompositeProvider combines ZDSO_SO_OPER (current) with*      historized InfoCube ZCUBE_SO_HIST (older periods) for one query view

Real project scenario

A manufacturing client needed shop-floor supervisors to see production confirmations within 10-15 minutes of posting, without waiting for the nightly load. The BW team built a write-optimized DSO fed by a real-time DTP under a daemon running every 10 minutes during shift hours, then combined it with the historized production DSO in a CompositeProvider so supervisors could see both today's live confirmations and prior-week comparisons in a single query.

Common mistakes

• Putting heavy transformation logic (complex routines, multiple lookups) on a real-time DTP, causing the daemon to lag behind its scheduled interval • Leaving the RDA daemon active outside business hours, wasting system resources and complicating monitoring • Allowing Direct Access queries with unrestricted selections, resulting in slow response times and heavy source system load • Failing to separate monitoring procedures for daemons from standard process chain monitoring, causing stale-data incidents to go unnoticed • Choosing BW Direct Access for a pure S/4HANA operational reporting need when embedded analytics (CDS views) would be simpler and faster

Best practices

• Keep RDA transformation logic simple to avoid delaying the daemon cycle • Define and enforce an active window for daemons matching actual business hours • Enforce mandatory selective filters on any direct access query or InfoProvider • Monitor RDA daemons and PSA requests separately from standard process chains • Evaluate embedded analytics/CDS views as an alternative before defaulting to BW Direct Access in S/4HANA scenarios

Interview angle

Expect questions distinguishing RDA from Direct Access in terms of where data is persisted, what triggers extraction, and how each impacts source system load. Strong answers mention daemon monitoring, selective queries for direct access, and awareness of when embedded analytics on S/4HANA is a better fit than BW-side real-time techniques.