Phase 04 — Data Acquisition

Architectural objective: learn how to acquire data into SAP Datasphere safely, predictably, and with an explicit decision about connectivity, persistence, freshness, source impact, and ownership.

Phase 03 established the integration architecture and the major movement patterns.

This phase moves one level closer to implementation:

How do we actually acquire data from the source without creating an accidental production problem?

This phase is intentionally focused on the acquisition boundary. Data Flow, Replication Flow, Transformation Flow, and Task Chain engineering are introduced here but are treated in depth in Phase 11 — Data Flows, Replication & Task Chains.

1. Why Data Acquisition Is an Architecture Problem

Data acquisition is the boundary between a source system and the governed analytical environment. The mistake beginners make is treating acquisition as a mechanical import step. An architect treats it as a decision about ownership, latency, persistence, connectivity, source impact, security, recoverability, and lifecycle. Before acquiring anything, answer seven questions:

1. What is the authoritative source?
2. What is the required freshness?
3. Must the data be physically persisted in Datasphere?
4. Is the source allowed to serve analytical queries directly?
5. What delta or change mechanism exists?
6. What connectivity path is permitted?
7. Who owns the source, pipeline, target, and operational SLA? These questions determine whether the correct pattern is federation, replication, a flow, a file/object-store load, an Open SQL hand-off, a semantic import, or a Business Data Cloud data product.

2. The Acquisition Mental Model

Think of acquisition as four layers:

• Source capability — what the source can expose.
• Connection capability — how Datasphere can reach the source.
• Acquisition mechanism — remote table, replication, data flow, transformation flow, file import, semantic import, data product, or SQL interface.
• Target representation — remote table, local table, object-store data, or a semantic object. The same source can legitimately use different acquisition patterns for different datasets. For example, a high-volume historical fact table may be replicated, while a small slowly changing reference table may remain federated. Do not choose one acquisition method for an entire source system merely because the connection exists.

3. Current SAP Datasphere Acquisition Landscape

SAP Datasphere currently provides multiple acquisition paths rather than a single universal ETL mechanism. Important patterns include:

• Remote tables for federated access and, where supported, replication.
• Replication flows for copying multiple source objects with delta-load capabilities.
• Data flows for graphical movement and transformation into local tables.
• Transformation flows for transforming local Datasphere data and, where applicable, using additional transformation capabilities.
• CSV and file-based acquisition for controlled file ingestion.
• Semantic imports from supported SAP systems.
• SAP Business Data Cloud data products where the tenant participates in the required formation.
• Open SQL schema integration for externally managed ingestion.
• HDI-container integration for SAP application data.
• Object-store acquisition for suitable large-volume workloads. Current SAP guidance positions replication flows and transformation flows as preferred loading patterns when an existing data flow is eligible for conversion. This course therefore introduces data flows here, but the engineering depth belongs in Phase 11.

4. Acquisition Architecture Reference

Use this reference model when designing a production acquisition path:

Source System
    │
    ├── SAP S/4HANA / BW / HANA
    ├── Non-SAP database / SaaS
    ├── Files / object storage
    └── Partner / data product
            │
            ▼
     Connectivity Layer
            │
     ┌──────┼────────┐
     │      │        │
 Federation Replication  File / SQL / Product
     │      │        │
     └──────┼────────┘
            ▼
      Acquisition Layer
            │
            ▼
     Datasphere Space
            │
     ┌──────┴─────────┐
     │                │
 Remote Table     Local Table / Object Store
     │                │
     └──────┬─────────┘
            ▼
   Preparation + Modeling
            ▼
       Consumption

Notice that acquisition is upstream of modeling. Do not solve modeling problems by blindly moving more data.

5. Connection vs Acquisition Object

A connection is not the data itself. A connection defines how Datasphere can communicate with a source or target and which features that connection type supports. An acquisition object is what you actually use in the space, such as a remote table or a local target populated by a flow. This distinction matters because:

• One connection can support multiple objects.
• A connection may support remote tables but not replication flows.
• A connection may support replication flows but not remote tables.
• A connection can be technically valid while the desired acquisition feature is unavailable.
• Connection availability is therefore not equivalent to acquisition compatibility. Always check the feature matrix for the exact connection type before designing the pipeline.

6. Connection Capability Matrix

Evaluate every connection against these dimensions:

