SAP BDC Architecture

SAP Datasphere key challenges you faced in real time:

Data integration and replication challenges
 Immature and unstable connectivity for non-SAP sources
 Inefficient Real-time replication: The Change Data Capture (CDC) mechanism in
replication flows can cause significant and sustained load on source systems, such as
S/4HANA, by running continuously.

 Impact of source system changes: Alterations to data types, table structures, or the
underlying configuration of applications like SuccessFactors can disrupt data
replication and synchronization, requiring manual rework and careful change
management.

 Licensing and API restrictions: Recent changes to SAP's licensing terms have
restricted third-party tools from using ODP APIs for real-time extraction from SAP
sources. This forces companies to explore alternative integration methods like OData
APIs, which can result in slower performance.

Data modeling and transformation challenges

Poor debugging and testing tools: Datasphere lacks robust debugging and execution plan
views, making it difficult to analyze and troubleshoot complex data transformations .Eg.,
Performance Analysis Mode in HANA CVs and SQL Analyzer(Plan Viz)
Performance and optimization hurdles
 Slow performance with remote data
 Memory management limitations
 Inadequate built-in monitoring tools
Governance and security challenges
 Data access control (DAC) limitations: Existing DAC mechanisms cannot easily apply
row-level or object-level security across different models within the same space,
which is a major hurdle for governance in large enterprises.
 Security for non-SAP data: While Datasphere has robust security for SAP data,
ensuring consistent governance and security policies across diverse non-SAP data
sources requires additional effort and configuration.
CDS View Creation & Features:
SAP HANA Studio (or Eclipse with ABAP Development Tools)-launch the environment- open
the Project Explorer - right-click your package - select New - Other ABAP Repository Object -
Core Data Services - Data Definition - Select Transport Request - Choose a template for
defining the view, such as Define View or Define View with Join.
CDS View Types
 Basic Views: Expose master data (dimensions) from underlying database tables.
Examples include customer master, material master, company code.
 Composite Views: Combine basic views and/or other composite views, acting as an
aggregation layer (similar to a BW Cube). These views must contain at least one
measure.
 Consumption Views: The final layer for consumption by reporting tools and
