If you come from an SAP BW or BW/4HANA background, you are probably used to monitoring operational delta extraction through frameworks like ODP and transactions such as ODQMON.

So naturally, when building a Replication Flow in SAP Datasphere using a CDC-enabled ABAP CDS view, the first instinct is usually:

“Let me check ODQMON and verify whether the delta queue is working.”

But after opening ODQMON, you find something unexpected.

No queues.
No subscriptions.
No delta records.

At first glance, it feels wrong. However, this behaviour is completely expected.

CDC-based replication flows in SAP Datasphere do not rely on the traditional ODP queue infrastructure. Instead, SAP introduced a separate runtime architecture based on:

• database triggers,
• logging tables,
• background observer jobs,
• and a transient staging framework called the Resilient Data Buffer (RDB).

Understanding this internal flow is extremely useful when:

• troubleshooting replication delays,
• analysing delta behaviour,
• monitoring runtime jobs,
• or debugging missing changes.

In this article, we will walk through the internal architecture step-by-step and trace how a delta change moves from an S/4HANA application table into a Datasphere local table.

How CDC-Based Extraction Differs from Classical ODP Extraction

Traditional SAP extraction frameworks such as ODP extractors primarily depend on operational extraction queues managed through ODQMON.

CDC-enabled CDS extraction works differently. Instead of persisting delta packages in operational queues, the ABAP CDC framework captures changes directly at the database table level using generated logging tables and database triggers.

Those changes are then processed through a resilient staging mechanism before being consumed by SAP Datasphere replication services.

This architectural shift is the primary reason why ODQMON remains empty, yet delta replication still works perfectly.

High-Level Runtime Architecture

At a high level, the runtime flow works like this:

1. Database changes occur on the source application table.
2. Database triggers capture the modified keys.
3. Logging tables register the changes.
4. Background jobs reconstruct the full CDS payload.
5. Delta records are staged into the Resilient Data Buffer (RDB) table.
6. SAP Datasphere replication services consume the staged records.
7. Successfully processed rows are automatically purged from the buffer.

The following architecture illustrates the complete flow between S/4HANA and SAP Datasphere.

 

The Key Components Behind the Scenes

Before diving into the runtime sequence, it is important to understand the main technical components involved.

1. CDC Logging Tables

When a CDC-enabled CDS view becomes active for replication, SAP dynamically generates logging tables in the backend system.

Typically, two logging structures are created:

• Master Logging Table (/1DH/ML*)
• Subscriber Logging Table (/1DH/SL*)

These tables do not store the complete business payload.

Instead, they mainly capture: changed keys, operation types, timestamps, and subscription-specific metadata. This lightweight logging approach prevents transactional overhead on OLTP operations.

1. Resilient Data Buffer (RDB)

The Resilient Data Buffer acts as a temporary staging area between S/4HANA and SAP Datasphere.

Think of it as a protected handoff zone. The RDB ensures that delta records are: safely staged, acknowledged by the consumer, and only deleted after successful delivery.

This protects the replication pipeline from:

• network interruptions,
• temporary cloud outages,
• and partial transfer failures.

1. Observer and Transfer Jobs

Two continuously running background jobs orchestrate the runtime flow:

/1DH/OBSERVE_LOGTAB – monitors logging tables for newly captured changes.

/1DH/PUSH_CDS_DELTA – Reconstructs the full CDS payload and stages records into the RDB.

These jobs can be monitored through transaction SM37.

Transactions You Actually Need to Monitor

For CDC-based replication flows, ODQMON is no longer the primary monitoring tool.

Instead, these transactions become critical:

Transaction	Purpose
DHCDCMON	Monitor CDC subscriptions, triggers, and generated logging tables
DHRDBMON	Monitor resilient buffer tables and staged delta records
SM37	Monitor Observer and Transfer background jobs

This is the operational monitoring layer for modern CDC-based extraction.

Prerequisites for the Scenario

For this walkthrough, the following setup is used:

• S/4HANA On-Premise source system
• SAP Datasphere target tenant
• SAP Cloud Connector configured
• Replication Flow configured with “Initial and Delta”

SAP Note 2890171 should also be reviewed for ABAP integration prerequisites and CDC enablement requirements.

For the demo scenario:

• custom table: ZAK_TABLE1
• CDS view: ZAKE_PO_ITEM_01

Table structure and initial data for reference:

The CDS view is enabled for CDC extraction using extraction annotations.