Capability	Architect question
Remote tables	Can I federate source data?
Replication flow source	Can I copy source objects with delta processing?
Replication flow target	Can the connection receive replicated data?
Data flow source	Can the source participate in a data flow?
Semantic import	Can Datasphere import business semantics from this source?
Model import	Can existing analytical models be brought across?
File-space support	Can this connection operate with object-store/file-space patterns?
Real-time replication	Are source changes captured continuously or near real time?
Scheduled refresh	Can freshness be achieved through scheduled loads?
On-premise connectivity	Is Cloud Connector or Data Provisioning Agent required?
Never infer these capabilities from the source product name alone.

7. Remote Tables

A remote table exposes source data to Datasphere without requiring the dataset to be fully persisted locally first. For supported connections, remote tables can be used for federation and may also be enabled for replication. Default mental model:

• Federation: query reaches the source when the data is used.
• Replication: source data is copied into Datasphere and queried locally. Remote tables are attractive when:
• the source remains authoritative;
• the dataset is relatively small or low-volume;
• freshness requirements are high;
• source query performance is acceptable;
• data residency and network policy permit live access;
• the cost of replication is not justified. Remote tables are dangerous when:
• analytical queries generate heavy source-system load;
• network latency is unpredictable;
• source availability is weaker than the analytical SLA;
• complex transformations require repeated remote execution;
• the source cannot tolerate broad scans.

8. Federation vs Replication

Dimension	Federation	Replication
Physical copy	No local copy of the dataset by default	Data stored in Datasphere
Query latency	Depends on source and network	Usually more predictable locally
Source load	Analytical queries can reach source	Load is concentrated in ingestion
Freshness	Potentially very high	Depends on replication capability and schedule
Source availability dependency	High	Lower after successful replication
Storage cost	Lower local storage	Higher local storage
Historical retention	Depends on source	Can be retained locally
Transformation freedom	More constrained by federation	Greater downstream flexibility
Recovery	Depends on source availability	Local copy can support recovery patterns
Typical use	Small, current, operational/reference data	Analytics, high-volume, repeated consumption
Architect rule: choose federation because it is the right workload pattern, not because replication is harder.

9. Data Acquisition from SAP S/4HANA

S/4HANA is one of the most important Datasphere acquisition scenarios. Separate three architectural goals:

1. Semantically rich acquisition.
2. Table-level or object-level replication.
3. Live/federated access. Where supported, semantic import can bring entities with metadata and semantics rather than treating the source as an anonymous collection of tables. For enterprise analytics, prefer business-level extraction contracts where they provide the required semantics and lifecycle stability. Do not automatically expose raw application tables simply because they are technically accessible. Source-side questions:

• Is the object released and supported for analytical integration?
• Does it provide delta capability?
• What is the expected extraction volume?
• Does it carry business semantics?
• Is the object stable across upgrades?
• Does the extraction method create operational load?

10. SAP CDS and Semantic Acquisition

CDS-based acquisition is important because the extraction contract can be closer to business semantics than a raw table contract. Use CDS-based approaches when the source provides an appropriate analytical or integration entity and when its semantics and lifecycle are aligned with the requirement. Do not assume every CDS view is automatically an ideal Datasphere acquisition source. Evaluate:

• release status;
• extraction enablement;
• delta behavior;
• key definition;
• authorization behavior;
• semantic annotations;
• volume;
• source performance;
• compatibility with the target architecture. Later Phase 16 covers CDS and ODP in much greater depth.

11. SAP ODP and Acquisition Contracts

Operational Data Provisioning is a framework used across SAP data extraction scenarios and is particularly important for BW-oriented landscapes. For Datasphere architecture, understand ODP as an extraction contract rather than merely as a BW technology. Questions to answer:

• What provider exposes the data?
• What delta mechanism is available?
• Who owns the queue/state?
• How is initialization performed?
• How are deletes represented?
• What happens after a failed subscriber load?
• How is reconciliation performed? Phase 16 will connect these concepts to CDS, S/4HANA, ODP/ODQ, and enterprise SAP extraction patterns.

12. SAP BW and BW Bridge Acquisition

Datasphere can participate in landscapes where SAP BW or SAP BW/4HANA remains an important source or where BW Bridge is used as part of the architecture. Do not collapse three concepts:

