Describing the data Provisioning scenarios


After completing this lesson, you will be able to:

  • Describe data Provisioning scenarios


Suppose you work for a company that sells goods to customers. You have recorded transactional data for all sales orders, and master data for all customers in different sources. You want to combine them, then aggregate the sum of all order amounts in the enterprise's currency and all quantities per customer and display each customer with its name. Following the data integration scenario using SAP Business Warehouse Bridge, you wonder what type of objects you have to create.

SAP Business Warehouse Bridge uses the same objects that you may already know from SAP BW/4HANA. If not, please see the following video to learn the required terminology.

Note that SAP Business Warehouse Bridge is mainly used for physical data storage. Instead of using the SAP BW/4HANA federation options in SAP Business Warehouse Bridge, you instead use the federation options in the SAP Datasphere core tenant. Therefore, the following SAP BW/4HANA object types are rarely used or cannot be used directly:

  • An Open ODS view accesses data from an external source or BW object. It cannot be defined in SAP BW bridge.
  • A BAdI Provider processes ABAP code at runtime. It cannot be defined in SAP BW bridge.
  • An InfoSource allows splitting a transformation into parts that are executed in sequence. It can be defined.
  • A Semantic Group is a collection of ADSOs (advanced DataStore Objects) that are combined in one CompositeProvider. It can be defined.
  • A BW Query is a predefined choice of filter values, columns, and rows for data Analysis, which can be changed at runtime. I can exist, but can only be used as a source object for model transfer with certain limits, for example a query with two structures cannot be transferred to a datasphere view.

So, you mainly maintain InfoObjects to manage master data and ADSOs for transactional data. In this course, you will see a data acquisition scenario.

In SAP Datasphere core tenant, there are other objects with similar purpose. Take a look at the following slide to see the object types.

The figure compares the BW Bridge obects with SAP Datasphere objects: Datasource is similar to Remote Table. low level DTP is similar to Data Flow or Replication Flow. InfoObject and ADSO is similar to Local Table. Transformation is similar to Intelligent lookup / SQL view. higher level DTP is similar to transformation flow. Ptocess chain is similar to Task Chain. CompositeProvider is similar to Graphical View. BW Query is similar to Analytic Model

Before we start creating these objects, let's consider in more detail how the data is delivered from SAP sources.

Data Provisioning Scenarios

The image shows the two tenants, SAP Datasphere BW Bridge and SAP Datasphere core tenant next to each other as possibe targets for a source. Under each box, the sources that are possible for this tenant are listed. For SAP BW Bridge, it is operational data provisioning (ODP), but other types of sources that you might know for SAP BW/4HANA , such as File, Big Data, HANA_LOCAL and HANA_SDA are not supported. For the core tenant, cloud sources, file sources, big Data sources, SAP HANA, smart data access, and SAP ODP sources are available

As you have seen, data integration can be achieved in SAP BW Bridge or in SAP Datasphere core tenant. So, which option should you use? SAP BW Bridge only supports on-premise, ODP-based DataSources. Even if direct connections to SAP BW Bridge using ODP_HANA and ODP_BW are theoretical options, SAP Datasphere core tenant offers better integration options for these cases.

Therefore, the following sources must or should connect with SAP Datasphere core tenant without SAP BW Bridge:

  • Flat files, database tables including SAP HANA on-premise or SAP HANA cloud, big data sources(data lakes), and other non-SAP sources use corresponding suitable SDI adapters.
  • SAP BW and SAP BW/4HANA InfoProviders should connect to SAP Datasphere core tenant using SAP BW connection (based on SDI ABAP) and SAP BW/4HANA model transfer.
  • Many cloud solutions use the SDI Cloud Data Integration (CDI) Adapter connection type .

But, if you extract from SAP Business Suite (ERP, CRM, SCM, SRM), SAP S/4HANA on-premise, or SAP S/4HANA cloud, you have the choice between different options:

Both SAP Datasphere BW Bridge (via ODP Data Sources) and SAP Datasphere core tenant (via SDI connections) are possible targets of source types SAP S/4HANA and SAP Business Suite (ERP, CRM, SRM, SCM). The question is: To bridge or not to bridge?
  • The SAP ECC connection type of SAP Datasphere core tenant refers, amongst others, to the S-API extractors of classic on-premise SAP Business Suite systems. Technically, it is based on the ABAP Adapter within SAP HANA Smart Data Integration (SDI).
  • The SAP S/4HANA On-Premise connection type of SAP Datasphere core tenant refers to the released S-API extractors and to the CDS extractors of SAP S/4HANA on-premise. Just like the SAP ECC connection, it leverages the SDI ABAP Adapter.
  • The SAP S/4HANA Cloud connection type of SAP Datasphere core tenant refers to the CDS extractors of SAP S/4HANA Cloud. Technically, it leverages SDI Cloud Data Integration (CDI) Adapter.
  • The ODP_CDS interface of SAP BW Bridge extracts data from SAP ABAP Core Data Services (CDS), which are delivered with SAP S/4HANA on-premise and public cloud.
  • The ODP_SAP the interface of SAP BW Bridge extracts data from classic ABAP based S-API (Service API) extractors (also known as DataSources). There are more than 5,000 SAP delivered standard DataSources available in SAP ERP or SAP S/4HANA on-premise. Consider, that not all S-API extractors are released in SAP S/4HANA on-premise (see SAP note 2500202), and, in SAP S/4HANA cloud, there are no S-API extractors at all.

Which option should you choose? Your choice depends on the extraction mode and datasource type.

Both SAP Datasphere BW Bridge (via ODP Data Sources) and SAP Datasphere core tenant (via SDI connections) are possible targets of source types SAP Business Suite or SAP S/4HANA on-premise with S-API extractors or SAP S/4HANA on-premise or cloud with CDS extractors. No restrictions of extractors for full loads to SAP datasphere exists. Decide based on system knowledge, existing models, harmonization requirements, and so on.

First, suppose that you extract all available data from a datasource (full extraction mode). There are no technical limitations, if full loads are required only. This means, both S-API and CDS extractors can be connected flexibly to either SAP BW Bridge or the SAP Datasphere Core. Your decision should be based on other considerations such as; existing know-how, existing models, the availability of business content, or the data harmonization requirements .

SAP Datasphere BW Bridge can be filled using S-API Extractors or CDS Extractors. SAP Datasphere Core can be filled using CDS Extractors. Problems exist for Delta loads of S-API Extractors to SAP Datasphere core: No primary keys are defined. Delta mode additive delta is incompatible .

Extracting data from large sources as full extraction is typically slow and uses up too much resources from the sources. To avoid this, most SAP datasources are capable of sending delta records, which means you load only the changes from the source. What should be your target for delta extraction - SAP BW Bridge or SAP Datasphere core tenant directly?

  1. Many S-API extractors are not a suitable source for the SAP Datasphere Core. They may be restricted to the SAP BW Bridge due to following two reasons:
    1. Incompatible Delta Process: The S-API extractors must comply in their Delta Process with the logic used in SAP Datasphere. This is not the case it the delta process is set up for the so-called additive delta extraction. Although less than 100 SAP S-API extractors are based on this delta type, some of these objects are quite often in use (for example, 0CO_OM_CCA_9, 0FI_GL_11, 0HR_PT_*, see table ROOSOURCE, DELTA = 'ADD' or 'ADDD' in the SAP source).
    2. Missing Primary Key Definition: Data Replication of delta changes in SAP Datasphere relies on upserting data based on a primary key. However, the vast majority of SAP delivered S-API extractors misses this primary key definition. SAP does not support a customer modification that adds key properties except for the highly demanded extractors 0FI_ACDOCA_10/20 (see SAP note 2341038).
  2. Delta-enabled CDS extractors can be used for both targets, but they are much more suitable for SAP Datasphere: Their delta logic complies with SAP Datasphere, because they require key definitions in their nature and they provide delta in upsert mode only.


For more details, refer to the following sources:

Log in to track your progress & complete quizzes