Accessing Data Directly from Remote Sources

Objective

After completing this lesson, you will be able to describe how to access data remotely.

Virtual Scenario for Transactional Data

Scenario: Using a BW Query in an Analysis for Office Workbook to access remote data

Across the lessons of this unit, a data flow has been described. The purpose of the data flow is to load transaction data from SAP S/4HANA into SAP BW/4HANA. The loaded data is permanently stored in DataStore Objects (advanced) (for transaction data) and characteristic InfoObjects (for master data). This data is available to BW Queries.

As well as querying data that has been loaded to SAP BW/4HANA, it is also possible to build BW Queries on data that is stored remotely in the original source systems. In this case we do not need to load the data. We can build BW Queries directly on the remote data. This is sometimes referred to as a virtual data scenario.

These two virtual data scenarios are explained in this lesson:

  • Combine the loaded and stored actual transactional sales data with plan sales data that is stored in an SAP HANA database table. The data in the remote table is provided to SAP BW/4HANA using an Open ODS View.
  • Combine the loaded and stored actual transactional sales data with CO2 footprint data provided by an SAP HANA calculation view.

Combine loaded and stored actual transactional sales data with plan sales data from an SAP HANA table

The actual product sales quantities have been loaded from SAP S/4HANA to SAP BW/4HANA and is stored in a Standard DataStore Object. The plan sales quantity is stored in an SAP HANA database table. The plan data in the SAP HANA table looks like this:

Screenshot of a Power BI table showing 71 rows of 2020 product plans with Product ID, CalYear, Planned Quantity, and Unit (EA) in Raw Data.

Instead of setting up a data flow to physically load the plan data to SAP BW/4HANA, a different approach is used:

Firstly, an Open ODS View is defined. This object is created in SAP BW/4HANA and reads the plan quantity in a remote SAP HANA table.

In the next step, a CompositeProvider is defined to combine the actual sales data, which is stored in the Standard DataStore Object, and the plan data which is read at run-time from the remote database table using an Open ODS View. We will define a union of the providers so that for each product we will have the actual and plan quantity.

We then create a BW Query on top of the CompositeProvider and finally display the results in Analysis for Microsoft Office. The report should look like this:

Screenshot of a spreadsheet dashboard showing product categories, weights, planned versus sold quantities, and variance percentages across hardware, computers, servers, and accessories items for planning.

So let's look at the data flow one more time to notice the objects for this scenario.

Diagram illustrates SAP BW/4HANA architecture: BW Queries, CompositeProviders, DataStore Objects, Transformations, DataSources, Data Transfer Processes, ODS View, ABAP CDS View, SAP HANA tables and views.

Using an Open ODS View

The first step is to create an Open ODS View in SAP BW/4HANA on top of the SAP HANA table.

Flow diagram shows SAP BW/4HANA architecture: BW Query, CompositeProvider, DataStore Objects, Transformations, DataSource; data opened in ODS View; ABAP CDS view; HANA table and view.

Open ODS View: terminology and use cases

An Open ODS View is an SAP BW/4HANA object that exposes remote source data to SAP BW/4HANA without the need to create InfoObjects and without loading and storing data.

Open ODS Views enable you to define data models based on database tables and database views that are located in remote databases. These data models allow flexible integration without the need to create InfoObjects and without the need to load the data into SAP BW/4HANA. This flexible type of data integration makes it possible to consume external data in SAP BW/4HANA without staging, and afterward, using a CompositeProvider, to combine these external data with other SAP BW/4HANA models.

Open ODS View: system settings

Screenshot of modeling interface: left pane lists source fields (Product ID, Calendar, Planned Quantity, Unit); right pane shows view fields, keys, and figures for planning.

In our scenario the Open ODS View is created based on the plan data table in SAP HANA .

CompositeProvider

A CompositeProvider represents the virtual layer of SAP BW/4HANA.