• consuming existing BW data;
• transferring or reusing BW models;
• building new acquisition pipelines directly from operational sources. An architect must decide whether the requirement belongs in the existing BW semantic layer, a BW Bridge pattern, or a native Datasphere model. Phase 17 is dedicated to BW/4HANA and BW Bridge. Here, learn only the acquisition decision.

13. Non-SAP Database Acquisition

Non-SAP sources may include Oracle, SQL Server, PostgreSQL, Snowflake, Redshift, BigQuery, and other supported technologies. Evaluate the source using the same principles:

• connectivity;
• supported feature set;
• pushdown capability;
• federation latency;
• replication support;
• change capture;
• volume;
• source workload;
• network topology;
• security requirements;
• cost. Do not assume that two databases with JDBC/ODBC connectivity have identical Datasphere behavior.

14. Cloud Source Acquisition

Cloud sources change the network and security model but not the fundamental acquisition decisions. Ask:

• Is the source in the same cloud region?
• Is private connectivity available?
• Are public endpoints permitted?
• Where are credentials stored?
• Is egress charged?
• Does the source support incremental extraction?
• Does the connection support the required Datasphere feature?
• Is data sovereignty preserved? An architecture that works technically but creates unexpected cross-region egress cost is not production-ready.

15. File and CSV Acquisition

CSV acquisition is useful for controlled operational datasets, small reference data, business-maintained files, and POCs. Treat files as data contracts, not as harmless attachments. Define:

• file naming;
• schema;
• delimiter;
• encoding;
• header rules;
• decimal and date conventions;
• null representation;
• duplicate handling;
• delivery frequency;
• retention;
• validation;
• quarantine behavior. CSV is simple only when the contract is simple. Enterprise file ingestion requires operational discipline.

16. Object Storage and File Spaces

Large-volume acquisition can be better suited to object storage/file-space patterns than traditional in-memory relational persistence. Understand the difference between:

• a file as an inbound delivery artifact;
• a table persisted in a Datasphere relational store;
• data stored in the Datasphere object store/file space;
• a remote object that remains owned by another platform. Object-store architecture should be evaluated on volume, cost, access pattern, transformation needs, lifecycle, and downstream consumption.

17. SAP Business Data Cloud Data Products

When the Datasphere tenant participates in the appropriate SAP Business Data Cloud formation, data products can become an acquisition path. Data products change the acquisition conversation from technical extraction to governed data consumption. Architectural questions:

• Who publishes the product?
• What business semantics and quality commitments exist?
• What refresh SLA exists?
• Who owns the data?
• What licensing or entitlement applies?
• What is the lifecycle contract?
• Can the product replace a custom extraction pipeline? Prefer a trusted, governed data product when it satisfies the requirement better than building and operating a custom pipeline.

18. Open SQL Schema Integration

Open SQL schema integration allows external processes or ETL tools to write data into a Datasphere-accessible schema. This is useful when the enterprise already has an integration platform and Datasphere should consume the resulting data rather than own the complete ingestion process. Design carefully around:

• ownership;
• write permissions;
• table lifecycle;
• schema evolution;
• load completion signaling;
• idempotency;
• reconciliation;
• security;
• operational monitoring. Do not use Open SQL as an excuse to bypass Datasphere governance.

19. HDI Container Integration

HDI-container integration is relevant when SAP application development and Datasphere analytics meet. An HDI container can contain application-managed data structures that analytics needs to consume. Separate application ownership from analytical ownership. Questions:

• Is Datasphere reading application data directly?
• Is a curated analytical contract provided?
• Who controls schema changes?
• Is the data transactional or analytical?
• What security boundary exists between application and analytics? This pattern belongs in the broader SAP HANA integration architecture covered later.

20. On-Premise Connectivity

On-premise acquisition requires an explicit network architecture. Typical building blocks can include SAP Cloud Connector, Data Provisioning Agent, or source-specific connectivity depending on the connection and feature. Do not teach Cloud Connector and DP Agent as interchangeable products. Evaluate:

• federation vs replication;
• required adapter;
• source protocol;
• network route;
• outbound-only requirements;
• credential handling;
• high availability;
• patching;
• monitoring;
• ownership. Connectivity is part of the production architecture, not an installation footnote.

21. Cloud Connector Decision

Use Cloud Connector when the supported Datasphere connection pattern requires secure access to an on-premise endpoint through the SAP connectivity architecture. Architectural principles:

