In analytics, speed is everything—yet pulling real-time data from a live SAP S/4HANA system remains a bottleneck for many organizations. When your reports rely on remote queries, they are instantly vulnerable to network latency and cross-system traffic. CDS view replication changes the game by moving the data to where the processing happens: caching it directly into SAP HANA Cloud and automating background syncs for instant reporting.

This post walks through everything you need to know to set up, operate, and monitor CDS view replication using the SAP HANA smart data access **abapodbc** adapter which is an extension to the already available federation as introduced by my colleague SeungjoonLee and my previous blog.

What Is CDS View Entity Replication?

At its core, CDS view replication lets you maintain a local copy of an SAP S/4HANA CDS view as a native table inside SAP HANA Cloud. Once the initial snapshot is loaded, subsequent updates are applied using **Change Data Capture (CDC)** — only inserts, updates, and deletes are fetched and replayed, not the entire dataset.

The result is a target table in SAP HANA Cloud that stays in sync with your S/4HANA source, with a freshness you control.

Why This Matters

– Performance: Local queries beat remote queries — no cross-system round trips at runtime.
– Availability: Your replica stays accessible even if the S/4HANA system is under maintenance.
– Flexibility: You can project specific columns or filter rows at the subscription level, so you only replicate what you need.
– Integration: The replicated table is a plain SAP HANA table — you can join it with other local data, build calculation views on top of it, or expose it via BTP services.

The Two Replication Phases

Replication is split into two distinct phases:

Phase 1: Initial Load

The initial load takes a full snapshot of the CDS view and copies it into the target table. You trigger this with the `QUEUE` command. The system handles chunking and parallelism internally — you just monitor progress.

One important caveat: the initial load does **not** check whether the target table is empty. If you're reloading after a reset, truncate the target table first.

Phase 2: Delta Load

Once the initial load completes, only changes (inserts, updates, deletes) are replicated. You have two options here:

– System-scheduled replication (`DISTRIBUTE`): The system automatically runs delta replication at a configurable interval. Set it once, let it run.
– User-driven replication (`DELTA LOAD`): You explicitly trigger replication whenever you want. Useful for controlled refresh scenarios or testing.

Setting It Up: 

Pre-requisite A — Setup Source System

Pre-requisite B — Configure Cloud Connector to Source 

Step 1 — Create a Remote Source

You need an abapodbc adapter remote source that connects SAP HANA Cloud to your S/4HANA system. This is your network tunnel between the two systems.

Step 2 — Create the Virtual Table and Target Table

Create a virtual table from the remote source (this is your read-through proxy to the CDS view), and create a local target table that will hold the replicated data.

Step 3 — Create the Remote Subscription

This is where the replication is defined. The `CREATE REMOTE SUBSCRIPTION` statement ties everything together:

-- Simplest form: replicate everything
CREATE REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION"
ON "SOURCE_CDS_VIEW"
TARGET TABLE "TARGET_TABLE";

-- Column projection: only replicate specific fields
CREATE REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION"
AS (SELECT "COL1", "COL2", "COL3" FROM "SOURCE_CDS_VIEW")
TARGET TABLE "TARGET_TABLE";

-- Row filter: only replicate rows matching a condition
CREATE REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION"
AS (SELECT * FROM "SOURCE_CDS_VIEW" WHERE "DEPARTMENT" = 'SALES')
TARGET TABLE "TARGET_TABLE";

The `WHERE` clause supports `=`, `<>`, `<`, `<=`, `>`, `>=`, `BETWEEN`, `IN`, `LIKE`, and logical operators `AND`/`OR`/`NOT`. A few syntax rules apply: field names must be double-quoted, string values single-quoted, and the right-hand side of a comparison must be a literal (no field-to-field comparisons).

Step 4 — Perform the Initial Load

ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" QUEUE;

Monitor progress in the `M_REMOTE_SUBSCRIPTION_INITIAL_LOADS` system view. The number of chunks can increase dynamically during the load as the system generates new ones.

Step 5 — Enable Delta Replication

Choose your mode:

-- Scheduled: run every 15 minutes
ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" DISTRIBUTE INTERVAL 900;

-- On-demand: trigger manually
ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" DELTA LOAD;

Load Behaviors: Normal vs. Upsert

When you create the subscription, you choose how DML operations are applied to the target table.

The upsert mode is useful when you want to preserve a history of deletions or need idempotent replay. It requires three additional metadata columns in the target table as shown below:

CREATE TABLE "TARGET_TABLE" (
"ID" INT,
"NAME" NVARCHAR(100),
"CHANGE_TYPE" NVARCHAR(1), -- 'A' = insert/update, 'D' = delete
"CHANGE_TIME" TIMESTAMP,
"CHANGE_SEQ" BIGINT -- optional: portion identifier
);

CREATE REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION"
ON "SOURCE_CDS_VIEW"
TARGET TABLE "TARGET_TABLE"
CHANGE TYPE COLUMN "CHANGE_TYPE"
CHANGE TIME COLUMN "CHANGE_TIME"
CHANGE SEQUENCE COLUMN "CHANGE_SEQ"
UPSERT;

Managing Replication Day-to-Day

Adjusting the Schedule

You can update the replication interval without triggering an immediate run — useful for shifting frequency during off-peak hours:

ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" INTERVAL 1800; -- 30 minutes

To immediately trigger replication AND update the interval:

ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" DISTRIBUTE INTERVAL 1800;