analytical applications. These views are often exposed as OData services.
CDS Data categories define the business context for data in a CDS view, typically
including Dimension (master data like customer or material), Fact (transactional data with
measures and units), and Cube (transactional data that can be combined with master data).
How to check CDS views extraction enabled:
SE16N: In an S/4HANA system, to view the IXTRCTNENBLDVW (I\
_DataExtractionEnabledView)
Annotaions: Extraction Enabled True/ CDC(change Data Capture:Delta enabled/
Authorizations enabled/ Curreny code enabled
Finance Related CDS Views:
Basic: I_JournalEntryItem: Provides access to all line-item details from the Universal
Journal, including GL, controlling, and asset accounting information.
  I_JournalEntryItemCube: A specialized basic view that is a source for accounting
balances and does not include technical balance carry-forward items from period
000. It is widely used for financial reporting.

2. Composite and consumption views:

These views sit on top of the basic views and are designed for specific business purposes,
such as reporting on balances, trial balances, or line items from a particular perspective.
General Ledger (G/L) accounting and reporting
 I_GLAcctBalanceCube: A standard analytical view for reporting on aggregated
accounting balances.
 C_Trialbalanceq0001: A consumption view used for querying the trial balance.
 I_GLPlanningView: Combines both actual data (from ACDOCA) and plan data (from
ACDOCP) for comparative analysis.
 I_AccountingDocumentItem: A compatibility view that replicates the structure of the
classic BSEG table by retrieving data from ACDOCA
Financial planning and analysis (FP&A)
These views are based on the ACDOCP table (the planning version of ACDOCA) and enable
planning functionalities, often in conjunction with SAP Analytics Cloud (SAC).
 I_ACDOCAPLAN: Analogous to I_JournalEntryItem, this view provides granular access
to line items for financial planning.
 I_CostCenterPlan: Used for cost center planning and reporting.
 I_ProfitCenterPlan: Used for profit center planning and reporting.
 I_FinancialStatementPlan: Focuses on the planning data for financial statement
items.
Specific finance sub-processes
 Receivables Management: Views
like I_ARAgingGridCube and I_DaysSalesOutstanding build on ACDOCA to provide
insights into accounts receivable and customer payments.
 Payables Management: Views
like I_APAgingGridCube and I_DaysPayableOutstanding are used for accounts
payable reporting.
 Asset Accounting: ACDOCA contains asset accounting data, which is consumed by
specific views for reporting on fixed assets.
  DATA FEDERATION FIRST THEN DATA REPLICATION, The approach for using the CDS
view as a data federation goes back to the basics
1.Select the required columns from the projection. e.g. CDS view may have 200 columns
however business may require 75 columns. hence select only 75 columns.
2.Filter the data as early as possible based on attributes like company code, sales org, plant,
dates, or periods.
3.Business logic and data aggregation can be handled in the source CDS view, you do not
have to do it on SAP Datasphere, unless required.
4.Use the view persistency option intelligently to get optimized data and high performance.
Restrictions: 2890171 - SAP Data Intelligence / SAP Datasphere - ABAP Integration
1.Not supported for data transfer if the CDS view not having the "dataExtraction"
annotation.
2.CDS view for the delta load requires the "dataExtraction" and "changeDataCapture"
annotations.
3.CDS Views having parameters and a table function are not supported.
4.CDS Views include Tables with a client field as a key, not a client-dependent field.
5.Data extraction halts with an error if the structure of a table or CDS view changes mid-load
or replication. Unfortunately, resuming after such an error isn't currently possible, requiring
a full restart of the data extraction process.
6.CDS views having more than 2 billion record set (internal HANA memory constraint),
Workaround is to create custom CDS views with data split and either replicate into the same
target table or union the individual target tables.
An alternative option is ODP extractors: If the ABAP CDS view is unavailable then prefer
ODP objects over the direct ABAP table replication. A direct connection can be established
provided SAP S/4HANA has the DMIS add-on.
1.The discouraged option is Direct ABAP Table Access and Replication: Bypassing CDS views
to replicate tables into SAP Datasphere directly is not recommended. This approach involves
replicating raw data (master and transactional) without its inherent business context and
relationships. Essentially, you'd be replicating the data and then manually recreating the
associations, logic, and hierarchies – a time-consuming and error-prone process. The
preferred approach is to leverage the existing, comprehensive CDS data models whenever

possible.
However, if replicating tables is unavoidable due to specific business or compliance
requirements, then the recommendations below should be followed.
1.Standalone SAP LT Replication Server: For replicating tables, the recommended approach.
2.Restrictions:1.Replicating tables with redirect views (e.g., MBEW, MARD, COEP) from your
SAP S/4HANA source system is not supported.
2.Declustering of INDX-like tables (e.g. STXL, PCL1, ...) during the transfer is not supported.
SAP S/4HANA Connection Supported SAP Datasphere Integration Features:

SAP S/4HANA Data Integration:

Source Object Types:
1. ABAP CDS Views: It provides business data along with semantic(context) information
(hierarchies, text, etc.), security, associations, and improved performance.
2. ODP Extractors: Specialized tools designed to extract specific datasets from SAP
S/4HANA.
3. ABAP Tables: The traditional SAP master and fact tables are used for raw business
data storage.
Delta Handling Mechanisms During Data Replication:
1. Database Trigger-based CDC Delta: This method leverages database triggers to
capture changes in real time. It utilizes the well-established SAP Landscape
Transformation Replication Server (SLT) technology.ABAP Pipeline Engine (APE): This
framework provides flexibility for building custom CDC pipelines suited to specific
needs.
2. Generic Timestamp/Date-based Delta: This approach relies on a designated
timestamp/date column within your ABAP CDS views to identify data modifications.
ODP Technical Infrastructure:
 Operational Data Provisioning (ODP) Framework: This is the modern framework for
CDC, replacing the older RSA7 (BW Delta Queues) approach. It simplifies data
extraction and management.
 Operational Delta Queue (ODQ): This queue stores changes made to data until they
are replicated.
Data Builder Objects in SAP Datasphere facilitate your integration with SAP S/4HANA:
1. Remote Tables: Enable access to SAP S/4HANA data in real-time or through
snapshots.
 2. Replication Flows: These define the path for data replication from source to target
system.
3. Data Flows: These specify the transformations applied to the data during replication.
4. SAP S/4HANA Data Integration Explained:
5. This diagram illustrates various methods for integrating data with SAP S/4HANA,
covering both data federation and replication scenarios.

Audit Logs:

SAP Datasphere audit logs are used for security analysis, compliance, and root-cause analysis,
tracking who did what and when to monitor database read and change actions, and can be enabled
and viewed from the Space Management area by selecting your space and going to the Auditing
tab. To get a complete overview, you'll need to enable logs for your spaces, set retention times, and
then access the Audit Log Viewer within your SAP BTP cockpit by subscribing to the service.

Uses of Audit Logs

Security Monitoring:Identify unusual or suspicious network and system behavior to detect potential
attacks or unauthorized access.

Compliance:Provide auditors with the necessary information to validate security policy enforcement
and ensure proper segregation of duties.

Troubleshooting:Assist IT staff with root-cause analysis following a security incident or other system-
related issues.

Data Integrity:Track data modifications and user actions to maintain the integrity of your data and
systems.

How to Check and View Audit Logs

1. Enable Audit Logs:

Navigate to Space Management in SAP Datasphere.

Select the space you want to audit.

Go to the Auditing tab for that space.

Check the boxes to Enable Audit Log for Read or Change Operations and set the retention time in
days.

2. Access the Audit Log Viewer:

Subscribe to the Audit Log Viewer service: in your SAP BTP Cockpit.

From the cockpit, you will be able to Go to Application to launch the viewer.

3. Review the Audit Logs:

Within the viewer, you can see a list of audit log entries.

You can filter by date and download the logs if needed.

Important Considerations

Disk Space: Be aware that audit logs can consume a significant amount of disk space, especially with
long retention periods.

Log Deletion: Administrators can delete audit logs to free up disk space when necessary.

Data Lake Objects: Statements executed via procedures for Data Lake objects are currently not
audited in SAP Datasphere.

Comparison of Graphical Views and Analytic Models:

Feature Graphical View Analytic Model

Primary Data preparation and transformation for a Targeted, multi-dimensional modeling for
purpose variety of semantic usages. analytical consumption in SAC.

Target user Data architects and engineers, as well as Data modelers and power users defining
business users for simpler tasks. complex analytical models.

User interface Visual, drag-and-drop environment. A dedicated editor that curates dimensions
and measures for analytical queries.

Level of Defines the base data logic at the Defines complex aggregation and business
abstraction individual row level. logic on top of base data.

Measure Uses simple, standard aggregation Provides advanced measure modeling,

definition functions. including calculated, restricted, and exception
 aggregations.

Hierarchy Creates dimension views with parent-child Incorporates pre-defined hierarchies from
support or level-based hierarchies as a base dimension views for user drill-down in
artifact. analytics.

End-user Primarily handles static filters and Uses variables and prompts for dynamic end-
interaction parameters at the view level. user input during analysis.

Data preview Basic preview showing data at each node, Rich analytical preview replicating SAC's data
primarily at a relational level. analyzer for aggregated, multi-dimensional
data.

Performance Supports run-time hints and persistency The analytical preview enables immediate
tuning options for the base view. testing and optimization of aggregation logic.

SAP datasphere how to enable delta capture manually:

In SAP Datasphere, you can enable delta capture for a

local table only during its initial creation, not manually after it has been deployed. The setting is
permanent once the table is deployed.

For remote tables or other data sources, the delta functionality is managed differently and depends
on the source system's capabilities.

Enabling Delta Capture During Local Table Creation

1. Navigate to the Data Builder: Access the Data Builder in the SAP Datasphere interface and
choose your space.

2. Create a New Table: Click "Create" and then select "Table".

3. Define Table Properties:

 Provide a business and technical name for your table.

 Add at least one key column, which is required for delta capture.

4. Enable Delta Capture: Find the "Delta Capture" toggle in the table creation panel and switch
it to "On".

5. Observe Auto-Generated Columns: Activating delta capture automatically adds two system-
managed columns to the table schema:

 CHANGE_TYPE: This column tracks change types (e.g., I for Insert, D for Delete, U for
Update).
  CHANGE_DATE: Records the timestamp of each change.

6. Deploy the Table: Deploy the table after defining it. The delta capture setting is now
permanent.

7. Populate the Table: Load data into the table. The CHANGE_TYPE and CHANGE_DATE columns
are automatically populated based on the data loading method (e.g., data flow, file upload,
or replication flow).

Alternatives for Other Data Sources

For delta capture from sources other than local tables, use these methods:

For Replication Flows (Recommended for SAP Sources)

If replicating data from a source system like SAP S/4HANA, the source system's capabilities typically
manage the delta mechanism. This includes Change Data Capture (CDC) based on CDS views.

1. Define a CDS View: The source CDS view in the ABAP system must be annotated
with @Analytics.dataExtraction.enabled: true and define a delta mechanism.

2. Create a Replication Flow: Create a new "Replication Flow" in the Datasphere Data Builder.

3. Select the Source: Select the connection to your SAP source system and the CDC-enabled
CDS view as the source object.

4. Configure Delta Load: Choose the "Initial and Delta" load type in the replication flow settings.
This automatically detects and replicates changes.

For Transformation Flows

Transformation flows can process data from delta-enabled local tables. This allows loading only
changed records into a new target table.

1. Create a Transformation Flow: Start a new transformation flow in the Data Builder.

2. Use a Delta-Enabled Local Table as Source: Drag and drop your local table with delta capture
enabled into the flow.

3. Set the Load Type: Select the "Initial and Delta" load type in the target table's properties. The
flow will use the CHANGE_DATE column to process new and changed records on subsequent
runs.

sap datasphere difference between associations and joins:

In SAP Datasphere, the primary difference between associations and joins is

their execution and purpose: a join is a physical, immediate data combination, while
an association defines a semantic relationship that triggers a "join on-demand" only when a
consumer requires the associated data. This difference significantly impacts performance, reusability,
and data modeling strategy.

Comparison of associations and joins in SAP Datasphere

Feature Associations Joins

Execution Lazy/On-demand. The actual join is only Immediate. Data from multiple sources is
executed at query runtime if a field from the immediately and permanently combined into
associated entity is explicitly requested by a a single new object based on the defined join
consuming application. conditions.

Purpose To define reusable, logical relationships To explicitly combine data from two or more
between entities without immediately sources for a specific data transformation or
combining data. This is ideal for modeling reporting scenario.
master-data relationships (e.g., product
dimensions and their attributes).

Reusability High. An association can be defined once on Low. Joins are specific to the view or data
a table or view and then used in any number flow where they are defined. If the same join
of views, data flows, or analytical models. is needed elsewhere, it must be re-created.

Performance Optimized. The "join on-demand" Can impact performance. Every time the view
functionality (or "join pruning") means that is accessed, the database executes the
associated tables are only queried when predefined join, regardless of which fields are
needed, improving performance for queries requested. This can lead to slower
that don't require the joined data. performance if many tables are joined but
not all are needed.

Use cases Semantic Modeling: Recommended for Data Integration: Combining data from
defining semantic relationships in the disparate sources within a Data Flow for a
Analytic Model and other consumption- one-time, specific transformation.
ready views. Creating a Flat View: Joining multiple tables
Master Data: Connecting fact data to to create a flat, denormalized view for a
dimension and text tables. specific report.

Configuration Defined by setting key columns and Configured within a Graphical View or Data
cardinality (e.g., 1:1, 1:n) in the associations Flow by dragging and dropping objects and
tab of a table or view. setting the join type and conditions.

Create an Association to Define a Semantic Relationship ...

Introduction to Associations. When you create a join in a view, you are immediately combining the
data from the two sources based on the definition of the join ...
When to use each in SAP Datasphere

Use Associations for:

 Modeling for Consumption: When building objects like an Analytic Model for reporting, use
associations to link dimension and text data to the central fact data.

 Performance Optimization: Use associations for tables with many potential lookups,
especially if not all of them are needed in every query. This ensures only necessary data is
retrieved.

 Master Data Relationships: For defining the relationships between transactional data and its
descriptive master data (e.g., sales data to product and customer information).

 Enabling Navigation: To allow end-users in reporting tools like SAP Analytics Cloud (SAC) to
navigate between related entities via path expressions.

Use Joins for:

 Data Transformation: In data flows, use joins to physically combine data from different
sources into a new target object before it is used for analysis.

 Flattening Data: When a single, flattened table is required for a specific purpose and the data
should be combined regardless of which columns are later queried.

 Non-Equi Joins: For complex join conditions that are not based on equality (e.g., joins using
greater than > or less than < operators).

 Static Views: When building data layer views for a downstream consumption model that
requires the sources to be fully combined ahead of time.

sap datasphere how can we show the replication related status in the sap analytics cloud:

You can show SAP Datasphere replication status in SAP Analytics Cloud (SAC)

by using a live data connection to a custom monitoring view in Datasphere. This method allows you
to build SAC stories that visualize the metadata related to your replication flows, providing a custom
dashboard for status monitoring.

Step 1: Create a monitoring view in SAP Datasphere

The standard monitoring tools in Datasphere are not natively exposed for SAC reporting. You must
build your own views on top of the system's metadata tables.
 1. Create a database user: A technical user with the necessary permissions is needed to access
the underlying SAP HANA database where Datasphere stores its monitoring tables.

2. Access the monitoring metadata: You will need to import the system tables that track the
replication process into your Datasphere space. The key tables are:

 REPLICATIONFLOW_RUN_DETAILS: This table contains metadata about each

replication flow run, including status, duration, and any errors.

 TASK_LOGS: Provides details on task management, which can offer a broader

overview of data integration tasks.

3. Build a model for consumption: Use the imported tables to create a graphical or SQL view. In
this view, you can:

 Join REPLICATIONFLOW_RUN_DETAILS with other relevant metadata tables.

 Create calculated columns to transform the raw data into more user-friendly status
metrics (e.g., categorizing run statuses as "Success," "Failure," or "Running").

 Define the output as an Analytic Model to make it ready for consumption by SAC.

Step 2: Connect SAP Analytics Cloud to the monitoring view

After deploying the monitoring view in Datasphere, you can establish a live connection from SAC.

1. Set up a live data connection: In SAC, create a new live data connection to your SAP
Datasphere tenant.

2. Create a story: Build a new SAC story using the live connection to the Analytic Model you
created in Datasphere.

3. Visualize the status: Add charts, tables, and numeric point widgets to your SAC story to
visualize the replication status metrics:

 Numeric Point: Show the total number of running or failed replication flows.

 Table: Display a detailed list of replication jobs, including status, start/end times, and
any error messages.

 Bar Chart: Show the number of replication flows by their current status (e.g., Active,
Failed, Completed).

Alternative: Use SAP Cloud ALM

For broader, enterprise-wide monitoring, you can integrate Datasphere with SAP Cloud ALM. This
provides a pre-configured, centralized dashboard for operations monitoring.

 Setup: Activate monitoring for Datasphere within your SAP Cloud ALM tenant.

 Benefits: While not as customizable as a self-built SAC story, Cloud ALM provides an
integrated overview of system health and includes metrics for Datasphere, reducing the need
for manual configuration of monitoring artifacts.

sap datasphere how can you analyze the data model performance:
You can analyze SAP Datasphere data model performance by using in-platform tools, standard
monitoring views, and advanced SQL techniques. SAP Datasphere runs on an SAP HANA Cloud
database, so HANA performance analysis tools are also applicable.

Using in-platform tools

Runtime Metrics in the Data Builder

The Runtime Metrics tool in the Data Builder is the starting point for analyzing a view's performance.

 What it does: Runs two benchmark queries on a view and provides metrics on their runtime
and memory consumption.

 How to use it:

1. Go to the Data Builder and open the view you want to analyze.

2. Click the Runtime Metrics icon in the toolbar.

3. Click Run to execute the performance analysis.

4. Run the tool again after making changes to see a comparison between the last two
runs.

 What you see: Key indicators include the number of sources, peak memory usage, execution
times for SELECT TOP 1000 and SELECT COUNT(*), and view persistence status.

View Analyzer in the Data Integration Monitor

For more detailed analysis, the View Analyzer provides persistence recommendations and the ability
to generate a query plan.

 What it does: Creates an overview of entities in your data model and suggests which views
are candidates for persistence to improve performance.

 How to use it:

1. Navigate to the Data Integration Monitor.

2. Select the view you want to analyze.

3. Choose the View Analyzer feature.

4. Options include a persistence simulation with or without memory consumption.

 Output: The analyzer provides a persistency score and a visual lineage showing where
persistence is recommended.

System Monitor

The System Monitor tracks overall tenant health, including expensive statements and queuing
events.

 What you see:

o Statements tab: Provides details on executed queries, including those tagged as

"expensive" for detailed analysis.
 o Admission Control Queuing Events: Shows if queries are being delayed due to high
system load.

 Prerequisite: Enabling "Expensive Statement Tracing" in the Configuration >

Monitoring settings is necessary to capture peak memory usage and CPU time.

Using standard monitoring views

You can query the underlying SAP HANA database monitoring views directly using a Database
Analysis User. This provides low-level insights that can be aggregated into a custom performance
dashboard.

Expensive statements

The M_EXPENSIVE_STATEMENTS table captures queries that exceed a specified time or memory
threshold. It records metrics such as CPU usage, runtime, and peak memory.

 Key insight: Identify the most resource-intensive queries and the data models they are
running on.

MDS statistics

The M_MULTIDIMENSIONAL_STATEMENT_STATISTICS table provides aggregated data on queries

originating from SAP Analytics Cloud (SAC), including runtime and peak memory.

 Key insight: If per-call capturing is enabled, you can see detailed performance data for
individual SAC requests, grouped by story and widget.

Using advanced techniques

Explain Plan

For in-depth analysis of a single query, you can generate an Explain Plan. This shows the query
execution flow and helps identify specific bottlenecks.

 How to generate:

1. Use the Runtime Metrics tool to generate the Explain Plan for a specific view.

2. Alternatively, you can get the SQL statement from the monitoring views and run a
PlanViz analysis in a tool like HANA Studio.

SQL code preview

For any data model, you can preview the generated SQL code. This helps you understand the
underlying database operations and manually debug or optimize the query.

 How to access:

1. Open a data model in the Data Builder.

2. Select Edit > Preview SQL.

Performance optimization best practices

After analyzing your data model's performance, consider these strategies for improvement:
  Persist complex views: Replicate data for complex or frequently accessed views instead of
relying on virtual modeling. Persisting data materializes the view, improving performance but
increasing storage.

 Filter early: Push filters down to the source systems to reduce the amount of data
transferred and processed.

 Optimize joins: Join on integer or key columns instead of string columns. Use associations for
dimension and text data to enable join pruning.

 Use layering: Use smaller, reusable views rather than monolithic ones. Structure your data
model into layers (e.g., inbound, harmonization, reporting) to simplify maintenance and
improve performance.

 Manage spaces: Use space management tools to prioritize resources for the most critical
workspaces.

sap datasphere in what scenario we use data flow and transformation flow

In SAP Datasphere, you use Data Flows for complex ETL (Extract, Transform, Load) scenarios and
Transformation Flows for simpler, view-based transformations, often as part of a larger ELT (Extract,
Load, Transform) process. The key difference lies in their transformation capabilities and how they
handle data persistence.

When to use a Data Flow

A Data Flow is a graphical ETL tool for building end-to-end data pipelines with a wide range of robust
operators. It is the right choice when you need more advanced, flexible, or custom processing
capabilities.

Use a Data Flow for scenarios such as:

 Complex data transformations: When your data requires extensive manipulation beyond
standard joins and filters. This can include multi-step operations like splitting a column,
replacing values, and then aggregating the data.

 Incorporating custom Python logic: For advanced analytics, data cleansing, or complex
calculations, you can use the Python Script operator. This allows you to leverage libraries like
Pandas and NumPy for powerful transformations within your data pipeline.

 Combining multiple source types: When you need to integrate data from various sources
(e.g., SAP tables, non-SAP databases, and flat files) into a single Datasphere table.

 Unioning data with similar structures: You can use a Data Flow's Union operator to combine
data from different sources with compatible schemas.

 Aggregating data: Use the Aggregation operator to summarize data, such as calculating the
total sales per product line.

When to use a Transformation Flow

A Transformation Flow is designed for more focused, SQL-based transformations that are either
based on a single source or simpler view logic. It is particularly useful for delta-based data loads.
Use a Transformation Flow for scenarios such as:

 Delta loads (Initial and Delta): This is a key advantage of Transformation Flows. You can
configure them to load the full data set initially and then automatically load only the
changed records on subsequent runs.

 Delta-enabled table transformations: Transformation Flows can take a single delta-enabled

table (created via a replication flow) and apply further transformations, such as a join with a
master data table.

 Simpler, SQL-based transformations: When your logic can be expressed clearly in a graphical
view or an SQL query, without needing a full-featured ETL pipeline. This is useful for building
data layers that perform simple consolidations or filtering.

 Targeting an SAP BW Bridge space: A Transformation Flow can be used to load transformed
data into local tables or remote tables within an SAP BW Bridge space.

 Persisting a complex view: If a graphical or SQL view is too complex or slow to be used
virtually, you can use a Transformation Flow to persist its results into a physical table for
better performance.

Summary of key differences

Feature Data Flow Transformation Flow

Complexity Designed for complex, multi-step ETL Best for simpler, view-based
pipelines. transformations.

Transformation Uses graphical operators (Join, Union, Uses graphical or SQL view transforms.
Logic Aggregation) and custom Python scripting.

Delta Loading Does not natively support delta capture Supports initial and delta loads for local
on the target table via the flow itself. tables with delta capture enabled.

Source Type Can integrate data from a wider variety of Primarily works with tables and views
SAP and non-SAP sources. within Datasphere, including remote tables
from BW Bridge.

Code Allows for advanced transformations using Uses SQL for custom logic within a
Customization the Python Script operator. transform, but no Python support.

Best For Heavy ETL jobs, complex data cleansing, Simple data loads, persisting view results,
and scripting. and delta-based integrations.
sap datasphere what is dp agent and when do you use:

In SAP Datasphere, the Data Provisioning (DP) Agent is

a lightweight, on-premise component that enables secure and direct connectivity to your local data
sources. It acts as a bridge, allowing your cloud-based SAP Datasphere instance to access and
integrate with data that resides behind your corporate firewall.

The DP Agent is part of the SAP HANA Smart Data Integration (SDI) framework and hosts adapters
that facilitate connections to various on-premise sources like SAP S/4HANA, Microsoft SQL Server,
Oracle, and more.

How the DP Agent is used

The DP Agent is essential for hybrid data landscapes, where you need to combine data from both
cloud and on-premise systems for analysis and reporting in SAP Datasphere. You would use the DP
Agent for the following scenarios:

 Remote tables: The agent allows you to create remote tables in Datasphere that mirror
tables in your on-premise systems. Data from the source is accessed on-demand, enabling
live, federated queries without permanent replication.

 Data replication and flows: For scenarios that require data transformation, the DP Agent
facilitates replication flows. This allows you to extract, transform, and load (ETL) data from
on-premise sources into Datasphere, either as a one-time process or on a scheduled basis.

 Real-time replication: The DP Agent enables real-time data streaming and change data
capture (CDC) from on-premise sources like Microsoft SQL Server and Oracle to SAP
Datasphere. This ensures that your cloud-based analytics are always working with the most
current data.

 Connecting to specific sources: You use the DP Agent to connect to systems like on-premise
SAP S/4HANA and SAP ECC. For other sources like SAP BW/4HANA, the DP Agent can be used
in combination with the SAP Cloud Connector for specific use cases like remote tables.

How the DP Agent works

1. Installation: The DP Agent is installed on a host within your corporate network that can
securely connect to both the on-premise data sources and the internet.

2. Registration: You register the DP Agent with your SAP Datasphere tenant through a
configuration process. The agent's external IP address must be added to the allowlist in
Datasphere for a secure connection.

3. Adapter hosting: The DP Agent hosts different data provisioning adapters for specific source
systems (e.g., ABAPAdapter, HanaAdapter, MssqlLogReaderAdapter). These adapters handle
the technical communication with the source databases.

4. Secure gateway: When Datasphere needs to access on-premise data, it sends requests to the
DP Agent, which then uses the appropriate adapter to communicate with the source system.
This creates a secure, controlled pathway for data transfer without exposing your internal
network.

sap datasphere different types of layers used in the datasphere

SAP Datasphere uses a layered architecture, a data modeling approach to organize data from
ingestion to consumption. The platform features two main tools, the Data Builder and Business
Builder, which correspond to the core Data Layer and Semantic Layer, respectively. Within the Data
Layer, best practices suggest further structuring data into logical layers like Inbound, Harmonization,
and Reporting.

The Data Layer

The Data Layer is the foundation where IT and data engineers acquire, transform, and prepare data
from various sources for the entire organization.

Key objects and sub-layers include:

 Ingestion (Source) layer: Raw data is brought into Datasphere using remote tables for virtual
access or data flows for replication and transformation.

 Inbound layer: This layer, sometimes overlapping with the ingestion layer, stores raw data,
essentially creating a mirror of the source system data.

 Harmonization layer: Here, the data is standardized, cleansed, and enhanced for consistency.
For example, currency conversions may be applied to transactional data in this layer.

 Propagation layer (optional): This optional layer can be used to further consolidate and
enrich datasets, feeding into the reporting layer.

 Corporate Memory Layer (optional): For long-term storage of historical transactional data, a
separate Corporate Memory Layer can be created to support historical analysis and machine
learning.

The Semantic Layer

Also known as the Business Layer, the Semantic Layer adds business context to the prepared data,
abstracting technical complexity for business users. Using the Business Builder tool (now largely
replaced by the Analytic Model in the Data Builder), this layer redefines and enriches technical
models with business-friendly terms.

Key features of this layer include:

 Business terms: Measures, dimensions, and hierarchies are given business names and
descriptions that are easily understood by non-technical users.

 Data abstractions: It hides the complex joins and technical details of the underlying Data
Layer models, providing a single, consistent view of the data.

 Consumption models: For business users, this layer provides a self-service environment for
creating highly focused, multi-dimensional models for analysis.

 Consumption (Reporting) layer: This final layer sits on top of the Data Layer to create
optimized views for reporting and analysis. It is designed for direct consumption by BI tools
like SAP Analytics Cloud.

The Catalog Layer

The Catalog in SAP Datasphere is a central repository that catalogs data and metadata from across
the data landscape.
  It provides a single, trusted source for discovering and understanding data assets.

 The Catalog promotes data governance by centralizing metadata, data lineage, and semantic
definitions.

Multi-Space Architecture and Layering

In practice, organizations often implement these layers across different "spaces" in Datasphere for
better organization and security. For example:

 A Central IT Space might contain the Inbound and Harmonization layers for corporate data.

 Different Departmental Spaces (e.g., Sales or Finance) would then consume and build upon
the harmonized data from the central space, developing their own Reporting layers.

 This approach, known as cross-space sharing, prevents data duplication and ensures
consistent data models.

sap datasphere what are data access controls

Data Access Controls (DACs) in SAP Datasphere are

the mechanisms used to implement row-level security on data. This ensures that users can only view
records that they are explicitly authorized to see, based on defined criteria. DACs are a crucial part of
an organization's data governance strategy, protecting sensitive information and maintaining
regulatory compliance.

The overall process involves three main components:

1. Permissions Entity: A table or view that defines which users have access to which data. It
typically contains a user ID column and one or more criteria columns, such
as SalesRegion or Department.

2. Data Access Control Object: An object that consumes the permissions entity and specifies
how its filtering criteria should be applied.

3. Data Views: The target views in your data model where the Data Access Control object is
applied. When a user queries a view with an attached DAC, the system filters the data
according to the rules defined in the permissions entity.

Types of Data Access Controls

SAP Datasphere supports several types of DACs to suit different security scenarios:

 Single Values: Filters data based on exact, individual matches in the permissions entity. For
example, a user may be given access to data where the SalesRegion column equals "EMEA".

 Operator and Values: Provides more complex filtering logic using boolean operators
like EQ (Equal to), GT (Greater than), BT (Between), or LIKE. This reduces the number of
permissions records needed, as an administrator can use a single row to define a range of
access.

 Hierarchy: Enforces security based on a hierarchical dimension, such as an organizational

chart. When a user is authorized for a specific hierarchy node, they automatically gain access
to all the node's descendants.
How data access controls work

A DAC is not a passive security layer—it actively joins your data with the permissions list to filter
results at query time.

1. Creation: An administrator creates a DAC object in the Data Builder, referencing a

permissions entity and defining the filtering criteria.

2. Application: The DAC is then applied to a data layer view. The administrator maps the criteria
columns in the DAC to the corresponding columns in the view.

3. Consumption: When a user with the necessary permissions queries the view (e.g., in an SAP
Analytics Cloud story), the Datasphere query engine filters the result set to show only the
rows matching the user's authorizations.

Best practices and limitations

 Segregate permissions: A common approach is to manage the permissions entity in a

separate space that is shared with the space where the DAC is defined. This allows business
users to maintain access rules without needing to be in the technical development space.

 Consider performance: While applying a DAC as early as possible in the data flow can
improve performance by filtering records early, applying multiple DACs to a complex view
can have the opposite effect. It is generally best to apply a single, targeted DAC to a
combined view.

 Note persistence limitations: A view that consumes another view with an applied DAC
cannot be persisted (stored as a snapshot). This can impact performance for subsequent
transformations and queries.

 DAC vs. Space roles: Datasphere also uses space-level roles to control high-level access to
artifacts (tables, views, etc.). DACs, by contrast, are used for granular, row-level security
within those artifacts.

sap datasphere What is content sharing

In SAP Datasphere, content sharing is

the process of distributing and exchanging data and analytical assets with different users, teams, and
systems. It enables a business data fabric architecture that unifies data access and promotes self-
service data consumption, while ensuring governance and security.

Key mechanisms for content sharing in SAP Datasphere include:

 The Data Marketplace: A central hub where users can discover and acquire pre-packaged
data products offered by internal teams, SAP, and third-party data providers.

o Data providers can list, manage, and monetize their data products.

o Consumers can browse and install data products into their SAP Datasphere spaces.

o Marketplaces can be public (visible to all consumers), private (invite-only), or internal

(restricted to specific tenants).

 The Content Network: A feature that allows you to import, export, and share content
packages across different SAP Datasphere tenants.
 o Transfer content: Facilitates the movement of content, such as tables, views, and
data models, between development, quality assurance, and production systems
without manual file transfers.

o Access pre-built content: Provides access to a library of pre-configured business

content from SAP and its partners, which can accelerate project implementation.

 Sharing within a single tenant: A secure method for sharing data assets between different
spaces within the same SAP Datasphere tenant.

o Space-to-space sharing: Enables teams to share data entities and other objects from
their designated space with other teams for collaborative projects.

o Access control: Ensures that sharing is governed by explicit permissions to maintain

security.

Benefits of content sharing in SAP Datasphere

 Centralized access to trusted data: The Data Marketplace provides a single point for
discovering data products and ensuring that all data consumers are using governed,
authoritative data.

 Accelerated time to value: Accessing pre-built business content from the Content Network
allows organizations to jump-start projects and leverage proven, best-practice data models.

 Enhanced governance: Content sharing mechanisms are built with security and control in
mind, ensuring that data is accessed and used according to defined policies.

 Democratization of data: By making data easily discoverable and accessible through a

centralized marketplace, content sharing allows more users across the organization to use
and create with data.

 Simplified data landscape: A business data fabric architecture, enabled by content sharing,
provides seamless access to data across hybrid and multi-cloud environments without
creating unnecessary data duplicates.

What are the key characteristics of SAP Datasphere?

There are four correct answers.

Collaboration: Enablement of both enterprise IT users and line of business users

Performance: Leverage the power of SAP HANA Cloud

End-to-end Integration: Consumption of data from any source in SAP Analytics Cloud

Elasticity: A 'pay for what you use' concept

Variables: Analytic Model-Standard Variable,Restricted Measure Variable,Filter Variable,Reference

Date Variable

Measures:Calculated measure,Restricted Measure,Count Distinct Measure,Currency Conversion

Measure,Non-Cumulative Measure.
Dimensions Association:Association/Hierarchy Association/Hierarchy with directory Association/Text
Association

Table functions & Stored Procedures:

In SAP BW/4HANA, a table function is typically used to leverage the WORKDAYS_BETWEEN SQL
function within a graphical calculation view, since the graphical editor does not directly support it.

Scenario: Calculating delivery lead time

A company wants to analyze the efficiency of its logistics department by calculating the number of
working days between the order date and the shipping date for a list of sales orders. The calculation
needs to exclude weekends and holidays defined in the company's factory calendar(TFACS table).

Solution architecture

The solution involves two main objects:

 A Table Function to encapsulate the WORKDAYS_BETWEEN logic using SQL Script.

 A Graphical Calculation View that uses the table function to enrich the sales order data with
the calculated delivery lead time.

 Step 1: Create the table function

 Create a new Table Function in your HANA development
environment. This function will take the start date, end date, and
factory calendar ID as input, and return the number of working
days.
 sql
 FUNCTION "MY_SCHEMA"."TF_CALC_WORKDAYS_BETWEEN" (
 IN iv_factory_calendar_id NVARCHAR(2),
 IN iv_start_date DATE,
 IN iv_end_date DATE
 )
 RETURNS TABLE (
 WORKDAYS_COUNT INTEGER
 )
 LANGUAGE SQLSCRIPT
 READS SQL DATA AS
 BEGIN
 RETURN
 SELECT
 WORKDAYS_BETWEEN(
 :iv_factory_calendar_id,
 :iv_start_date,
 :iv_end_date,
 'SAPABAP1' -- Schema where TFACS table is located
  ) AS WORKDAYS_COUNT
 FROM DUMMY;
 END;
 Note: The TFACS table must exist in the specified schema. For
BW/4HANA systems, this is typically the ABAP schema SAPABAP1 .
Step 2: Create the graphical calculation view
Follow these steps to create a calculation view that utilizes the table
function:
1. Create the view: In your BW/4HANA project, create a new graphical
Calculation View.
2. Add a projection node: Add a Projection node and select your source
data. For this example, let's assume a DataStore Object
(advanced) /BIC/ADSO_ORDERS with ORDER_DATE and SHIPPED_DA
TE fields.
3. Add the table function node: Drag and drop a Table Function node
from the palette and add your new
function TF_CALC_WORKDAYS_BETWEEN.
4. Map the inputs:
1. Connect the Projection node to the Table Function node.
2. In the Input Mapping tab of the table function node, map the
input parameters:
o Map the ORDER_DATE from the projection
to iv_start_date.
o Map the SHIPPED_DATE from the projection
to iv_end_date.
o Create a Constant for iv_factory_calendar_id (e.g., 'US').
5. Join the nodes: Use a Join node to combine the original data from
the ADSO_ORDERS with the output of the table function
(WORKDAYS_COUNT).
6. Create the aggregation: Add an Aggregation node to define the final
output, including the WORKDAYS_COUNT measure and any other
dimensions from your sales order data.
7. Propagate and activate: Propagate the necessary fields to
the Semantics node and activate the calculation view.

Stored Procedures:

SAP BW/4 hana calculation view when to use a stored procedure with a
scenario
A stored procedure is used within an SAP BW/4HANA calculation view
when you need to execute complex business logic that goes beyond the
capabilities of graphical modeling. You embed the stored procedure in a
"scripted" calculation view or, more commonly, within a Table Function
that is then consumed by a graphical calculation view.

Scenario: Complex, multi-step financial calculations

Business requirement: A finance team needs a real-time report on a
custom "Net Revenue" metric that requires a series of calculations and
temporary storage of intermediate results. The logic involves:
1. Fetching sales data from an Advanced DataStore Object (ADSO).
2. Calculating several intermediate key figures, such as "Gross Sales"
and "Total Discounts," for each transaction.
3. Applying a dynamic currency conversion based on the exchange
rate on the transaction date, not the reporting date.
4. Incorporating data from an external table containing adjustment
factors.
5. Applying complex, nested conditional logic and ranking functions to
filter out certain outlier transactions.
6. Finally, calculating the aggregated "Net Revenue" for reporting.

Why a stored procedure is needed

While a graphical calculation view can handle many steps, this scenario
requires a procedural approach to manage the multi-step, iterative logic
efficiently.
 Sequential logic: A graphical view executes in a single, parallelized
query. A stored procedure allows you to execute SQL statements
sequentially, with the output of one step serving as the input for the
next.
 Temporary tables: A stored procedure can create and populate
temporary tables to store the results of intermediate calculations.
This prevents you from nesting complex logic into a single massive
query.
 Performance optimization: Performing the entire process within a
single stored procedure on the SAP HANA database minimizes the
number of data transfers between the database and the application
layer.
  Custom functions: The complex business rules, like the currency
conversion based on a dynamic date, are best implemented with the
procedural features of SQLScript, which can be wrapped inside a
stored procedure.
Solution approach using a stored procedure
1. Create the Stored Procedure: Develop a stored procedure in
SQLScript that contains the full calculation logic.
 It begins by fetching data from the ADSO.
 It uses variables and temporary tables (#TEMP_SALES) to
store intermediate results.
 It performs the dynamic currency conversion and applies the
adjustment factors.
 It executes the complex ranking and filtering logic.
 It returns the final, aggregated dataset as a table-type output
parameter.
2. Create a Table Function: Wrap the stored procedure call inside a
Table Function. Since graphical calculation views cannot directly
consume stored procedures, a Table Function acts as a bridge. The
Table Function simply calls the procedure and returns its output.
sql
FUNCTION "MY_SCHEMA"."TF_CALCULATE_NET_REVENUE" ( )
RETURNS "MY_SCHEMA"."TT_NET_REVENUE"
AS BEGIN
CALL "MY_SCHEMA"."SP_CALCULATE_NET_REVENUE" ( LT_RESULT
=> :LT_RESULT );
RETURN :LT_RESULT;
END;
Use code with caution.
3. Consume in a Graphical Calculation View:
 Create a graphical calculation view in your BW/4HANA
modeling environment.
 Add a "Projection" node and select the Table Function
(TF_CALCULATE_NET_REVENUE) as the source.
 You can then build additional graphical logic on top of the
Table Function's output, such as joins with other master data,
further aggregations, or input parameters for the BW Query.
  This hybrid approach combines the performance of SQLScript
with the flexibility and reporting metadata of the graphical
calculation view.

Difference between Table Function Vs Stored Procedure:

ey Differences Summarized:
Feature Table Function (in Stored Procedure
Calculation View)

Purpose Data retrieval, reporting Complex logic, data manipulation,

reusability

Data Read-only (SELECT) Can perform DML (INSERT,

Manipulation UPDATE, DELETE)

Return Value Always returns a tabular Can return scalar values, tables,
result set or no value

Consumption Direct consumption in Called by applications, services, or

graphical Calculation Views other procedures

Usage in Used to define the logic for Used for data preparation,
BW/4HANA SQL Scripted Calculation transformation, or specific
Views business processes

Difference between Scalar Function Vs Table Function:

A scalar function returns a single, elementary (scalar) value. This value

can be of a standard data type like integer, decimal, string, or date.
They are typically used in the SELECT list or WHERE clause of
a SELECT statement, much like built-in functions (e.g., SUM(), AVG()).
eg., A function that takes an amount and a tax rate as input and returns
the calculated tax amount.

A tabular function returns a table, which is a set of rows and columns.

They are used in the FROM clause of a SELECT statement, acting like a
virtual table or view.
Tabular functions are ideal for encapsulating complex data retrieval or
manipulation logic that results in a dataset. This can involve joining
multiple tables, applying filters, or performing aggregations to produce a
structured output.
eg., A function that takes a date range as input and returns a table
containing all sales orders within that period, including details like
customer information and total order value.

Datasphere: Currency Conversion:

To perform currency conversion,the tables(TCURV-exchange Rate Type,TCURW-exchange Rate Type

text,TCURX-Decimal places in currencies,TCURN-Quotations,TCURR-Exchange Rates,TCURF-
Conversion Factors,TCURC-Currency Codes,TCURT-Currency Text)must be available in the space.

Data Builder ---Currency Conversion Views -select source(S/4 HANA system or manual)-create -It will
create tables,views and data flows automatically- Run the 8 data flow manually or add all the 8 steps
in the task chain and run.

https://www.youtube.com/watch?v=Y2udOzBh4mE

Task Chains:

Automation and Scheduling:Task chains group multiple tasks, allowing you to run them manually or
set them on a periodic schedule for automated execution.

Data Flow and Replication Execution:You can include tasks to execute Data Flows, Transformation
Flows, and Remote Table Replication as steps within a task chain.

View Persistency Management:Task chains can be used to create or refresh the persistency of
views.

Open SQL Procedure Integration:They can run Open SQL schema procedures, integrating custom
database logic into your data processes.

Parallel Task Execution:You can add tasks to a task chain to run them in parallel, allowing for
simultaneous processing and reducing overall execution time.

REST API Interaction:Newer capabilities allow task chains to include a REST API task, enabling direct
interaction with external systems and services through REST APIs.

Email Notifications:Configure email notifications to be sent upon successful completion or failure of

the entire task chain, ensuring awareness of process status.

Error Handling:Task chains can be configured to stop processing if a task fails, protecting data
integrity by preventing subsequent tasks from running on incomplete data.

Nesting Task Chains:You can nest task chains within other task chains, creating hierarchical "meta
chains" that combine complex processes into a single, manageable unit.

Intelligent Lookup:
SAP Datasphere's Intelligent Lookup uses a combination of fuzzy matching and rules-based
automation to harmonize and merge data from disparate sources, even when they lack common
identifiers or contain inconsistencies. It excels at combining internal datasets with external data,
handling issues like case sensitivity, typos, and extra characters, to simplify data integration and
improve data quality for analytics and business intelligence.

Harmonizing Data:It blends internal and external datasets that may not have a common unique key.

Handling Data Inconsistencies:It effectively combines data from heterogeneous systems despite
inconsistencies such as:

Spelling errors and typos

Case sensitivity differences

Extra characters or spaces

Automated Data Matching:It uses intelligent rules to create mappings and automates the process,
reducing manual effort.

Fuzzy Matching:The core technology allows for matches based on a similarity percentage rather than
exact values, enabling the connection of similar but not identical records.

Interactive Environment:Provides a visual interface for users to review and confirm proposed
matches, with mapping rules needing to be created only once.

Integration with SAP Datasphere:The harmonized results are standard entities that can be leveraged
by other models and consuming tools within SAP Datasphere.

Business Data Fabric Foundation:It forms a cornerstone for a Business Data Fabric, connecting data
from different business contexts to simplify the overall data landscape.

In essence, Intelligent Lookup simplifies the complex task of joining and integrating data, allowing
users to connect and analyze datasets that were previously difficult or impossible to combine using
traditional join methods.

Eg., Imagine you have a view containing 20k electric vehicle charging points across the country,but it
lacks accurate location names.Use fuzzy rule to match charging points with location information.

Databuilder-Intelligent Lookup – Input entity(table or view you want to enrich)-Identify the pairing
column(usually a unique identifier)that links individual objects between the input objects and lookup
table-Define the rules for matching records based on your business requirements.

Entity Relationship Model: https://www.youtube.com/watch?v=XTSxhKLadwM&t=5s

An SAP Datasphere Entity Relationship (ER) Model scenario involves creating a visual representation
of your data structure, where tables and views act as entities, and you define the relationships (joins)
between them to form a coherent data model.

Scenario: Retail sales analysis using an Entity-Relationship (ER) model in SAP Datasphere

In this scenario, a retail company needs to build a data model to analyze its online sales
performance. The company wants to answer questions like:

 Which products are best-sellers in a given region?

  Who are our most valuable customers?

 What is the total revenue per month?

To achieve this, a data engineer in SAP Datasphere will create an ER model to structure the data,
define relationships between entities, and enable downstream analysis.

1. Identify entities

The first step is to identify the core business objects or entities involved in the online retail process.
These will typically be represented as tables or views in the data model.

 Customer: An entity representing the buyers.

o Attributes: Customer ID (primary key), Name, Email, Country, Registration Date.

 Product: An entity representing the items being sold.

o Attributes: Product ID (primary key), Name, Category, Price.

 Order: An entity representing each transaction.

o Attributes: Order ID (primary key), Customer ID (foreign key), Order Date, Status.

 OrderProduct: An intermediate entity (or junction table) to handle the many-to-many

relationship between orders and products. A single order can contain many products, and a
single product can be in many orders.

o Attributes: Order ID (foreign key), Product ID (foreign key), Quantity, Line Item Price.

2. Define relationships

Next, the data engineer establishes the associations between these entities in the ER model to
reflect the business rules.

 Customer to Order (One-to-Many): A single customer can place multiple orders, but each
order is associated with only one customer.

 Order to OrderProduct (One-to-Many): A single order can contain many line items
(products), but each line item belongs to only one order.

 Product to OrderProduct (One-to-Many): A single product can be included in many line items
across different orders.

3. Build and deploy the ER model in SAP Datasphere

1. Ingest data: The data engineer imports the necessary tables from source systems (e.g., SAP
ERP) or external files (like a CSV for product data) into SAP Datasphere using the Data Builder.

2. Create the ER model: A new ER model is created in the Data Builder. The data engineer then
drags and drops the imported tables (Customer, Product, Order) and potentially a new table
for OrderProduct onto the canvas.

3. Create associations: The data engineer graphically links the tables together based on the
defined relationships and cardinality (e.g., 1-to-many).
 4. Enrich the model (Optional): Additional information can be added, such as business names,
semantic usage types (like dimensions and facts), and hierarchies.

5. Deploy: The entire model is saved and deployed with a single action, making the
relationships available for subsequent data modeling and consumption.

4. Consume the ER model in a graphical view

With the ER model deployed, data consumers can easily build reports.

1. Create a graphical view: In the Data Builder, a business user creates a new graphical view.

2. Add a source: The user drags the Order table (the fact table) onto the canvas.

3. Leverage associations: The user can then click the + icon on the Order table to automatically
add the associated Customer and Product tables from the ER model. This eliminates the
need to manually define the joins.

4. Build calculations: Measures like Total Revenue (calculated from Quantity * Line Item Price)
can be created in the view.

5. Enable analysis: The resulting view can then be used in SAP Analytics Cloud for creating
dashboards and stories, allowing business users to analyze sales data based on any
combination of attributes from the customer, product, and order entities.

Variables and Input Parameters:

Variables are primarily for filtering, while input parameters are for dynamic calculations and more
advanced logic.Variables are bound to attributes; input parameters are more flexible and can be used
in various expressions.Variables filter at the semantic node; input parameters can be applied at any
projection level.

Input parameters, by applying conditions earlier, can sometimes lead to better performance by
reducing the data set earlier in the processing chain.Dynamic date calculation (e.g., filtering for the
last month's data)

 Create two input parameters:

IP_DATE_FROM: Type Direct, semantic type Date, with a default value expression
like ADD_MONTHS(date(now()), -1).

IP_DATE_TO: Type Direct, semantic type Date, with a default value expression like date(now()).

Use them in a filter expression: Filter a date column using the BETWEEN operator: Date_Column
BETWEEN '$$IP_DATE_FROM$$' AND '$$IP_DATE_TO$$'

 Create an input parameter:

Name it IP_DISCOUNT_RATE.

Set its type to Direct.

Specify the appropriate numeric data type and scale.

Use it in a calculated column: Define a calculated column (e.g.,

"Discounted Revenue") with an expression like Revenue * (1 - '$
$IP_DISCOUNT_RATE$$') .

SAP BW bridge: This component (optional) creates a data staging layer

specifically for supporting SAP S/4HANA ODP extractors. This is mainly for
the existing SAP BW and BW/4HANA customers to enable a path towards
conversion with SAP Datasphere, BW bridge, or Hybrid use case

SAP Landscape Transformation Replication Server (SLT): This

server replicates tables from SAP S/4HANA to the SAP Datasphere and can
be integrated into your Replication Flow.

Recommended option is ABAP CDS Views: If the ABAP CDS is

available with the desired data needs then establish a direct connection
between SAP Datasphere and the source system. Recommend to
use released CDS views as they are upgrade stable.

 @AbapCatalog.sqlViewName: 'CUSTOMER': After activation,

the CUSTOMER CDS database view is created in the ABAP
Dictionary.

 @Analytics.data Category: Dimension,Fact,Cube

 @AccessControl.authorizationCheck: #NOT_REQUIRED: There is no

access control required to retrieve the selected data from the
database.

 @Analytics for business intelligence

 @Metadata.allowExtensions: true: Allows you or other developers to

overwrite or add annotations in a metadata extension.

 @Consumption for user interfaces and value help

 @OData for Fiori apps

 VDM.viewType: #BASIC, #COMPOSITE, #CONSUMPTION. At its core,

the VDM is SAP’s “semantic layer” in S/4HANA, an abstraction built
entirely with ABAP Core Data Services (CDS) views. Instead of
 writing queries against raw tables (for example, VBAK or VBAP),
you consume meaningful business entities such
as SalesOrder or BillingDocument for example.

Recommended DATASPHERE integration with S/4 CDS views:

SAP S/4HANA Connection Supported SAP

Datasphere Integration Features:

SAP BW bridge: This component (optional) creates a data staging layer specifically for supporting SAP
S/4HANA ODP extractors. This is mainly for the existing SAP BW and BW/4HANA customers to enable
a path towards conversion with SAP Datasphere, BW bridge, or Hybrid use case
SAP Landscape Transformation Replication Server (SLT): This server replicates tables from SAP
S/4HANA to the SAP Datasphere and can be integrated into your Replication Flow.

SAP Datasphere is a unified service for data integration, cataloging, semantic modeling, data
warehousing, and virtualizing workloads across all your data.

Spaces, as part of the SAP Datasphere solution, are virtual (team/project/department) environments
where your administrator can assign users, add source system connections, and allocate memory and
storage.All data acquisition, preparation, and modeling in SAP Datasphere happens inside spaces. A
space is a secure area. Space data cannot be accessed outside the space unless it is shared to
another space or exposed for consumption. Therefore all data related workflows in SAP Datasphere
start with the selection of a space.

Data Ingestion methods:Replication Flow - Persisting Data

Data Flow - Persisting Data

Remote Table Access – Federated Data

CSV Files Import - Uploading Data