Clean Core Architecture Guide #48

SAP Clean Core CDS Change Data Capture (CDC) & Real-Time Replication Guide

⏱️ 15 min read 🏢 Enterprise Architectural Blueprint 🔄 Updated for S/4HANA 2023 & Datasphere

Core Architectural Mandate: In SAP S/4HANA Clean Core, external analytics systems (Snowflake, Databricks, SAP Datasphere, Google BigQuery) must never extract data via direct database queries, obsolete RFC function modules (RFC_READ_TABLE), or trigger-based SLT on standard tables. Instead, Clean Core enforces high-performance Change Data Capture (CDC) using released Core Data Services (CDS) view entities annotated with @Analytics.dataExtraction.

1. The Problem: Legacy Data Extraction vs. Clean Core CDC

In legacy SAP ECC and initial S/4HANA deployments, data engineering teams frequently connected third-party ETL pipelines directly to the SAP underlying database or leveraged trigger-based replication (SAP SLT). This practice violated core decoupling:

Extraction Approach	Upgrade Stability	Locking & Concurrency Impact	Clean Core Status
Direct DB / JDBC Access	Zero stability (bypasses application logic, breaks on table schema updates)	Heavy table scans, read lock contention	❌ Strictly Forbidden
RFC_READ_TABLE / Custom RFCs	Low stability (unmanaged memory usage, fails on 512-byte row limit)	High application server CPU spikes	❌ Deprecated
Trigger-Based SLT on Standard Tables	Medium stability (DB triggers fail during system upgrades/S/4 conversion)	Trigger execution adds write overhead to transactional tables	⚠️ Phase-Out Mandate
CDS CDC (@Analytics.dataExtraction)	100% Upgrade-Stable (Public stable interface C1 contract)	Zero Lock Contention (ODP buffer page streaming)	✅ Official Clean Core Standard

2. Anatomy of a Clean Core CDS CDC View Entity

To enable delta extraction, developers define a CDS View Entity in ABAP Cloud with the @Analytics.dataExtraction annotation suite. There are two primary delta extraction paradigms:

A. Delta by Element (Timestamp / High-Watermark)

The most common and efficient mechanism. The CDS view designates an indexed UTC timestamp or change counter field. During each extraction run, the SAP Operational Data Provisioning (ODP) framework only reads rows where the timestamp is strictly greater than the last recorded high-watermark:

@EndUserText.label: 'Sales Order CDC Delta Extract'
@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #FACT
@Analytics.dataExtraction: {
  enabled: true,
  delta.byElement: {
    name: 'LastChangeDateTime',
    maxDelayInSeconds: 15,
    detectDeletedRecords: false
  }
}
define view entity ZC_SalesOrderDelta
  as select from I_SalesOrder
{
  key SalesOrder,
      SalesOrderType,
      SoldToParty,
      TotalNetAmount,
      TransactionCurrency,
      
      // Mandatory UTC high-watermark field
      LastChangeDateTime
}

B. Change Data Capture (CDC) with Record Mode

For entities requiring exact delete tracking and before/after image reconciliation, SAP S/4HANA supports full CDC table logging mapped through CDS annotations. This generates a standard RecordMode field:

N: New / Inserted record
U: Updated record (after-image)
X: Updated record (before-image)
D: Deleted record (tombstone)

Master Clean Core Enterprise Integration & BTP Architecture

Discover complete production blueprints for CDS view optimization, ODP delta queue governance, SAP Datasphere federation, and Event-Driven Architectures in The SAP Enterprise Architecture Suite.

Get the Architecture Suite (FLASH80 - 80% Off) →

3. ODP Delta Queue Governance (ODQMON)

When an external client (such as SAP Datasphere or an OData consumer) requests an extraction, SAP buffers the delta packages in the Operational Delta Queue (ODQ).

Transaction ODQMON: Used by Basis and SAP Integration teams to monitor subscriber queues, compression rates (typically 75% to 85%), and data volumes.
Zero-Loss Repeat Extraction: If an external network interruption disconnects Snowflake or Datasphere mid-transfer, the ODQ provides a repeatable delta window, re-transmitting the exact chunk without touching the base database tables.
Automated Housekeeping: Clean Core governance dictates configuring background job ODQ_CLEANUP to prune expired delta spools after 7 days.

4. Consuming Delta Links via OData V4

In side-by-side architectures (e.g., Python microservices, Databricks pipelines, or AWS Glue), the CDS delta view entity is exposed via an OData V4 Web API.

The client triggers an initial read with the query parameter $deltatoken. The SAP OData V4 gateway returns the current data snapshot alongside an @odata.deltaLink header containing the encrypted cryptographic token. On subsequent calls, the client queries the delta link, receiving only mutations that occurred since the token was issued.

Architecture Summary Checklist

✅ No Direct DB Access: All extractors built on released CDS View Entities.
✅ Indexed High-Watermark: Ensure LastChangeDateTime is backed by a database index.
✅ MaxDelayInSeconds: Configured (typically 15-30s) to allow open LUWs to commit before delta cutoff.
✅ ODQMON Monitoring: Automated alert thresholds on queue size and spool retention.

← Back to Interactive CDC Architect Tool