• avoid unnecessary inbound firewall exposure;
• keep source access narrowly scoped;
• separate environments where required;
• document virtual-to-internal host mappings;
• monitor tunnel health;
• define ownership and patching. Never say 'Cloud Connector is required for Datasphere' without qualifying the exact connection and feature.

22. Data Provisioning Agent Decision

The Data Provisioning Agent is used for supported integration scenarios that need agent-based connectivity and adapters. Evaluate it separately from Cloud Connector. Questions:

• Which adapter is required?
• Does the acquisition method require agent connectivity?
• Where should the agent run?
• How is it patched?
• How is HA achieved?
• What credentials does it hold?
• What network paths does it open? Treat the agent as production middleware with an owner, monitoring, backup/recovery procedure, and lifecycle.

23. Initial Load Architecture

Every acquisition design should explicitly describe initialization. Typical stages:

1. Validate source metadata.
2. Establish connection.
3. Validate access and authorization.
4. Determine target schema.
5. Perform initial load.
6. Validate row counts and key totals.
7. Establish delta state if supported.
8. Start steady-state processing. Never treat initial load as a one-time technical detail. It establishes the baseline from which future deltas are interpreted.

24. Delta and Change Processing

A delta load is meaningful only when the source provides a reliable change contract. Evaluate:

• inserts;
• updates;
• deletes;
• late-arriving changes;
• out-of-order events;
• duplicate events;
• reprocessing;
• checkpoint state;
• source retention window. Do not call a scheduled full refresh a delta strategy. Do not assume timestamp columns are a reliable delta mechanism without validating update semantics.

25. Delete Handling

Delete handling is one of the most commonly missed acquisition requirements. Ask whether the source exposes deletes and how they are represented. Possible patterns include:

• explicit delete records;
• change logs;
• tombstones;
• source-side soft deletes;
• periodic reconciliation;
• full reload. A pipeline that captures inserts and updates but silently misses deletes can produce permanently incorrect analytical results.

26. Source-System Protection

An analytical platform must not become a denial-of-service client for an operational system. Protect sources with:

• selective extraction;
• filters;
• projection pruning;
• appropriate load windows;
• replication instead of repeated federation where justified;
• incremental extraction;
• source-side indexing where appropriate;
• workload monitoring;
• concurrency limits. Source protection is a business requirement because operational disruption is usually more expensive than analytical latency.

27. Data Acquisition Security

Secure acquisition across four boundaries:

1. Identity — who connects?
2. Network — where can traffic travel?
3. Authorization — which source objects are visible?
4. Data — what sensitive fields cross the boundary? Use least privilege. Prefer technical users or supported credential mechanisms with clearly defined ownership. Do not embed credentials in documentation, scripts, notebooks, or screenshots. Classify sensitive data before selecting federation or replication because the storage location changes the control surface.

28. Schema Evolution

Source schemas change. Production acquisition must define what happens when:

• a column is added;
• a column is removed;
• a datatype changes;
• a key changes;
• a view is replaced;
• a semantic annotation changes;
• a source object is deprecated. Choose explicit policies:
• fail fast;
• accept additive changes;
• quarantine;
• version the contract;
• require controlled redeployment. Never rely on 'the source team will inform us' as the only schema governance mechanism.

29. Data Quality at Acquisition Boundary

Acquisition should establish technical correctness before business transformation. Validate:

• connectivity;
• schema;
• row counts;
• null rates for required keys;
• duplicate business keys;
• data type conformity;
• date ranges;
• source freshness;
• control totals. Business rules can belong downstream, but technical integrity must be established as close to acquisition as practical.

30. Acquisition Monitoring

Monitor at least:

Signal	Why it matters
Last successful load	Availability
Data freshness	SLA compliance
Rows loaded	Volume anomaly detection
Rows rejected	Data quality
Duration	Performance drift
Source connectivity	Network/source health
Delta backlog	Change-processing health
Schema change	Contract risk
Target storage	Capacity/cost
Monitoring should answer not only 'did the job run?' but also 'is the data trustworthy and fresh enough to use?'

31. Acquisition Decision Tree

Use this sequence:

1. Is a governed SAP Business Data Cloud data product already available and suitable?
   • Yes → evaluate consumption before custom extraction.
   • No → continue.
2. Does the source need to remain live and is source query load acceptable?
   • Yes → evaluate federation/remote table.
   • No → continue.
3. Does the source support reliable replication/delta processing?
   • Yes → evaluate replication flow or supported replication pattern.
   • No → continue.