Suspending During Maintenance

If your S/4HANA system is going down for maintenance, suspend replication at the remote source level. All subscriptions under that source are paused; running jobs are allowed to finish but no new ones are scheduled.

ALTER REMOTE SOURCE  SUSPEND CAPTURE;

-- When the system is back up:
ALTER REMOTE SOURCE  RESUME CAPTURE;

Note that `SUSPEND CAPTURE` only affects system-scheduled jobs. Manual `DELTA LOAD` commands still work.

Cancelling a Running Job

If a replication job is consuming too many resources or is stuck, you can cancel it mid-execution:

-- Find the running job
SELECT CONNECTION_ID
FROM M_REMOTE_REPLICATION_JOBS
WHERE STATUS = 'RUNNING'
AND REMOTE_SUBSCRIPTION_NAME = 'ABAP_SUBSCRIPTION';

-- Cancel it
ALTER SYSTEM CANCEL SESSION '';

The system rolls back any partial changes, restoring the target table to its pre-job state. The job is automatically rescheduled for its next interval.

Resetting vs. Dropping

Reset returns the subscription to its initial state without removing it. Use this when you need to re-run the full initial load:

ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" RESET;
TRUNCATE TABLE "TARGET_TABLE";
ALTER REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION" QUEUE;

Drop permanently removes the subscription and cleans up resources on the ABAP source. The target table is retained.

DROP REMOTE SUBSCRIPTION "ABAP_SUBSCRIPTION";

Monitoring: The System Views You Need

SAP HANA provides a set of dedicated system views for CDS view replication. Here's when to use each one:

A few useful queries to keep handy:

-- Is my initial load done?
SELECT CHUNK_ID, TOTAL_RECORD_COUNT, EXECUTION_STATUS, EXECUTION_TIME
FROM M_REMOTE_SUBSCRIPTION_INITIAL_LOADS
WHERE REMOTE_SUBSCRIPTION_NAME = 'ABAP_SUBSCRIPTION';

-- What's my latest replicated version?
SELECT EXTERNAL_VERSION_ID
FROM REMOTE_SUBSCRIPTIONS
WHERE SUBSCRIPTION_NAME = 'ABAP_SUBSCRIPTION';

-- Did any scheduled jobs fail recently?
SELECT STATUS, ERROR_NUMBER, ERROR_MESSAGE, START_TIME, END_TIME
FROM M_REMOTE_REPLICATION_JOBS
WHERE REMOTE_SUBSCRIPTION_NAME = 'ABAP_SUBSCRIPTION'
ORDER BY START_TIME DESC;

Workload Management

Automatic replication jobs participate in SAP HANA's native admission control. You can define workload class thresholds to prevent replication from overwhelming the system:

CREATE WORKLOAD CLASS "AbapReplicationControl"
SET 'ADMISSION CONTROL REJECT CPU THRESHOLD' = '90',
'ADMISSION CONTROL QUEUE CPU THRESHOLD' = '70';

CREATE WORKLOAD MAPPING "AbapReplicationMapping"
WORKLOAD CLASS "AbapReplicationControl"
SET 'APPLICATION NAME' = '_SYS_REMOTE_REPLICATION_ABAP_DELTA_LOAD';

Jobs that exceed the QUEUE threshold are delayed; jobs that exceed the REJECT threshold fail with an error and are rescheduled.

Limitations to Know Before You Start

Before you commit to a schema design, check these constraints:

– Load behavior: Only Normal and Upsert are supported. INSERT and ARCHIVE load behaviors are not.  (Archived data in the source are converted to deletes and will be removed from the target table)
– Schema changes: The `WITH SCHEMA CHANGES` clause is not supported. If the CDS view schema changes, replication will fail and you'll need to manually update the target table and recreate the subscription.
– Initial load: Only the automated `QUEUE` command is supported. The manual `INITIAL LOAD PREPARE/EXECUTE/FINALIZE` flow is not available.
– Subquery expressions: Column projection and row filtering work. Function calls like `UPPER()` or arithmetic expressions in the subquery do not.
– Subscription query: Once created, the subscription query cannot be changed. `ALTER REMOTE SUBSCRIPTION … REFRESH DEFINITION` is not supported. Recreate it if you need to change the filter or projection.
– Target type: Only `TARGET TABLE` is supported. `TARGET PROCEDURE` and `TARGET TASK` are not.
– **NULL handling**: Empty values on the ABAP side (empty strings, zeros) may arrive as `NULL` in the target table. Account for this in downstream logic.

—

Summary

CDS view replication with the abapodbc adapter gives you a clean, CDC-based pipeline from SAP S/4HANA into SAP HANA Cloud. The lifecycle is straightforward: create the subscription, run the initial load with `QUEUE`, then choose between scheduled replication (`DISTRIBUTE`) or on-demand updates (`DELTA LOAD`). Built-in system views give you full visibility into job status, and native workload management ensures replication doesn't compete with your critical workloads.

The main things to keep in mind:

1. Truncate the target table before re-running the initial load — the system won't do it for you.
2. Schema changes on the source CDS view require a manual rebuild of the subscription.
3. Orphaned replications can silently drain ABAP resources — check with `DHADM` after any failed `CREATE REMOTE SUBSCRIPTION`.
4. Failed scheduled jobs are **not** automatically rescheduled — you need to re-issue `DISTRIBUTE` after resolving the error.

With that, you have everything you need to get replication running and keep it healthy in production.