Phase 1 — Before the Initial Load

After activating the CDS view in the source system, create a Replication flow in Datasphere tenant.

Login to Datasphere Tenant -> Go to Data builder -> Select Space -> Click on Create Replication Flow -> Select the source system in which CDS view created -> Select CDS Extraction folder -> Select ZAKE_PO_ITEM_01 as source object, Select target as Datasphere and set the Load Type to “Initial and Delta”.

Deploy Replication flow. (Do not run this yet).

 

Datasphere Local table created without any data.

 

At this stage:

• DHCDCMON shows no active subscription entries.

 

 

• DHRDBMON does not yet show generated RDB tables.

 

• Observer and Transfer jobs are running in SM37 but remain idle.

This is expected behaviour because no active replication execution has started yet.

 

Phase 2 — Initial Load Execution

Once the replication flow is executed for the first time, the runtime framework initializes several backend components automatically.

Records loaded to Local table

What Immediately Changes

Refreshing DHCDCMON now shows active CDC registration, generated logging tables, trigger assignments. SAP dynamically creates:

• Master Logging Tables (/1DH/ML*)
• Subscriber Logging Tables (/1DH/SL*)

 

At the same time, the backend also generates the Resilient Data Buffer table (/1DH/RDB*) (DHRDBMON)

Important Observation: Initial Load Bypasses the Logging tables

One of the most interesting runtime behaviours appears during the initial load phase.

Although the CDC framework already creates:

• Master Logging Tables (/1DH/ML*)
• Subscriber Logging Tables (/1DH/SL*)
• database triggers,
• and CDC subscriptions,

these logging tables typically remain empty during the initialization process.

This surprises many engineers because the replication flow is already active, yet no entries appear in the CDC logging tables.

The reason is that the initial load follows a different runtime path optimized for bulk data transfer.

Instead of processing records through the CDC logging framework, the runtime performs:

• a direct read from the source application tables,
• stages the extracted payload into the Resilient Data Buffer (RDB),
• and transfers the data into the SAP Datasphere local table.

The runtime flow during initialization can therefore be simplified as:

Source Table → RDB Buffer → Datasphere Local Table

 

How Delta Changes Move Through the Pipeline

Once the initial load completes, the replication flow enters steady-state delta mode.

Now let us insert a new record into ZAK_TABLE1 using transaction SM30. The following runtime sequence occurs internally.

Step 1 — Database Trigger Activation

The insert operation activates generated database triggers.

These triggers write lightweight entries into:

• Master Logging Tables
• Subscriber Logging Tables

At this stage, only key-level metadata is captured. The full CDS payload is not reconstructed yet.

This is important because it minimizes transactional overhead on the application system.

 

Step 2 — Observer Job Detection

The Observer job continuously scans the subscriber logging tables.

Once new entries appear, the Observer job activates the Transfer job pipeline.

Step 3 — Full Payload Reconstruction

The Transfer job now:

• reads changed keys,
• re-evaluates the CDS view logic,
• reconstructs the complete output payload,
• and stages records into the RDB table.

Opening DHRDBMON during this stage shows staged delta rows, operation flags, package information, sequence ordering.

At this point, the RDB temporarily acts as the handoff layer between S/4HANA and Datasphere.

Step 4 — Datasphere Consumes the Delta

During the next replication interval, Datasphere replication services consume staged records from the RDB framework. The records are written into the Datasphere local table. Once the target acknowledges successful processing, the staged RDB rows are automatically deleted.

This cleanup process keeps the buffer lightweight and transient.

As a result:

• RDB tables dynamically grow during bursts,
• and shrink back down after successful processing.

Practical Troubleshooting Guidance

The following observations are extremely useful during issue analysis.

Observation	Likely Meaning
ODQMON is empty	Expected for CDC replication
DHCDCMON has no entries	Subscription not initialized
Subscriber logs continuously growing	Transfer job issue
RDB table continuously growing	Datasphere consumption delay
Observer job inactive in SM37	CDC pipeline stalled
Initial load succeeds but delta missing	Trigger or subscription issue

Final Thoughts

CDC-based replication in SAP Datasphere does not depend on classical ODP queue processing.

Instead, SAP uses:

• database triggers,
• CDC logging tables,
• observer jobs,
• resilient staging buffers,
• and Replication Flow Runtime services

to build a cloud-ready near real-time replication framework. Once these runtime mechanics are understood, monitoring and troubleshooting become significantly easier.