16.5 CDS Extraction
1. Objective
The goal is to move from:
"I found a CDS view"
to:
"I have a supported, extraction-ready business interface."
2. End-to-end pattern
S/4HANA CDS
|
| extraction-enabled
v
SAP Datasphere connection
|
v
Remote source object
|
+--> federation
|
+--> replication flow
|
v
local persistence
3. Implementation sequence
- Identify the business object.
- Find the appropriate CDS view.
- Verify supported release status.
- Verify extraction capability.
- Validate grain and keys.
- Validate required delta behavior.
- Configure the Datasphere connection.
- Discover the source object.
- Create the required Datasphere object or replication flow.
- Perform an initial load.
- Validate row counts and business totals.
- Validate delta behavior.
- Document ownership and support.
4. Do not skip grain validation
Suppose the business expects one row per sales order item.
If the CDS view produces multiple rows because of:
- partner functions,
- pricing elements,
- schedule lines,
- text joins,
then a successful technical load can still be logically wrong.
Always document:
Expected grain:
one row per ...
Actual source grain:
one row per ...
Transformation:
...
5. Initial-load validation
Validate at least:
- record count,
- key uniqueness,
- null keys,
- business totals,
- date ranges,
- currency/unit semantics,
- representative samples.
6. Delta validation
Create controlled source changes:
- insert,
- update,
- delete if supported.
Verify that the target receives the expected changes.
Do not validate delta using only an application screen. Reconcile source and target using deterministic checks.
7. Extraction anti-pattern
Do not build an enterprise pipeline around an undocumented internal CDS view simply because it works today.
Prefer supported, stable, extraction-enabled interfaces.
Architect exercise
Create a CDS extraction design for billing documents.
Include:
- source CDS,
- extraction mode,
- grain,
- initial load,
- delta validation,
- target,
- monitoring,
- reconciliation.