4. Is transformation required during ingestion?
   • Yes → evaluate the appropriate flow pattern.
   • No → use the simplest supported acquisition path.
5. Is the source file/object based?
   • Yes → evaluate file/object-store acquisition.
6. Is an external ETL platform already authoritative for ingestion?
   • Yes → evaluate Open SQL/schema hand-off.
7. Is the source on-premise?
   • Yes → design Cloud Connector/agent topology explicitly.
8. Does the source expose business semantics?
   • Yes → prefer supported semantic acquisition where it meets requirements.

32. Common Acquisition Anti-Patterns

Anti-pattern 1 — Federate everything

Why it fails: source load, network dependency, unpredictable latency, and poor analytical isolation.

Anti-pattern 2 — Replicate everything

Why it fails: storage, duplication, unnecessary pipelines, and increased lifecycle cost.

Anti-pattern 3 — Build a custom pipeline when a governed data product exists

Why it fails: duplicate ownership and operational burden.

Anti-pattern 4 — Treat connection success as pipeline success

Why it fails: connectivity does not prove feature compatibility, delta correctness, or data quality.

Anti-pattern 5 — Ignore deletes

Why it fails: analytical truth diverges silently.

Anti-pattern 6 — Use full loads forever

Why it fails: increasing volume and runtime eventually become operational constraints.

Anti-pattern 7 — Put source credentials into code

Why it fails: security and rotation risk.

Anti-pattern 8 — Let every project create its own connection

Why it fails: duplicated security review, inconsistent ownership, and uncontrolled topology.

33. Developer → Architect Progression

Level	Expected capability
Beginner	Create a connection and acquire a table
Developer	Choose remote vs replicated data
Senior developer	Implement initial/delta acquisition and troubleshoot failures
Lead	Design source protection, monitoring, and environment strategy
Architect	Select acquisition patterns across SAP, cloud, non-SAP, security, cost, SLA, and lifecycle
The goal of this phase is to move beyond 'I know how to import a table' toward 'I can justify the acquisition architecture.'

34. Hands-On Lab 1 — Remote Table

Scenario: acquire a small reference dataset from a supported source. Tasks:

1. Create or use an approved connection.
2. Verify the connection feature matrix.
3. Import the remote table.
4. Inspect metadata and sample data.
5. Test query latency.
6. Identify source-system impact.
7. Decide whether federation remains appropriate. Deliverable: a one-page decision record explaining why the dataset should remain federated or be replicated.

35. Hands-On Lab 2 — Replication

Scenario: acquire a high-volume analytical dataset. Tasks:

1. Identify the source change mechanism.
2. Estimate initial-load volume.
3. Define the target grain.
4. Configure the supported replication pattern.
5. Execute initialization.
6. Validate counts and control totals.
7. Verify delta behavior.
8. Test restart/recovery.
9. Measure freshness. Deliverable: an operational runbook containing load, validation, failure, and reconciliation steps.

36. Hands-On Lab 3 — File Acquisition

Create a controlled CSV ingestion contract. Include:

• sample file;
• schema definition;
• naming convention;
• validation rules;
• duplicate policy;
• bad-file handling;
• delivery SLA;
• retention policy. Then document how the architecture changes if the file volume grows from thousands to tens of millions of records.

37. Hands-On Lab 4 — Acquisition Architecture Comparison

Design three solutions for the same dataset: A. Federation. B. Replication. C. External ingestion followed by Open SQL/schema hand-off. Compare:

• latency;
• source load;
• storage;
• operational complexity;
• failure modes;
• cost;
• security;
• recovery. Then select one and defend the decision.

38. Troubleshooting Playbook

Connection cannot be created

Check source prerequisites, network route, authentication, feature availability, and required middleware.

Connection works but remote table is unavailable

Check whether the connection type supports remote tables and whether the feature is enabled.

Replication starts but fails

Check source object compatibility, permissions, metadata, delta capability, target configuration, and integration logs.

Data is stale

Check last successful execution, schedule, delta state, source change capture, and backlog.

Counts do not reconcile

Check filters, deleted records, duplicate keys, initialization boundary, timezone handling, and late-arriving changes.

Source system is slow

Check federation query patterns, missing filters, broad projections, concurrency, and whether replication should replace live access.

Schema change breaks the pipeline

Compare source metadata with target contract and determine whether additive changes are allowed.