Architecture diagram of BW/4HANA flow: BW Queries, CompositeProvider, DataStore Objects, Transformations, DataSources, Open ODS View, ABAP CDS View, tables calculation views in SAP HANA today

CompositeProvider: system settings

Our CompositeProvider has two providers: the Standard DataStore Object that contains the actual data and the Open ODS View that exposes the plan data.

Data-mapping interface screenshot showing a source model on left and target fields on right, with connectors mapping calendar year, product, quantities, and amounts across datasets.

In our scenario we create a CompositeProvider to generate a union of the actual and plan sales data.

BW Query

A BW Query is defined on top of the CompositeProvider.

Diagram of SAP BW/4HANA data flow supporting Analysis for Microsoft Office, displaying BW Query, CompositeProvider, DataStore Objects, Transformations, DataSources, ODS View, and SAP HANA views.

BW Query: system settings

Two screenshots of an EPM query designer: left shows filters (Calendar Year 2020, Product ID); right lists columns (Planned/Sold Quantity, diff, variance) and ID rows.

In our scenario the BW Query selects Sold Quantity from the Standard DataStore Object and Planned Quantity from the Open ODS View. Two additional formulas are also defined in the BW Query: Diff. Sold - Planned and % Variance Sold/Planned.

Combine loaded and stored actual transactional sales data with CO2 footprint data from an SAP HANA calculation view

In another scenario we combine data relating to the CO2 footprint of each product with the actual sales data to generate the total CO2 footprint for each sale. The CO2 footprint data is provided by an SAP HANA calculation view and the actual sales data again comes from the Standard DataStore Object.

The CO2 footprint data provided by the SAP HANA calculation view looks like this:

Screenshot of a table showing Sl No., Product_ID_(EPM_Demo), KG_CO2_e, and SUM_CO2_Footprint for various items with CO2 values in kilograms across a table spanning dozen entries.

To set up this scenario, another CompositeProvider is created to combine the Standard DataStore Object which stores the actual sales data and the SAP HANA calculation view. The results of a BW Query, defined on top of this CompositeProvider, are then displayed in Analysis for Microsoft Office. The final result should look like this:

A blue spreadsheet displays product categories, gross weight, amounts, quantities, and CO2 footprints; items include USB drives, keyboards, mice, speakers, screens, and software details listed.

So let's look at the data flow to notice the objects for this scenario.

Architecture diagram shows SAP BW/4HANA data flow: BW Queries, CompositeProviders, DataStore Objects, DataTransfer Processes, Transformations, DataSources, Open ODS View, ABAP CDS Views, and calculation view.

CompositeProvider

We define a CompositeProvider to combine the Standard DataStore Object with the SAP HANA calculation view.

Diagram depicts SAP BW/4HANA data flow: BW Queries and CompositeProviders feeding DataStore Objects, Transformations, and DataSources, connected to ABAP CDS Views and HANA calculation views.

CompositeProvider: system settings

ETL mapping interface showing a scenario with left outer join, source and target panels; fields from product, calendar, currency, and quantity connected by data links.

In our CompositeProvider we define a Left Outer Join between the Standard DataStore Object and the SAP HANA calculation view.

Note

We use a left outer join to ensure that if the CO2 data is missing for a product, we will still display the sales data. An inner join would not return the sale data if CO2 data was missing.

BW Query

A BW Query is defined on the CompositeProvider.

Architecture diagram of SAP BW/4HANA data flow: sources to DataStore Objects, transformations, Open ODS and CDS views; CompositeProviders, BW queries, tables, calculation views for reporting.

BW Query: system settings

Two-panel interface: left shows filters for P_V_SO_3_Q1, including Calendar Year 2020; right shows sheet definition with key figures and Product ID (EPM Demo) CO2 Footprint.

In the BW Query Gross Amount and Quantity are selected from the Standard DataStore Object and the key figure CO2 Footprint (Each) is selected from the SAP HANA calculation view. Also a formula is defined, CO2 Footprint (Total), which calculates the total CO2 Footprint when the BW Query is executed.