39. Architect Exercise — Global Procurement Platform

Design acquisition for:

• S/4HANA procurement transactions;
• supplier master data;
• an external logistics database;
• monthly Excel reference data;
• a cloud data product;
• historical data retained for seven years. Requirements:
• operational source protection;
• daily analytical freshness for most datasets;
• near-real-time supplier status;
• governed access;
• auditable loads;
• cost control. Your architecture must state:

1. Acquisition mechanism per source.
2. Connectivity path.
3. Persistence choice.
4. Delta strategy.
5. Security boundary.
6. Monitoring.
7. Recovery approach.
8. Ownership.
9. Reason alternatives were rejected.

40. Interview Preparation

Q1. What is the difference between federation and replication?

Explain physical persistence, latency, source dependency, source load, and cost.

Q2. Is a connection the same as a remote table?

No. A connection defines connectivity and feature capability; a remote table is an acquired modeling object representing source data access.

Q3. When would you replicate instead of federate?

When predictable analytical performance, source protection, historical retention, transformation, or reduced runtime source dependency justifies persistence.

Q4. Why should you inspect connection capabilities?

Because supported features differ by connection type.

Q5. What is a delta load?

An incremental change-processing mechanism that transfers changes rather than repeatedly reloading the full dataset.

Q6. Why are deletes important?

Without reliable delete handling, the target can diverge from the source.

Q7. When would you use a data product?

When a governed, reusable product satisfies the requirement and provides a better ownership and lifecycle contract than a custom extraction.

Q8. Is Data Flow always the preferred ingestion method?

No. Current SAP guidance favors replication flows and transformation flows for eligible loading scenarios; Data Flow remains a supported pattern for applicable cases.

Q9. What should an architect monitor?

Connectivity, successful execution, freshness, volume, duration, errors, delta backlog, schema changes, and storage/cost signals.

Q10. How do you protect S/4HANA from analytics?

Prefer selective extraction, incremental processing, appropriate replication, filtering, source-side workload controls, and monitoring instead of uncontrolled federation.

41. Production Checklist

• Source ownership documented.
• Connection ownership documented.
• Feature matrix verified.
• Source-to-target contract documented.
• Federation vs replication decision recorded.
• Initial-load strategy documented.
• Delta strategy documented.
• Delete handling documented.
• Schema-evolution policy documented.
• Security and credentials reviewed.
• Network topology reviewed.
• Source impact assessed.
• Data-quality checks defined.
• Monitoring and alerting configured.
• Reconciliation procedure documented.
• Failure/restart procedure tested.
• Storage and cost estimated.
• Environment strategy defined.
• Ownership and SLA agreed.

42. Architect Takeaway

Data acquisition is the discipline of bringing the right data into the right analytical boundary with the right freshness, persistence, security, and operational contract. The strongest Datasphere architect does not ask:

'How do I load this table?' They ask: 'What is the smallest, safest, most reliable acquisition pattern that satisfies the business SLA and remains supportable at enterprise scale?' That is the foundation for the next phases:

• Phase 05 — Data Preparation & Transformation
• Phase 06 — Graphical Modeling
• Phase 07 — SQL & SQLScript Modeling
• Phase 08 — Semantic Modeling
• Phase 09 — Analytic Models & Consumption
• Phase 11 — Data Flows, Replication & Task Chains
• Phase 16 — S/4HANA, CDS, ODP & SAP Integration
• Phase 17 — BW/4HANA & BW Bridge
• Phase 18 — HANA, Cloud & Non-SAP Integration Do not treat acquisition, transformation, and modeling as interchangeable activities. Keeping those boundaries clear is what makes the enterprise architecture understandable and operable.

Official SAP Documentation Anchors

The architecture in this phase is aligned with current SAP Datasphere documentation for acquiring data, connection capabilities, remote tables, replication flows, data flows, and transformation flows.

• SAP's current Acquiring Data documentation covers remote-table federation/replication, data flows, replication flows, SAP S/4HANA acquisition, SAP BW/BW Bridge acquisition, CSV import, and other acquisition paths.
• SAP's current Connection Types Delivered by SAP documentation emphasizes that supported capabilities vary by connection type.
• SAP's current guidance states that replication flows and transformation flows are preferred loading mechanisms for eligible scenarios compared with older data-flow patterns.

Always verify the feature matrix and current product documentation for the exact Datasphere release and connection type used in a project.