SAP Community - BW SAP HANA Data Warehousing

New SAP BW/4HANA Learning Journey

2023-10-10T08:57:03+02:00

The very latest version of SAP’s on-premise data warehouse is SAP BW/4HANA.

If you are a BW modeler, developer, consultant or administrator and have built up a significant skill set over the years in SAP Netweaver BW, make sure that you upgrade your skill to this solution which is used by thousands of customers already.

We have developed a new learning journey especially for BW experts. We focus on the changes:

The main differences between SAP BW and SAP BW/4HANA,

The new tools and modeling artifacts of SAP BW/4HANA

The new monitoring possibilities in the SAP BW/4HANA cockpit and BW/4HANA statistics content

The new data provisioning philosophy and the source system types

The enhanced data tiering optimization to store your data on the most suitable hardware

New modelling philosophy of hybrid models (combining SAP BW/4HANA and SAP HANA objects)

Watch our videos and demonstrations and check your progress by the built-in assessments. The Learning journey even leads to a certification, and if you take it successfully, you can point it out on your resumé

Don’t stay behind, but stay current in your field of expertise.

Fill the gap through upskilling and enjoy SAP’s learning offerings on the SAP Learning site. This article is created and brought to you by SAP Product Learning CoE experts!

Written by Alexander Scivos

SAP Datasphere - the next generation of SAP Data Warehouse Cloud

2023-10-11T21:11:17+02:00

Hope this blog post finds you well. Goal with this post is to provide helpful resources and support documentation to assist you in navigating the latest news.

During the SAP Data Unleashed 2023 virtual event on March 8th, it was announced that SAP Datasphere, the next generation of SAP Data Warehouse Cloud, will include enhanced features for data discovery, modeling, and distribution. This update is noteworthy.

All existing SAP Data Warehouse Cloud tenants will be transitioned to SAP Datasphere automatically, and there will be no interruption for existing customers. If you are interested, you can watch the SAP Data Unleashed 2023 virtual event on-demand to see live demos showcasing new capabilities, learn about new partnerships, and hear from customers on how they unleash the power of their business data across their data landscape.

What is SAP Datasphere? - Link for video

a data service built on SAP Business Technology Platform (SAP BTP)

a unified experience for data integration, data cataloging, semantic modeling, data warehousing, data federation, and data virtualization

easily distribute mission-critical business data—with business context and logic preserved.

(source: https://news.sap.com/2023/03/sap-datasphere-power-of-business-data/)

SAP Datasphere includes the following major new features.

(As per the SAP Help Portal (Documentation) > What's New in SAP Datasphere)

Feature	Description	More detail at:
Data Integration - Replication Flows	You can now create a replication flow to load multiple data assets from one source into one target in a fast and easy way. Possible data sources are, for example, SAP HANA, SAP HANA Cloud, or SAP S/4HANA. Possible targets are the local repository (SAP Datasphere); SAP HANA Cloud; SAP HANA; or SAP HANA Cloud, data lake.	SAP Help Portal (Documentation) > What's New in SAP Datasphere SAP Help Portal (Documentation) > Creating a Replication Flow
Data Cataloging - SAP Datasphere Catalog	The new SAP Datasphere catalog provides an effective data governance strategy and is the central place to identify, enrich, publish, and promote the use of your organization’s trusted data and analytic assets. You can use the Monitoring page to connect to data sources, monitor the data source extractions, and remove or restore data sources You can manage glossary terms, tags, and KPIs and link them to assets The catalog is the central place where you find data from your data sources	SAP Help Portal (Documentation) > What's New in SAP Datasphere SAP Help Portal (Documentation) > Governing and Publishing Catalog Assets
Data Modeling - Analytic Model	In the Data Builder, a new object is available: the analytic model. Analytic models are now the preferred objects for making data ready for consumption in SAP Analytics Cloud. They allow you to create and define multi-dimensional models to provide data for analytical purposes to answer different business questions. Pre-defined measures, hierarchies, filters, variables, and associations provide flexible and simple navigation through the underlying data	SAP Help Portal (Documentation) > What's New in SAP Datasphere SAP Help Portal (Documentation) > Creating an Analytic Model SAP Community Blog > Introducing the Analytic Model in SAP Datasphere

Strategic Partnerships - new open-data partners

SAP’s strategic partners provide the unique strengths of their ecosystems and enable customers to combine all their data like never before:

(Source: https://news.sap.com/2023/03/sap-datasphere-business-data-fabric/ and https://news.sap.com/2023/03/sap-datasphere-simplify-data-landscape-partnerships-collibra-confluent-databricks-datarobot/)

Databricks and SAP will deliver bi-directional integration between SAP Datasphere—with SAP data’s complete business context—with its Data Lakehouse platform on any cloud platform. More detail at: Unified Analytics with SAP Datasphere & Databricks Lakehouse Platform- Data Federation Scenarios

Collibra and SAP will start by integrating their data catalogs to future-proof data governance, privacy, and compliance initiatives for every organization

Confluent will enable data in motion with real-time streaming data from/to SAP Datasphere

DataRobot will allow any organization to build powerful custom machine learning models on top of SAP Datasphere and bring results directly into their business data fabric

SAP Datasphere FAQ

For answers to some initial questions you may have about SAP Datasphere, please check out the SAP Datasphere FAQ in the SAP Community which can be found at https://community.sap.com/topics/data-warehouse-cloud/datasphere-faq.

a). How does SAP Datasphere compare to SAP Data Intelligence Cloud?

It is planned that SAP Data Intelligence Cloud will remain its own solution. The co-existence of SAP Datasphere and SAP Data Intelligence Cloud will continue until SAP Datasphere can support all customer use cases of SAP Data Intelligence Cloud. The goal is for SAP Datasphere to eventually cover all major capabilities, target systems, and use cases that SAP Data Intelligence Cloud provides. Tools will also be provided to facilitate the technical transition.

b). What does this mean for SAP Data Intelligence Cloud customers?

Customers using SAP Data Intelligence Cloud should continue using this product as they have been. No changes are needed.

c). What is the integration between SAP Datasphere and SAP Analytics Cloud?

SAP Datasphere and SAP Analytics Cloud are seamlessly integrated to support a wide range of analytics and planning use cases. The upcoming release of the Analytic Model in SAP Datasphere will further enhance this integration. With the Analytic Model, users can enjoy a multi-dimensional modeling experience that includes advanced features such as calculated and restricted measures, exception aggregations, and pruning of attributes and measures. These capabilities enable users to address complex modeling requirements, making SAP Datasphere models "first class citizens" in SAP Analytics Cloud. It is also worth noting that SAP Datasphere can serve as a solid data foundation for extended planning and analysis with SAP Analytics Cloud.

d). How does SAP Datasphere relate to SAP Business Technology Platform?

SAP Datasphere, an integral part of the SAP Business Technology Platform (SAP BTP), is a powerful data service that can help businesses build a robust data fabric architecture. It comes equipped with a BW bridge that allows existing SAP BW customers to make the most of their existing models and transformations. SAP Datasphere is built on the highly reliable SAP HANA Cloud, which is yet another exceptional product within the SAP BTP.

=> Please pay attention to the recently updated material in SAP Datasphere Learning Journey.

Under the Expand Your Skills section you will see the updated SAP Datasphere, SAW BW Bridge and Integration subsection.

Expanding the tiles you'll find newly released blogs, KBA's, and Documents as well as information on the new Readiness Check Scenario - SAP Readiness Check for SAP Datasphere, SAP BW bridge

Also see this blog for more details on the SAP Readiness Check for SAP Datasphere, SAP BW bridge

Another great resource if you're implementing/transitioning to SAP Datasphere is the SAP Activate Methodology for SAP Datasphere: Here

Useful Links:

SAP News Blogs

Unleashing the Power of Business Data with SAP Datasphere

A Deeper Look Into How SAP Datasphere Enables a Business Data Fabric

SAP Introduces SAP Datasphere to Simplify Customers’ Data Landscape – Partners with Collibra, Confluent, Databricks and DataRobot

Partner Quotes: SAP Introduces SAP Datasphere

SAP Product Information

SAP.com > SAP Datasphere

SAP Community > SAP Datasphere

SAP Community > Getting Started with SAP Datasphere

SAP Help Portal (Documentation) > SAP Datasphere

SAP Road Map Explorer > SAP Datasphere

SAP BW/4HANA & BOBJ Dashboard Reporting (Blog1)

2023-10-28T17:15:56+02:00

1.1 Overview

The objective of this blog series is to detail the development of solution architecture and technical design specifications of SAP ECC staging Datasources (Blog1) for reports in SAP BW/4HANA & SAP BOBJ dashboard reporting (Blog2) and development of a standalone in SAP Business Intelligence/SAP BusinessObjects. The Dashboard reporting uses the SAP BusinessObjects BI (SAP BOBJ). which is a centralized suite of reporting and analytics tools for business intelligence (BI) platforms. SAP BOBJ consists of several reporting applications that allow users to discover data, perform analysis to derive insights and create reports that visualize the insights through Dashboards. The following topics are covered in this blog series.

SAP ECC staging Datasources for reports: Solution Architecture & Design (Blog1)

Dashboard Reporting: SAP BW/4HANA and SAP Businessobjects Analysis for OLAP & Businessobjects WEBI Dashboards (Blog2)https://blogs.sap.com/2023/10/29/sap-bw-4hana-bobj-dashboard-reporting-2/

1.2 Functional Requirement

1.2.1 Dashboard REPORTING SCOPE

The existing reports in SAP ECC, which need to be designed and viewed/queried from SAP ECC to SAP BW/4HANA and SAP BOBJ reporting tools. The main objective is to facilitate user self-service, to allow the users to generate their own reports in future as the requirements change.

1.3 Business Process Landscape

The business process landscape below shows the specific scope in the broader context of the overall process landscape of SAP BW/4HANA System. The Dashboard reporting uses the SAP BusinessObjects BI (SAP BOBJ), which is a centralized suite of reporting and analytics tools for business intelligence (BI) platforms.

Enterprise Data Warehouse Layer (EDW): This is a combination of Open Operation Data Store Layer (ODS) and Core Data Warehouse layer (CDW) in SAP BW/4HANA LSA++ architecture. Open ODS layer is similar to the data acquisition layer in SAP BW. The open ODS layer is used to integrate data into the Data Warehouse and provides the same functionality as the classic data acquisition layer, but with more flexible data integration possibilities. The CDW layer, is responsible to perform functions like data transformation, data cleansing and consolidation In EDW layer, cleansed, harmonized and consolidated data from different source systems is provided. Source data can be transformed, enhanced and merged, to support broad usage and easy consumption for a wide-range of analysis purposes. Data is not aggregated, but stored at line-item level in EDW Core ADSO’s. These serve as a reusable consistent data foundation used in the next layer if required. The purpose of this layer is the transformation of data in one layer

Curated Data Layer: This is also known as Virtual Data Mart Layer. This layer is responsible to combine the data from other layers and to make it available for reporting purposes. This layer contains all the InfoProviders that combine data using join or union, without saving the result: MultiProvider, Composite Provider, etc. You can use this to access data directly in the SAP HANA database, to allow queries on Composite Provider, Open ODS View. Composite provider allows you to merge the data from BW InfoProviders with HANA Modeling views. Union and Joins are performed in SAP HANA and queries can be run on composite providers, like BW InfoProviders. Based on application-specific business requirements, data from EDW core layer is combined and mapped to Data Marts. These structures then serve as query targets for reporting and analytics. This layer will be accessed by Data Scientists.

Virtual Reporting Layer: Represents logical views of data and does not physically contain data. This layer will be accessed by Data Analysts.

Visualizations Layer: Provides the Reporting and Analytical layer, it provides the End Users with View Access, and Self-Service Reporting for End Users and Data Analysts.

ECC- BW Staging Area: The customized data sources through function module will extract the ECC data to SAP BW InfoProviders from ECC tables

1.4 SOLUTION ARCHITECTURE

The existing custom reports requires more analysis in ECC system, and the business need for a BW 4HANA report/BOBJ Dashboard that shows the same data with the custom report in ECC. In standard cases, the ideal way would be to search for standard business content ECC datasources to extract the ECC data to BW/4HANA. Since standard business content datasources are not available to meet these reporting requirements, there is a need to create custom datasources for ECC reports in the ECC-BW staging area. There are three main methods explored for creation of custom BW datasources below.

1.4.1 Option 1: Extraction by table/view

Change the existing the custom program of the custom report to fill in a Z table and create generic Datasources on the Z table to extract the ECC data

Steps:

Create Z Table

Change the Z Program of Report to fill the Z Table

Create Datasource; Extraction by View/table. to extract the data

Design & Dataflow

1.4.2 Option 2: Extraction by function module with memory id

Change the existing report code to add the memory ID to store the output results and create function module to import the output results from memory id and create generic datasource on this function module to pass the output to the datasource

Steps:

Create function module to import the output from memory ID and pass it datasource: Report is called by FM Using Submit report with Parameters and return statement along with selection screen parameters. Add the Minor code changes to the existing program of report to save the output results in Memory ID by export statement

Add memory ID to the Z program report to store and export the output: Use the function module to retrieve the output results by import from memory Id and pass it to the datasource. .

Create Datasource; Extraction by function module. to extract the data: When the function is called to upload an Datasource, the FM code calls the report to generate the data we require through Memory ID to datasource

Design & Dataflow

1.4.3 Option 3: Extraction by function module

Create a function module with same logic of custom report code and create generic datasource on this function module

In this blog1, the ECC custom datasources for dashboard reporting are configured by using Option Extraction by function module.

1.4.4 Technical design steps and dataflow

Create function module: create a function module that exactly behaves the same way as the program logic of the custom report.

Create Datasource; Extraction by function module. to extract the data : create a totally new datasource according to a new requirement, by using logic in the existing custom program.

1.5 Testing

The ECC report data is extracted by the relevant custom datasources and unit testing is done with two scenarios. The data is matched with ECC Report to relevant datasources in both scenarios.

Appendix:

Datasource: Datasources contains a set of fields that provide the data for a business unit for data transfer into BW. From a technical point of view, the Datasource is a set of logically-related fields that are provided to transfer data into BW in a flat structure. When execute the datasource through function module. the data from DB table is passed on to the datasource through Extract structure by function module. The structure of the datasource is called extract structure (T-Codes in ECC, RSO2-for creation of Datasource; RSA3-to check/extract the data in Datasource-; RSA2 - to check properties of data sources ;RSA5 -Install Business content ; RSA6 – Maintain datasources; RSA8 – Datasource Repository ;RSDS:-Datasource)

Function Group: Function group is a container of Function modules; every Function Module must be saved in a Function group. (T-codes in ECC for creating Function Modules and Function groups are SE37 or SE80).

Function Module: Function Modules are sub-programs which contains set of re-usable statements with importing, exporting parameters, exceptions. Unlike include programs Function Modules can be executed independently.

Components of Function Module: Import: These are input parameters of a Function Module. Export: These are output parameters of a Function Module .Tables: These are internal tables which also acts as importing and exporting parameters. Exceptions: Exceptions in Function Modules are used to catch certain type of errors.

SAP BW/4HANA & BOBJ Dashboard Reporting (Blog 2)

2023-10-29T06:16:05+01:00

1.1 Overview

The objective of this blog series is to detail the development of solution architecture and technical design specifications of SAP ECC staging Datasources (Blog1) for reports in SAP BW/4HANA & SAP BOBJ dashboard reporting (Blog2) and development of a standalone in SAP Business Intelligence/SAP BusinessObjects. The Dashboard reporting uses the SAP BusinessObjects BI (SAP BOBJ). which is a centralized suite of reporting and analytics tools for business intelligence (BI) platforms. SAP BOBJ consists of several reporting applications that allow users to discover data, perform analysis to derive insights and create reports that visualize the insights through Dashboards. The following topics are covered in this blog series.

SAP ECC staging Datasources for reports: Solution Architecture & Design (Blog1) https://blogs.sap.com/2023/10/28/sap-bw-4hana-bobj-dashboard-reporting/

Dashboard reporting: SAP BW/4HANA and SAP BusinessObjects Analysis for OLAP & Businessobjects WEBI Dashboards (Blog2)

1.2 Functional Requirement

1.2.1 Dashboard REPORTING SCOPE

Time - Fiscal Year; Fiscal Quarter and Fiscal Period

Geography – Area, district, ward, sub council

Customers

Filters Input Controls:

Area/Location

District

Sub council

Ward

Suburb

Date range

KPIs measures to include:

Number and Percentage of Active Bays per area, suburb, district and sub-council.

Number and Percentage of Active Bays

Comparisons of active bays using Areas, suburbs

Comparisons of active bays using Date ranges/fiscal year

1.3 DESIGN (B/W4HANA Modelling)

BW/4HANA Modelling -Custom Datasources (Transaction & Master data)

BW/4HANA Modelling -Custom Datasources (ODP) (Transaction & Master data)

BW/4HANA Modelling -Infoobjects ( key Figures & Characteristics)

1.4 DESIGN (SAP Businessobjects Analysis for OLAP)

SAP BusinessObjects Analysis, edition for OLAP is a powerful, web-based OLAP analysis tool that can help to gain insight into business data and make intelligent decisions that impact corporate performance.

1.5 DESIGN (BOBJ WEBI Dashboards)

Consuming data from SAP Datasphere into Power BI via ODBC connector

2023-11-09T09:54:51+01:00

I wanted to share my proof of concept about consuming data from SAP Datasphere into Power BI via ODBC connection (Open database connection)

Required:

Datasphere tenant.

Power BI.

Need to create a database user for the particular space in the space management.

Host name, Port number, Password, Database username.

Need to add External IPV4 Address in the IP Allowlist.

Hana ODBC client.

Need to add credentials in Power BI.

Datasphere part:
Login into Datasphere -> Space Management -> Choose the space and select Edit.

Click Create and Make sure that you have enabled Expose for consumption by default

Copy Database Username, Host name, Port, Password.

Go to System-> Configuration-> IP Allowlist-> Trusted Ips

EXTERNAL IPV4 ADDRESS should be added here, not Internal IPV4

To get External IPV4 Address

Open Command prompt and enter nslookup myip.opendns.com resolver1.opendns.com or curl ifcfg.me

Then run nslookup myip.opendns.com resolver1.opendns.com
in command prompt and add that IPV4 Address in the IP Allowlist.

Add and Save the External ipv4 address here.

ODBC PART:

Need to install SAP HDODBC driver SAP Development Tools (ondemand.com) in the system.

Open ODBC in the system

Click Add

Select HDODBC

Give any meaningful name to Data source name, description.

Database type: SAP HANA Cloud or SAP HANA Single tenant (both will work fine).

Already copied Host URL in datasphere space, Paste the copied Host URL.

Click Test connection

Paste the Database username in Username and Password.

POWER BI PART:

Power BI-> Get data-> ODBC.

Select the created ODBC Connection

Paste the same Username and Password which copied in datasphere part, click "Connect".

Successfully Power BI consuming data from SAP Datasphere

Dashboard built in Power BI

From this POC:

Data from Datasphere can be consume via OBDC connection 100/100.

Since ODBC connection is possible, we can consume data into any third-party reporting tools that we want.

THANK YOU !

Inventory Management in BW/4HANA

2023-11-13T23:12:16+01:00

Inventory management deals with: -

Stock (Qty and value) of material kept in a plant for a customer.

Movements (Incoming and outgoing) of material from one place to another. Also called ‘Receipts’(Incoming) and ‘issues’(Outgoing).

When we talk about stock of material, we cannot cumulate (sum) the stock. For e.g. On 1st Jan, the stock was 100 KG and on 2nd Jan it was 90 KG, we cannot add both and say the total stock is 190 KG which would be wrong. So, by end of 2nd Jan, the total stock is 90KG. This is called non-cumulative key figure.

Therefore, when we can't cumulate the values, we call them non-cumulative values and for non-cumulative values, we always need a time reference. E.g., If the question asked is 'What's the current material stock?' then we need to ask a counter question that 'As of what date?'. If the as of date is 1st Jan, then value is 100 and if as of date is 2nd Jan, then value would be 90. So, this time reference is used for exception aggregation.

Initial Stock: As of today, what is current total stock (Material and Plant combination). This is the data which marks the current stock qty and value in source.

BW/BWoH -> Opening Balance -> Markers [Markers were stored in Active table]

BW4HANA -> Opening Balance -> Reference Points [Markers are now called as Reference points]. Reference points are no longer stored in the active table. Reference point (Opening balance) are now stored in special table (reference point table).

Historical data: This is the historical movements before today which resulted in the initial stock. Historical data load will not impact Reference point because it has already result ed in Opening balance.

Delta: This is from today onwards what are the incoming (receipts) and outgoing (issues) movements. This will update the Reference point as it is future movement.

Reference Point:

This is the time reference for non-cumulative keyfigure.

The reference characteristic is always the most granular time characteristic in the ADSO.

Reference is the current up to date Stock Qty and Value which can be found in the ADSO.

Ex:- Initially a value came in 100 KG. and then 20KG was issued (outgoing). Pointer adjusted to 80KG (100 – 20, then 50KG was received (incoming) and 25 KG was issued (outgoing). Pointer adjusted to 105KG (80 + 50 - 25).

Reference pointer = The value of the non-cumulative KF.

This is called reference and is the first value which is used to calculate all the remaining values by traveling to the future or past.

Previous LSA Inventory Dataflow:

Old LSA Inventory Dataflow

Three Datasources in the past:

2LIS_03_BF: Movements (Historical and Delta movement). Base table MSEG and others.

2LIS_03_BX: Opening Balance (Stock Initialization) Base table MARD.

2LIS_03_UM: Revaluations (Optional). If price of material changes, then all the stocks will be re-evaluated.

*All the data is loaded into a single InfoCube.

New BW/4HANA Flow on Premise

BW/4HANA LSA++ Inventory Flow

Same three Datasource were available here also.

2LIS_03_BX: No Staging ADSO as it is a onetime full load.

2LIS_03_BF: Two Staging ADSO for Historical and Delta Movements. This will then go to three ADSO (Initial stock Quantity, Initial stock Values and Movements)

2LIS_03_UM: Revaluations only going to Material Stock Value ADSO because the revaluations do not impact the quantity, it only impacts the value.

This has simplified the design (less rule group and ABAP routine codes).

Now, SAP has replaced ABAP routines with formula in the standard content, as with the formulas we can now have HANA execution possible. Hence it is much faster now.

Record Type concept in Inventory:

Non-cumulative ADSO use the technical field ‘Record Type’ (RECORDTP). This field((RECORDTP) is not visible in TRFN and by default it will be calculated in the system in backend.

I will differentiate between the Historical movement, Delta movement and Initial Stock (Opening stock).

RECORDTP = ‘1’: Initial Stock will load with Record Type = 1. This will not go to active data table but rather go to another table. In General Properties of Datasource, it has the flag as “Opening balance”.

RECORDTP = ‘2’ Historical Movement will load with Record Type = 2 and upon activation stay as Record Type = 2. This will go to active data table.

RECORDTP = ‘0’: Delta Movement will load with Record Type = 0 and upon activation it will change to Record Type = 2.

It is very important to update the reference point every time a new delta comes in.

Also, helps in time-based archiving of a non-cumulative ADSO.

BW Modelling for Stock Flow: -

ADSO: Two types of ADSO’s can be use for modelling of Initial Stock Flow: -

Standard ADSO with change log: We need to make sure that the Key Figure aggregation behaviour is Summation as the datasource gives ABR.

Data Mart ADSO: Automatically aggregation behaviour is always summation.

Inventory ADSO Properties

We need to check the box “Inventory-Enabled” in special properties. When Inventory-Enabled checkbox is checked another tab called “Inventory” will appear for the ADSO and here we have.

We will use the non-cumulative keyfigure “0TOTALSTCK” (Total Quantity Stock), automatically two cumulative keyfigure (source of non-cumulative key figure) 0ISSTOTSTCK (Issue Stock Total Quantity) and 0RECTOTSCTK (Receipt Quantity Total Stock) will be added along with base unit of measure.

Total value is equal to total of inflow – total of outflow and this will not be calculated in ADSO layer, but it will be calculated in Query layer.

Inventory Tab: - This is specially for Inventory ADSO and appears only when we select for “Inventory-Enabled” in special properties of ADSO.

Reference Time characteristics: - By default it will take lowest granularity of time characteristics.

Validity Period: - Validity period defines the time since when the Keyfigure (Qty and Value) are valid from. (Here it will take 0CALDAY by default).

If the plant is not there on 1^st Jan and comes into Picture on 1^st June then the plant will only show up in the report starting from 1^st June and not from 1^st Jan and all the values from 1^st Jan till 1^st June as Zero.

The Validity Table automatically contains the “most detailed” of the selected time characteristics which is also known as reference characteristic.

Tables for Inventory ADSO

1.Inbound Table [/BIC/AADSO1]

2.Active Table [/BIC/AADSO2]

3.Change Log (not filled for Datamart ADSO) [/BIC/AADSO3]

4.Validity Table [/BIC/AADSO4]

5.Reference Point [/BIC/AADSO5]

6. Extraction View (UNION of Inbound + Active + Reference Table) [/BIC/AADSO6]

7.Reporting View (UNION of Inbound + Active + Reference Table) [/BIC/AADSO7]

8. External SQL View (Mimicking Query behaviour with Non-cumulative KYF populated [/BIC/AADSO3]

Scenario during data loading

On 22^nd July' 2020, the initial stock balance is extracted from source to B4H.This is the current operational stock (Opening balance).

To be able to report on stock quantities before 22^nd July' 2020, we also load historical movements that happened before we extracted the initial stock balance.

From now onwards, delta movements, i.e., Goods issued, and Goods receipt are loaded.

Here are the initial stock, delta, and historical records to be loaded into ADSO.

Data Example

Example of Data for this Scenario

Record type journey for different data load types in Inventory

Record Type Journey

For Initial Stock

Inbound table: - The Initial stock will be loaded into Inbound table with Record Type = 1.

and after activation data will be deleted from here (as usual).

Active Table: - No Involvement of Active table in this scenario.

Validity table: - The Validity will be updated in CALDAY From(0CALDAY_F) and CALDAY To (0CALDAY_T) column.

Reference Point: - Once the Initial Stock is activated it will go in the Reference Point table. Here it will load into Receipt as in is Initial stock and is considered as Incoming [Record Type = 1].

External SQL View: - Here Non-Cumulative value will be populated and Calday/Calmonth will become end of Time 9999-31-12.

For Historical Movement

Inbound table: - The delta records will be loaded into Inbound table with Record Type = 2.

and after activation data will be deleted from here (as usual).

Active Table: - After activation data comes to Active table with Record Type = 2.

Validity table: - The Validity table CALDAY From(0CALDAY_F) column will be updated (as Historical load is past data) from the Calday coming in historical movements.

Reference Point: - Historical movement (Record Type = 2.) does not update the reference point. {As the historical movement has already updated the reference point and Initial stock balance is result of Historical movement}. No Change in Reference Point table.

External SQL View: - For Record Type 2 we cannot see the non-Cumulative value but it’s the Inbound and Outbound which will be populated.

For Delta Movement

Inbound table: - The delta records will be loaded into Inbound table with Record Type = 0 and after activation data will be deleted from here (as usual).

Active Table: - After activation data comes to Active table with Record Type = 2.

Validity table: - The Validity will be updated in CALDAY To (0CALDAY_T) with the latest date.

Reference Point: - Delta movement will update the Reference Point. Record Type will still be 1 here.

External SQL View: - For Delta movement also we cannot see the non-Cumulative value but it’s the Inbound and Outbound which will be populated

Query Result on Top of Inventory Info-Provider

Query Result

Here for Material M100 we have data from 17/09/2020 – 25/09/2020 but system has created row for 1 day before [16/09/2020] in query with [0] data.

Similarly for Material M200, It started from 21^st and 300 issued on 21^st, and after issuing 200 was remaining. It means on 21^st what would have been the total value before the issue. Its 500 and that what system gives calculating back in time.

What system does is that if the value is not there it will add the value going back in time and it gives that this must have been the value before.

Reference

https://blogs.sap.com/2018/06/25/inventory-modeling-in-sap-bw4hana/

https://www.hanaexam.com/2018/06/inventory-management-in-sap-bw4hana.html

Sierra’s InFocus: SAP Datasphere Readiness Assessment

2023-11-14T22:57:45+01:00

The InFocus SAP Datasphere Readiness Assessment, crafted to enable rapid SAP BTP readiness, is a solution co-offered by SAP and its global partner, Sierra Digital. Unlike conventional SAP BW assessments which are limited to analysis of a system's BW artifacts, InFocus assesses standard/custom SAP BW objects, plus BW Bridge limitation--and its usage across the enterprise. Such expanded scope enables the user to produce precise, bespoke artifacts, significantly enhancing the ability to scope transition to SAP Datasphere, assuring heightened efficiency, and optimizing outcomes.

Sierra's InFocus SAP Datasphere Readiness Assessment

How InFocus Aids SAP BW to SAP Datasphere Migration

Promotes understanding of the current state of SAP BW System, including data models, complexity, usage, and frequency

Identifies gaps and/or inconsistencies in the SAP BW System that need to be addressed before migrating to SAP Datasphere

Identifies SAP BW Objects that are not compatible with BW Bridge Migration and need to be redesigned or migrated using a different method

Results in a migration plan that outlines the steps needed to successfully migrate SAP BW System to SAP Datasphere

Recommends retirement of obsolete objects from existing environment

Identifies SAP BW processes that need to be modernized or automated to run more efficiently in SAP Datasphere

Calculates rough cost and resource estimate required to migrate SAP BW System to SAP Datasphere

Solution Architecture :

High Level Solution Architecture for SAP Datasphere Readiness Assessment

Sample Screens Generated in SAP SAC :

The InFocus SAP Datasphere Readiness Assessment is anchored by a dashboard which offers a comprehensive view of the landscape. The dashboard helps users gain valuable insights on their SAP BW environment. The Overview Screen serves as a centralized hub, presenting a detailed inventory of standard and custom objects ranging from data sources to ETL components, modeling, and reporting artifacts. A key feature is the Object Usage Aging Report, which provides a historical perspective on how SAP BW Objects have been utilized over time. This data empowers customers with the ability to make informed decisions about retiring unused objects, optimizing the system, and reducing unnecessary overhead

Sample SAC Report with all SAP BW Artifacts

The dashboard offers more than a list of objects. It offers a deeper dive into the specifics of Currency & Unit Conversion within queries and transformations—valuable detail for an enterprise considering a migration from SAP BW to Datasphere using the SAP BW Bridge Tool.

The SAP BW Artifacts Section of the dashboard facilitates yet deeper understanding via the Complexity Categorization Report. This report classifies SAP BW artifacts as Simple, Average, or Complex, providing an easy-to-reference roadmap for the migration process. Prepared with the Complexity Categorization Report, the enterprise can more fully estimate effort and resources required for a successful transition, thus enabling better project planning and execution.

Integration of readiness functionality with SAP SAC steps users toward enhancing customer convenience, simplifying processes, and fostering efficiency leveraging SAP BTP.

Conclusion:

In summary, the SAP Datasphere Readiness Assessment Dashboard stands out as a robust resource for organizations navigating the transition from SAP BW to Datasphere. It not only provides a comprehensive overview of the current SAP BW landscape but also furnishes the insights necessary for making strategic decisions, streamlining the migration process, and ensuring a seamless transition to the future of data management. The integration of Assessment Readiness functionality into SAP SAC is a key step towards enhancing customer convenience, simplifying processes, and fostering efficiency and consistency. Sierra Digital proudly offers this funded assessment service, contingent upon the establishment of all necessary connections, underscoring our dedication to delivering a smooth migration experience.

We value your thoughts and feedback on our SAP Blog. Please feel free to share your insights and comments below. Additionally, for more content related to SAP and data management, we invite you to follow our profile. Thank you for your engagement!

Would you like us to evaluate your existing SAP BW system free? Don't hesitate – please sign up using the link below.

https://www.sap.com/registration/free-assessment-offer-for-bw-customers.html

For Additional Information:

This is a short video on what the report will contain:

This is a brief video that dwells deeper into the assessment:

Co-Author :Kaviarasan (Kavi) Thangarasu is a BI Architect with extensive experience designing, describing, and managing solution engineering matched to specific business problems. Immersed in SAP IT solutions for over a decade, Kavi mentors customers who seek to bridge the gap between technology and business leveraging automation and integration practices that unlock hidden business worth.

Where can I develop the skills to implement a data warehouse using SAP BW/4HANA?

2023-12-19T17:37:32.680000+01:00

You can build the skills you need, for free and at your own pace with our Digital Learning Journey.
on our SAP Learning Site

Access our Implementing a Data Warehouse Using SAP BW/4HANA learning journey

Overview
This learning journey will enable you to develop the skills to implement a data warehouse using SAP BW/4HANA.

Learning objectives
After completing this learning journey, consultants will be able to:

Identify how SAP BW/4HANA is used to set up a data warehouse by implementing a scenario
Work with SAP BW/4HANA using BW Modeling Tools, SAP BW/4HANA Cockpit, and SAPGUI
Model InfoObjects, DataStore Objects (advanced), Open ODS Views and CompositeProviders
Model Data Flows with DataSources, Transformations and Data Transfer Processes using the Graphical Data Flow Tool
Load master data and transactional data from SAP S/4HANA, flat files and SAP HANA tables

Consume SAP BW/4HANA data in SAP Analysis for Microsoft Office using a BW Query

Prerequisites
Getting Started Building an On-Premise Data Warehouse using SAP BW/4HANA

Hope this is helpful.

Please ask a question related to the digital learning Journey in the Q&A area
Our SAP Learning Experts will get back to you as soon as possible! We are here to support you.

We appreciate your feedback and we will make sure to continue sharing interesting topics.

Kind regards
Margit

How to map SAP ERP fields to SAP BW/4HANA InfoObjects?

2024-01-09T02:36:36+01:00

Introduction

It could be cumbersome for BW developers while trying to find appropriate InfoObjects to use in InfoProviders. BW developers often ask themselves if there are any standard InfoObjects that they can use for mapping with SAP ERP fields and therefore, use in the InfoProviders such as DSO.

In this blog post, I'm going to teach a way to find the mappings of SAP ERP fields with SAP BW/4HANA InfoObjects. The process I will talk about works also on SAP BW classic (3.X and 7.x).

At the end of this blog post, you'll know how to find the standard InfoObject (if there are any) mappped with a SAP field and use in your InfoProvider.

Solution

In SAP BW classic versions, it was easier to find the right mapping for ERP fields, thanks to tables such as:

Table RSTRFIELDSH (Shadow table: Transfer Structure Fields)

Table RSOSFIELDMAP (Mapping Between OLTP Source Fields and InfoObjects)

Table RSTSFIELD (Transfer structure fields)

Since these tables don't exist anymore in SAP BW/4HANA, I started thinking about utilizing the assignment rules in BI Content Transformations. These help us to find out what InfoObjects are used to be mapped with the source fields in the standard transformations.

I created a Program named ZMAP_FIELD_INFOOBJECT for this purpose. Create the same in your SAP BW/4HANA system. I suggest that you execute this program once in background and insert the output in a table for easier and faster access.

Based on the output of my Program, I designed a helper report. You can do the same for yourself or write your email for me in comments, if you want me to send this excel report to you.
To explain how this report works, I’m giving you an example. Let’s take MATNR for instance. Here, we see that the InfoObject 0MATERIAL is used 119 times in transformation rules to be mapped with MATNR.

Source of Program:

*&---------------------------------------------------------------------*

*& Report ZMAP_FIELD_INFOOBJECT

*&---------------------------------------------------------------------*

*&

*&---------------------------------------------------------------------*

REPORT ZMAP_FIELD_INFOOBJECT.



TABLES: RSTRAN, RSTRANRULE, RSTRANFIELD.



TYPES: BEGIN OF ST_RESULT,

         ZFIELDNM      TYPE RSFIELDNM, 

         ZIOBJNM       TYPE RSIOBJNM, 

         SOURCETYPE    TYPE RSO_TLOGO_SUBTYPE,

         SOURCENAME    TYPE SOBJ_NAME,

         TARGETTYPE    TYPE RSTLOGO,

         TARGETNAME    TYPE SOBJ_NAME,

         TRANID        TYPE RSTRANID,

         OBJVERS       TYPE RSOBJVERS,

         RULEID        TYPE RSTRAN_RULEID,

         SEQNR         TYPE RSTRAN_SEQNR,

         GROUPID       TYPE RSTRAN_GROUPID,

         GROUPTYPE     TYPE RSTRAN_GROUPTYPE,

         RULETYPE      TYPE RSTRAN_RULETYPE,

         SEGID         TYPE RSTRAN_SEGID,

         STEPID        TYPE RSTRAN_STEPID,

         PARAMTYPE     TYPE RSTRAN_PARAMTYPE,

         PARAMNM       TYPE RSFIELDNM,

         FIELDTYPE     TYPE RSTRAN_FIELDTYPE,

         RULEPOSIT     TYPE RSPOSIT,

         ZSOURCE_POSIT TYPE RSPOSIT,

         ZTARGET_POSIT TYPE RSPOSIT,

       END OF ST_RESULT.



DATA: WA_RESULT  TYPE ST_RESULT,

      WA_RESULT1 TYPE ST_RESULT,

      WA_RESULT2 TYPE ST_RESULT,

      IT_RESULT  TYPE TABLE OF ST_RESULT,

      IT_RESULT1 TYPE TABLE OF ST_RESULT,

      IT_RESULT2 TYPE TABLE OF ST_RESULT,

      LV_COUNT   TYPE I,

      GR_TABLE   TYPE REF TO CL_SALV_TABLE.



SELECT-OPTIONS: P_FIELD     FOR RSTRANFIELD-FIELDNM.





SELECT RSTRAN~TRANID

       RSTRAN~OBJVERS

       RSTRAN~SOURCETYPE

       RSTRAN~SOURCENAME

       RSTRAN~TARGETTYPE

       RSTRAN~TARGETNAME

       RSTRANRULE~RULEID

       RSTRANRULE~SEQNR

       RSTRANRULE~GROUPID

       RSTRANRULE~GROUPTYPE

       RSTRANRULE~RULETYPE

       RSTRANFIELD~SEGID

       RSTRANFIELD~STEPID

       RSTRANFIELD~PARAMTYPE "0=Importing - 1=Exporting

       RSTRANFIELD~PARAMNM

       RSTRANFIELD~FIELDTYPE "F=Field - I=InfoObject

       RSTRANFIELD~RULEPOSIT

  INTO CORRESPONDING FIELDS OF TABLE IT_RESULT1

  FROM RSTRAN

  INNER JOIN RSTRANRULE  ON RSTRAN~TRANID      = RSTRANRULE~TRANID

                        AND RSTRAN~OBJVERS     = RSTRANRULE~OBJVERS

  INNER JOIN RSTRANFIELD ON RSTRANRULE~TRANID  = RSTRANFIELD~TRANID

                        AND RSTRANRULE~OBJVERS = RSTRANFIELD~OBJVERS

                        AND RSTRANRULE~RULEID  = RSTRANFIELD~RULEID

  WHERE RSTRAN~OBJVERS      = 'D' "Content

    AND RSTRAN~SOURCETYPE   = 'RSDS' "DataSource

    AND RSTRANRULE~RULETYPE IN ('DIRECT' , 'TIME').





APPEND LINES OF IT_RESULT1 TO IT_RESULT.

DELETE IT_RESULT WHERE PARAMNM   NOT IN P_FIELD.

DELETE IT_RESULT WHERE PARAMTYPE NE 0

                   AND FIELDTYPE NE 'F'.

SORT IT_RESULT BY TRANID RULEID.





CLEAR: WA_RESULT.

LOOP AT IT_RESULT INTO WA_RESULT.

  WA_RESULT-ZSOURCE_POSIT = WA_RESULT-RULEPOSIT.

  WA_RESULT-ZFIELDNM = WA_RESULT-PARAMNM.



  CLEAR: WA_RESULT1, LV_COUNT, IT_RESULT2.

  LOOP AT IT_RESULT1 INTO WA_RESULT1 WHERE TRANID = WA_RESULT-TRANID

                                       AND RULEID = WA_RESULT-RULEID

                                       AND PARAMTYPE = 1

                                       AND FIELDTYPE = 'I'.

    APPEND WA_RESULT1 TO IT_RESULT2.

  ENDLOOP.



  IF SY-SUBRC NE 0.

  ENDIF.



  DESCRIBE TABLE IT_RESULT2 LINES LV_COUNT.

  IF LV_COUNT = 1.

    WA_RESULT-ZTARGET_POSIT = WA_RESULT1-RULEPOSIT.

    WA_RESULT-ZIOBJNM = WA_RESULT1-PARAMNM.

  ENDIF.



  MODIFY IT_RESULT FROM WA_RESULT.

ENDLOOP.



DELETE IT_RESULT WHERE ZIOBJNM IS INITIAL.

SORT IT_RESULT BY ZFIELDNM ZIOBJNM SOURCETYPE TARGETTYPE SOURCENAME TARGETNAME.





CALL METHOD CL_SALV_TABLE=>FACTORY

  IMPORTING

    R_SALV_TABLE = GR_TABLE

  CHANGING

    T_TABLE      = IT_RESULT.



CALL METHOD GR_TABLE->DISPLAY.

Conclusion

Now, the Program ZMAP_FIELD_INFOOBJECT is at your service to help you find out which InfoObjects are mapped to SAP ERP fields in BI Content Transformations. So creation of InfoProviders gets faster by knowing what InfoObjects to include in the structure.

I hope that you find this post helpful. I'd appreciate if you share your feedback or thought in a comment.

Best regards,

Hadi

Safeguard your SAP BW conversion with SAP Enterprise Support services

2024-02-28T15:04:18.393000+01:00

As an SAP BW customer you may be in the process of planning your conversion from SAP Netweaver BW 7.5 to SAP BW/4HANA and investigating SAP Datasphere use cases in parallel.

It is important to note that the timeline for end of maintenance is fast approaching for SAP BW Netweaver 7.5 and its related components (as outlined in the recent Feature Overview SAP BW/4HANA 2023 – page 18).

With that in mind I would like to take this opportunity to refresh your knowledge of support and empowerment services that are available from SAP Enterprise Support to safeguard you SAP BW project milestones.

CONVERSION GUIDANCE

In a recent blog I provided all of the details about our Expert Guided Implementation service.
This virtual classroom session is designed to provide guidance SAP BW/4HANA, SAP Datasphere, and the conversion strategies associated with these SAP Data warehousing solutions.

As a brief summary the goals are:

Understand the use cases and important features in SAP BW/4HANA and SAP Datasphere and the available conversion approaches for each to support customers that must convert (due to maintenance) from a current SAP BW system.
Learn how to convert an existing SAP BW system to SAP BW/4HANA or SAP Datasphere, SAP BW Bridge.
Enable customers to leverage SAP Readiness Check for BW/4HANA and SAP Readiness Check for SAP Datasphere, SAP BW bridge.

SUPPORT SERVICES

It is timely to remember that as an SAP Enterprise Support customer you are entitled to a range of Continuous Quality Check services.

This is where you engage with and SAP Expert to analyze your system and/or situation based on real life data from your systems or solution. After each service, you receive a service report with an executive summary, findings, and a detailed action plan to mitigate risks or improve your situation.

For SAP BW the following are applicable:

Technical Performance Optimization (TPO)

The TPO service is designed to focus on the optimization of the throughput of your database.
Some of the checks included in the service include:

Checks for major misconfigurations and hardware bottlenecks
Parameter settings, table space, expensive SQL statements
Database management (CBO statistics, Index and table storage management, Online log configuration)

For more details read the infosheet.

Business Process Performance Optimization (BPPO)

The CQC for SAP Business Process Performance Optimization is designed to ensure best performance for business-critical steps in your solution.
Some of the checks included in the service include:

Detailed technical analysis of critical process steps, evaluates and identifies potential improvement areas.
Investigation of long running process chains / failed process chains.
Investigation of long running BW queries
Parameter checks of the system for both hardware/software and suggestions for performance improvement

For more details read the infosheet

Implementation Service

The CQC for implementation analyzes your SAP system for stability, performance and optimization potential based on SAP best practices.
This would be applicable to position for the new SAP BW/4HANA system to ensure technical capabilities of the new productive environment are verified, configuration of parameters is aligned with SAP best practices, performance and stability are optimized.

For more details read the infosheet.

Data Volume and Archiving

When planning a conversion from SAP Netweaver BW 7.5 to SAP BW/4HANA and/or SAP Datasphere it should be seen as an optimal time to plan a data volume management strategy.
SAP BW/4HANA provides an important feature; Data Tiering Optimization (DTO).
This enables customers to perform data tiering, transferring data to HOT, WARM and COLD tiers respectively for the given InfoProvider, based on the data temperature.

When customers are looking for SAP BW/4HANA conversion from their existing BW system (SAP HANA or non-HANA), it has always been a requirement to reduce the HOT HANA footprint, pushing it to the WARM/COLD tier.

This is feasible for Shell conversion or Greenfield implementation but has been challenging to achieve the same using the Remote Conversion.

Watch our webcast recording to learn about this topic and best approaches.

We also have a Continuous Quality Check for Data Volume Management

The CQC for data volume management determines the type and amount of data that can be archived or deleted, as well as the corresponding archiving objects or deletion reports.
It considered as a technical blueprint that can be used as a basis for the definition and
implementation of a data volume management strategy in your company

For more details read the infosheet.

Further Support and Empowerment via SAP Enterprise Support Value Maps

Value Maps are a support and empowerment program from SAP Enterprise Support and are available to you via the SAP Learning Hub. A one-time sign in with your S User is required, and everything thereafter is free as part of your entitlements. We provide:

Prescriptive Guidance
Empowerment
Social Collaboration
Expert Access

For Data and Analytics we provide all of the services and support outlined above, and much more, as part of our Learning Journeys.
We have a dedicated Learning Journey for BW Modernization enabling you to plan out your data warehousing transformation including integration with SAP Datasphere and BW Bridge.

It also includes several other best practices including related topics of how to handle BPC aspects during the conversion.

Check out the SAP Enterprise Support value maps landing page for more and start engaging today!

Quicklinks

Exploring Datasphere & BW Bridge : Technical Insights

2024-03-06T09:40:26.319000+01:00

Abstract: This white paper delves into the technical aspects of SAP Datasphere, BW Bridge, and SAP Analytics Cloud (SAC), exploring their functionalities and how they work together to empower data-driven decision making. This white paper has equipped you with the foundational knowledge to get started. For a deeper dive into the configuration and implementation details, refer to the resources mentioned throughout the paper or explore the official SAP documentation.

Overview :

Datasphere :- SAP Datasphere provides a multi-cloud, multisource business semantic service for enterprise analytics and planning. SAP Datasphere is the latest innovation in the data warehousing portfolio of SAP. It is based on the SAP HANA Cloud and follows a clear data warehouse as a service (DWaaS) approach in the public cloud, with fast release cycles.

BW Bridge - This next-generation data warehousing solution is designed to seamlessly integrate with Datasphere, enabling organizations to leverage existing BW investments while embracing the scalability and agility of cloud-based analytics. With BW Bridge, organizations can unlock the full potential of their data assets, accelerating time-to-insight and driving business innovation.

SAC (SAP Analytics Cloud):- By integrating seamlessly with Datasphere and BW Bridge, SAC enables organizations to leverage advanced analytics techniques to uncover hidden patterns, trends, and opportunities within their data. With SAC, businesses can empower decision-makers at all levels with actionable insights, driving informed decision-making and driving business growth.

The figure, SAP Datasphere Architecture, shows a high-level architecture of SAP Datasphere.

Technical Configuration and Connectivity

We will now proceed with the technical step-by-step procedure for configuring and establishing connectivity between the Datasphere tenant, BW Bridge, and SAP Analytics Cloud (SAC).

A prerequisite for this process is having SAP BTP administration authorization on the subaccount entitled to SAP Datasphere. It's important to note that Datasphere currently offers only a cloud-based deployment option, running on SAP's infrastructure (BTP). However, it excels at connecting to and working with data from various sources, including on-premise systems such as SAP and non-SAP applications, databases, and file systems within your data center.

Here are some key points to remember:

Connectors: Datasphere provides pre-built connectors for various on-premise data sources such as SAP S/4HANA, ABAP CDS views, and generic SFTP servers.
Data Access Methods: You can choose between methods like federation (live access) or replication (copying data into Datasphere) for on-premise data.
SAP Cloud Connector: For secure communication between your on-premise systems and the cloud-based Datasphere, setting up the SAP Cloud Connector may be necessary as an intermediary.

1. Creating a Datasphere Instance on SAP BTP:

To navigate through the BTP Cockpit, follow these steps:

Access your BTP Cockpit and navigate to the "Services" tab.
From the left navigation menu, select "Service Marketplace."
In the search bar, type in "Datasphere" and select the corresponding service.
Click on the "Create" button located in the top right corner.
Follow the prompts provided by the wizard to configure the instance details, including the system owner, resource plan, and data center location.
Review your selections and click "Create" to initiate the Datasphere instance creation process."

2. Linking Datasphere and SAC Tenancy:

Before proceeding, ensure you have administrative access to both your SAP Datasphere and SAP Analytics Cloud (SAC) tenants.

Log in to your SAP Datasphere tenant.
Navigate to the System Configuration section.
Locate an option named 'Tenant Links' or a similar term related to tenant connections.
Within the Tenant Links section, you'll find a field designated for the URL of your SAP Analytics Cloud tenant.
Paste the URL of your SAP Analytics Cloud tenant into the provided field.
Save the configuration changes.

It's important to note that while this link establishes a connection between the Datasphere and SAC tenants, an SAP Analytics Cloud user will still need to create a separate live connection to access and utilize data residing within your Datasphere tenant.

3. Space Management & Storage Allocation:

To facilitate effective data management, two types of spaces must be configured within the Datasphere platform: Datasphere Space and BW Bridge Space. Follow the steps below to create these spaces and allocate storage:

Configure Datasphere Space:
- Navigate to Space Management within the Datasphere platform.
- Create a new space specifically designated for Datasphere usage.
- Allocate appropriate storage resources to this space to accommodate data processing and storage requirements.
Configure BW Bridge Space:
- Similar to the Datasphere Space configuration, create a separate space dedicated to BW Bridge functionalities.
- Allocate storage resources tailored to the needs of BW Bridge operations within this space.

Once the spaces have been created and storage has been allocated, it is essential to grant access to authorized users. This ensures that individuals have the necessary permissions to access the spaces and establish connections within them.

After creating the spaces, proceed to add users to each space, granting them appropriate access privileges. This enables users to utilize the allocated storage and establish connections as required for their respective roles and responsibilities within the Datasphere environment.

4. Installing the Data Provisioning Agent (DP Agent):

To install the DP Agent (Data Provisioning) for enabling on-premises connections within SAP Datasphere, follow these steps:

Navigate to System >> Configuration >> Data Integration >> On-Premise Agents within the Datasphere platform.

Click on the "+" icon to initiate the creation of a new agent.

SAP Datasphere supports the utilization of SAP HANA smart data integration (SDI) along with its Data Provisioning Agent to establish on-premises connections seamlessly.

In scenarios such as SAP Rise, it is advisable to raise a Service Request (SR) to SAP and provide the necessary agent details. SAP will then undertake the configuration of the connection to Datasphere.

Upon adding the DP agent, essential details such as the HANA server, port, username, etc., are automatically generated. These details streamline the configuration process, ensuring smooth and efficient establishment of on-premises connections.

5. Adding Source System's Public IP to Datasphere's IP Allow list:

Go to System -> Configuration -> IP Allow list -> Trusted IPs.
Add the source SAP system's public IP address.

6. Connecting Datasphere to Cloud Connector:

To establish connectivity between Datasphere and the Cloud Connector, follow these steps:

Create a sub-account under the Cloud Connector specifically for SAP Datasphere.

Navigate to Datasphere >> System >> Administration >> Data Source Configuration.

Obtain the necessary account information from the Data Source Configuration section, including Sub account ID, Region Host, Sub account, Location ID, and User.

Utilize this information to configure the connection between Datasphere and the Cloud Connector. This ensures seamless communication and data transfer between the two platforms.

Additionally, enable Live Data Sources within Datasphere. This feature is essential for certain advanced functionalities that require live on-premises data to traverse your network and pass through SAP's network without storage or processing.

7. SAP BW Bridge Tenant:

The SAP BW Bridge Tenant serves as a connector between traditional SAP BW systems and cloud-based analytics platforms like Datasphere and SAP Analytics Cloud (SAC). It enables seamless integration, data warehousing, user access control, and connectivity with SAC for deriving insights from SAP BW data and other sources.

To ensure smooth operation, it's imperative to define SAP BW Bridge storage before creating the SAP BW Bridge Tenant. Prior to creating the SAP BW Bridge Tenant, specify the storage requirements for the BW Bridge.

Access the Tenant Configuration section by navigating to System >> Configuration >> Tenant Configuration. Configure the size of your SAP BW Bridge Tenant according to your storage needs. After configuring the tenant size, click on the Save button to apply the changes and finalize the setup.

After configuring the SAP BW Bridge storage, the next steps involve creating a new SAP BW Bridge system and activating the BW Bridge Tenant.

Navigate to the SAP BW Bridge tab.

Create a new SAP BW Bridge system by specifying details such as Instance Name, Description, Storage Unit, and optionally enable the system for development. Upon creating the BW Bridge system, a corresponding space is automatically generated in Datasphere's Space Management. Only we need to add the users in newly created Bridge Space.

The activation of the BW Bridge Tenant is initiated by the system owner.

When a new SAP BW bridge tenant is provisioned together with a new SAP Datasphere tenant, the system owner receives a welcome email. Click the activate account button to connect to the server and set your password. You are then logged into SAP datasphere.

When a new SAP BW bridge tenant is provisioned to an already existing SAP Datasphere tenant, the first login to the SAP BW bridge tenant must be done by the user who was system owner of the SAP Datasphere tenant when the SAP BW bridge tenant was provisioned. The reason for this is that the initial administrator of the new SAP BW bridge tenant is identical to the system owner of your SAP Datasphere tenant at the time of provisioning.

Once activated, the BW Bridge Tenant is ready for use.

To access the SAP BW Bridge Cockpit, navigate to SAP Datasphere and select More >> Data Integration Monitor >> BW Bridge Space. From here, users can open the SAP BW Bridge Cockpit to manage and monitor BW Bridge activities.

8. Connectivity for ODP Source Systems in SAP BW Bridge:

To establish connectivity for ODP (Operational Data Provisioning) source systems in SAP BW Bridge. Navigate to the SAP BW Bridge Cockpit within the SAP Datasphere environment. Within the BW Bridge Cockpit, locate the Administration section and navigate to Communication Management. Under Communication Management, select the option to maintain the details of ODP source systems. Enter the relevant details of the ODP source systems, such as system name, connection parameters, and user credentials. After providing the necessary details, save the configuration to establish connectivity between SAP BW Bridge and the ODP source systems.

9. Connectivity to SAP S/4HANA :

To prepare connectivity to SAP S/4HANA within the SAP Datasphere environment.

Navigate to Datasphere >> System >> Configuration >> Data Integration >> DP Agent.

Create a TCP/IP RFC in the SAP S/4HANA system and register a server program for communication.

Obtain the program ID generated during the creation of the TCP/IP RFC in the SAP S/4HANA system. This program ID will be used later in the DP Agent connection setup.

Register the program ID to the gateway using a command. This ensures proper communication between the DP Agent and the SAP S/4HANA system. After completing the registration process, perform a test of the RFC connection to validate that the communication between the DP Agent and SAP S/4HANA system is functioning correctly.

10. Live data connection with S4HANA system:

To establish a live data connection with an SAP S/4HANA system in SAP Datasphere, follow these steps:

Navigate to SAP Datasphere >> System >> Configuration >> Integration >> Live Data Connection. Select the option to manage live data connections and choose the SAP S/4HANA system from the list. Update the live data connection details including Tunnel Name, Description, Connection Type, Location ID, Host, HTTPS Port, Client, Username, and Password. Once updated, save the connection settings.

Go to Datasphere >> Space Management and select the space designated for SAP S/4HANA. Navigate to Connections and click on "Go to Connections" followed by "Create" to initiate the creation of a new connection.

Provide the following details for the connection:

S4Application Details: SAP Logon Connection Type, Application Server Host, System Number, Client, System ID, and Language.
Cloud Connector Details: Specify whether to use the Cloud Connector, Location, Virtual Destination, Virtual Host, and Virtual Port.
Credentials: Enter the Username and Password for authentication.
Features: Enable or disable features such as Remote Tables, DP Agent, Streaming Option, Gateway Host, Gateway Port, RFC Destination, Data Flows, Replication Flows, Model Import, and Live Data Connection (Tunnel) Name.

Once all details are entered, save the connection settings to finalize the configuration.

Summary :

This white paper has explored the technical intricacies of SAP Datasphere, BW Bridge, and SAP Analytics Cloud (SAC), shedding light on how these innovative solutions synergize to drive data-driven decision-making. Datasphere, with its multi-cloud, multisource semantic service, serves as a robust foundation for enterprise analytics and planning, while BW Bridge seamlessly integrates with existing BW investments, fostering scalability and agility in cloud-based analytics. SAC complements these platforms by leveraging advanced analytics techniques to uncover insights within data, empowering decision-makers at all levels.

Through detailed technical configurations and connectivity procedures outlined in this white paper, organizations can harness the full potential of these SAP solutions. From setting up Datasphere instances to establishing live data connections with S/4HANA systems, each step is meticulously laid out to facilitate a smooth implementation process. Furthermore, the paper delves into the creation of spaces, installation of DP Agents, and connectivity to ODP source systems and SAP S/4HANA, providing comprehensive guidance for users.

SAP IQ NLS-The Cold Storage Solution for SAP BW/4HANA

2024-03-08T15:55:31.522000+01:00

Introduction –

As we know B systems contain a large volume of data that is only accessed rarely. The data is either never or rarely needed in Data Warehouse processes or for analysis. The main challenge of implementing a multi-temperature memory strategy is to seamlessly integrate the warm and cold memory areas and to make these areas invisible to the outside, in order to ensure that all required functions are applied to this data. SAP offers various solutions, which help to reduce TCO SAP IQ NLS is one of them to reduce load by cold data

SAP IQ based Nearline storage can be used to offload the data and reduce main-memory data footprint further. Typically, the data is sliced based on the time dimensions or it can be completely moved into the cold storage DB. The read access to IQ NLS is in most cases much faster than READ access to the traditional databases. The unique advantage of such a native solution is that the performance of the BW query that requires the data from the Sybase IQ store can be optimized using HANA SDA (Smart Data Access). Smart data access enables remote data access as if they are local tables in HANA without copying data into HANA. It is highly optimized, high-performance and decision-support server designed specifically for mission-critical business intelligence, analytics, data warehousing and Component Integration Services within SAP .Sybase IQ provide direct access to relational and non-relational databases on mainframe, UNIX, or Windows server. SAP IQ (formerly known as SAP Sybase IQ or Sybase IQ; IQ for Intelligent Query) is a column-based, petabyte scale, relational database software system used for business intelligence, data warehousing, and data marts

Its primary function is to analyze large amounts of data in a low-cost, highly available environment. SAP IQ is often credited with pioneering the commercialization of column-store technology. At the foundation of SAP IQ lies a column store technology that allows for speed compression and ad-hoc analysis. SAP IQ has an open interface approach towards its ecosystem. SAP IQ is also integrated with SAP's Business Intelligence portfolio of products to form an end-to-end business analytics software stack, and is an integral component of SAP's In-Memory Data Fabric Architecture and Data Management Platform.

Architecture :

Below diagram is sap IQ data base Architecture -

Communication between BW and SAP IQ via NLS interface

Pre-installation Tasks:

Check for Operating System Patches- check snote - 3060790
Increase the Swap Space- Recommended minimum swap space is 1 GB.
Check Port Availability for SAP IQ Cockpit - HTTP Port: 4282 HTTPS Port: 4283 ,RMI Port: 4992 ,TDS Port: 499
Verify Network Functionality- verify that the server where you plan to install SAP IQ can use TCP/IP to communicate with other devices on your network.
Disable HugePages - Remove the HugePages options from /etc/ sysctl.conf and restore the kernel to the default configuration
Transparent HugePages - Disable Transparent HugePages to avoid SAP IQ performance problems.
Set the Kernel Parameters-Set the number of available semaphore identifiers to at least 4096.
Create the SAP IQ Account
Download Installation Files login on sap market place and download require software based on you infrastructure

Installation -

The below flowchart gives you an overview of the major tasks to install and implement a SAP IQ system on an Azure Linux VM. Some configuration and post steps need to be done by BW team.

Install SySAM

Given below are step to install SySAM

Unselect un-relevant component and enter option 11 SySAM License server

Choose 1 Typical

Now you can see below directory.

Install SAP IQ Server

Start IQ

Command : start_iq -n utility -x "tcpip{port=34238}" -su *****

Installing client on BW dB and App server

Install SDA

Check all environment variable as per IQ installation document

Configuration

Logon to BW system and update RSADMIN table using report SAP_RSADMIN_MAINTAIN

Create DBCO Connection

Transaction DBACOCKPIT

Add

And test connectivity

References –

SAP IQ Installation and Update Guide for Linux (SAP IQ 16.1 SP 05 Document Version: 1.0.0 – 2023-12-15)

https://community.sap.com/t5/technology-blogs-by-sap/managing-large-sap-bw-on-hana-systems-sap-hana-enterprise-cloud-hec/ba-p/13363789

SAP IQ - Wikipedia

How to Debug DTP Filter Routine

2024-03-08T15:56:55.611000+01:00

Dear SCN Community ,

I have been going through the SCN Blogs for Debugging DTP Filter routines where I found to put a BREAK-POINT in code which is not possible in a Production Environment where a complex routine needs to be simulated . For this case I have followed an approach which will be helpful :

Here we will discuss a simple approach to debug a DTP filter routine which doesn’t need a hard coded break point.

1. Go to the DTP and in Execute Tab select Processing Mode as Serially in the Dialog process (for Debugging) – Expert Mode (To make sure no data gets loaded once debugging is completed).

2.Now go to class CL_RSBC_FILTER_CMD and method PROCESS_SEL_ROUTINE. We will see a standard piece of code with LOOP AT l_t_varseltab . Put a debug point at the line .

3.DTP filter routines are a type of Form with naming convention C_<FIELD_NAME>.In the above snip put a debug point on the PERFORM statement. PERFORM Key word is used to call the form.

4.Now in DTP screen, put /H in the Transaction screen and press enter. Now click on simulate.

5.If there are multiple filter routines in the DTP, debugger will call routines 1 by 1. Once the variable is picked up by debugger for which we need to debug the code, go inside the perform statement. We will be landed on the DTP filter code which we wanted to debug. Hence we can debug the code in a Production Environment in a simple and easy approach.

Assign points if its useful for you ! 🙂

Best Regards,

Suraj Grewal

Getting Started with SAP BW Request Housekeeping

2024-03-17T20:18:34.718000+01:00

Hi BW enthusiasts!
In this blog post, I would like to dive deeper into Housekeeping, an area sometimes a bit neglected in BW-systems. The focus here is actually on BW Request Housekeeping.

To start with, it is important to understand which kind of request management concepts are available and which one applies for your specific SAP BW environment:

1) The classic one: Request Status Management (RSSM) is the original concept from SAP NetWeaver BW and there in use for a long time already for all classic InfoProviders CUBE, ODSO, IOBJ and DEST.
The RequestID is based on a prefix and a following 25 characters long randomly generated unique identifier. Typical prefixes are REQU_* for InfoPackage requests, DTPR_* for DTP requests, and ODSR_* for ODSO activation requests.

2) The new one: Request Status and Process Management (RSPM) is the revised concept for ADSOs in SAP NetWeaver BW 7.50 on HANA. In SAP BW/4HANA RSPM is used for all InfoProviders (ADSO, IOBJ, DEST) and RSSM is decommissioned.
The Request ID is now called Request TSN (Transaction Sequence No), which is a timestamp and is derived from the ODQ Transaction ID.

As a first summary the focus of your individual BW request housekeeping concept is either on RSSM processes/tools or RSPM processes/tools. OR, in case you run BW on HANA, then often both approaches apply as classic objects and ADSOs often coexist side-by-side.

WHY bothering with BW request housekeeping?
In general, request meta information (all details your find in a request monitor like timestamps, runtime, package sizes, record amount, warnings etc) is stored in BW backend tables. These tables grow continuously based on the daily data processing activities. If housekeeping is not done, it will have a negative impact on the…

overall system size,
data management performance (loading, activation, delta determination etc.),
waiting time for InfoProvider administration in Tr. RSA1/RSMNG, or BW/4HANA Cockpit, or
preparation of a move to BW/4HANA or BW Bridge. Leveraging the SAP transfer tools (BW/4HANA inplace or remote approach / BW Bridge remote approach) requires the number or requests in classic InfoProviders to be reasonable (<1.000), see also warnings in your Readiness Check.

WHAT is done during BW request housekeeping?
Request Housekeeping deletes the request details (meta data) from the core runtime BW backend tables. This means, details of the request history will be removed which is older than a customer specific number of days. However, no need to be afraid: The real BW data is not deleted - master data and transactional data residing in the InfoProviders is NOT affected! Housekeeping only shrinks the request history behind them!
Also, good to know: During the housekeeping process, the objects are not locked, and they are available for loading/reporting without restrictions. Still, it is clear it is better to run the cleanup not during business hours.

As you see in the figure below, the housekeeping process removes the detail data from the original tables and moves it to housekeeping tables in a compressed form. If that is not enough (normally however this is not the case), you can even move all to an external archive (RSSM details here, for RSPM see SAP notes 2867347 and 2980697).

HOW to analyze the status quo?
RSSM: Tr. RSREQREDUCE provides the full list of InfoProviders with critical no of requests.
The same information is provided by table RSMDATASTATE_EXT.

RSPM: In SAP BW/4HANA, leverage the Cockpit apps for Request Management in ADSOs, InfoObjects or Open Hub Destinations and sort the column of 'Successful Requests' properly.

In SAP BW on HANA it is a little more challenging as these apps are missing. You can either use the new CDS-based technical content (aka "statistical analysis"). In Tr. RSRT following sources are available which both provide a key figure "No of successful requests" per ADSO:
2CRVCREQUEST/!2CRVCREQUEST or 2CRVCREQUEST/2CRVCREQQRY

The second BW on HANA option is to run following SQL statement (e.g. in Tr. DB02-SQL Editor) to get the ADSOs in most requests in descending order:
SELECT DATATARGET, COUNT(*) NUM_OF_REQUESTS
FROM RSPMREQUEST
GROUP BY DATATARGET
ORDER BY NUM_OF_REQUESTS DESC

HOW to run BW request housekeeping?
RSSM Request Housekeeping can be triggered and scheduled from Tr. RSREQREDUCE based on the two reports RSSM_REDUCE_REQUESTLIST and RSSM_AUTODEL_REQU_MASTER_TEXT. Thorough documentation here.
For RSPM, SAP provides report RSPM_HOUSEKEEPING which can be scheduled via Process Chains (in BW 7.5 as ABAP variant, in BW/4HANA there is a new dedicated variant). Thorough documentation here.

WHICH Requests can be removed?
You can clean up a request if it is not available as physical entity. This means, it is not stored in an InfoProvider table anymore (e.g., in an ODSO/ADSO inbound queue to change log table).

To start with, all deleted requests can be removed from all InfoProviders.
In general, all requests can be removed from following InfoProviders: ODSO/ADSO (type direct update), IOBJ and DEST
Requests can also be removed if they meet following prerequisites:
- ODSO/ADSO (type standard), CUBE/ADSO (type data mart)
  DTP loading requests can be deleted from the inbound queue if they are activated / compressed already.
- ODSO/ADSO (type standard):
  Change log requests can be removed if they have been deleted from Change log. This is only possible if the delta has been provisioned to all connected data targets.

Finally, HOW to set the whole process up properly?

Define your individual housekeeping strategy. This means you have to make a decision how many days of request history should be kept in your BW landscape.
For RSPM: Depending on your SP-level, check whether some recommended SAP corrections need to be installed (see SAP note 3137171).
Test housekeeping on a few objects (e.g. 1 ODSO/ADSO, 1 IOBJ, 1 DEST).
Run housekeeping once for the whole DEV-system (e.g. with > 1000 days).
For RSPM: Transport SAP notes (2) to the next system.
Run housekeeping in tiers until you reach the defined limit of of days (1), depending on the age of the system, for example 1st run > 1500 days, 2nd one > 1000 days, then >800 days… In a large system each run could take a few hours.
When the defined limit (1) is reached: Schedule housekeeping, e.g. for RSPM in a weekly process chain like the following one:

Useful sources:

RSSM Housekeeping https://help.sap.com/docs/SUPPORT_CONTENT/bwdabc/3564975514.html
RSPM Housekeeping
- SAP note 3137171 - Housekeeping for Request Administration tables (RSPM* tables)
- Help https://help.sap.com/docs/SUPPORT_CONTENT/bwdabc/3361383396.html
- BW/4HANA release notes

SAP Datasphere - Space, Data Integration, and Data Modeling Best Practices

2024-04-04T02:06:22.184000+02:00

Motivation:

SAP Datasphere is a powerful all-in-one business data platform. It provides the technology foundation for creating a business data fabric, delivering meaningful data with context and logic to every user. It combines a flexible data fabric architecture with a robust platform for integrating multiple data sources, performing complex analysis, and modeling.

While these capabilities offer valuable insights, the complexity of data integration and modeling can affect user experience. However, strategic design choices can ensure that SAP Datasphere performs optimally. This article shares best practices and tips to maintain smooth data flow, prevent performance problems, and enhance efficiency. It helps you set up your SAP Datasphere space, integrate data, and model effectively while encouraging creativity as a data engineer, modeler, or architect.

1. Managing Your Datasphere Spaces:

What is the Space and What are the benefits?

In SAP Datasphere, a space is a secure area set up by an administrator where members can handle data. It functions like a self-contained data warehouse, residing within the SAP HANA Cloud database, tailored for specific departments, Line of Business (LOB) units, data domains, project teams, or individuals. Administrators are responsible for creating one or more spaces, managing memory and disk storage allocation, assigning members (users), setting priorities and statement limits, establishing source connections, and acquiring data and models. In SAP Datasphere, everything happens within these spaces to keep things safe. Data and models in space stay private unless shared with other spaces or made available for use by BI tools or other systems.

What are the Space types and Important Configuration Parameters?

Space Type: SAP Datasphere: Required Space type and the Administrator can only create spaces of type SAP Datasphere. Multiple spaces can be created and configured.
Optional Space Type: SAP Datasphere(Embedded Data Lake Access): The Administrator must select a space connecting to the embedded HANA data lake. Checkbox setting: Use This Space to Access the Data Lake. Only one space can have access and can only write data to the embedded SAP HANA data lake.
Optional Space Type: SAP BW bridge: SAP BW bridge provisioning generates a dedicated space for exposing BW bridge objects as remote tables to other SAP Datasphere spaces, allowing the connection of a single SAP BW bridge system to SAP Datasphere.

Important Configurations Parameters

Enable Space Quota Disk(GB) and Memory(GB)	Allocate disk storage (GB) and memory(GB) allocation for the space. There is no best practice it is based on the requirement/demand. however generally Disk: Memory(RAM) ratio can be 100:40-50 Disk 256 GB : Memory(RAM) 120 GB Disk 1024 GB : Memory(RAM) 480 GB Disk 4096 GB : Memory(RAM) 1800 GB Memory storage value cannot exceed the amount of disk storage space limit. Default: Enabled A disabled option lets space consume all available disk and memory resources in your SAP Datasphere tenant. (Not recommended)
Lock or Unlock Your Space	SAP Datasphere locks spaces exceeding memory or disk storage limits to prevent resource overload. Users can then free up space by deleting data, or an administrator can assign additional storage.
Space Priority (1-low, 8-high)	The setting helps SAP Datasphere to prioritize space execution (1-low, 8-high).In situations where spaces are competing for available threads, those with higher priorities have their statements run before those of spaces with lower priorities. e.g. Space gets higher priority on which you have live and operational reports compared to historical reports.
Workload Configuration (Custom): Total Statement Thread Limit	Set thread limit between 1% and 70% (or equivalent number) of total tenant threads. Too low impacts statement performance, and too high impacts other spaces.
Workload Configuration (Custom): Total Statement Memory Limit	To avoid OOM statement errors. Define a memory limit (between 0 for no limit and the total available tenant memory) for statements running in this space. This setting balances performance for this space with a potential impact on memory available for other spaces in your SAP Datasphere tenant. To prevent a space from encountering a general out-of-memory situation, you can establish a memory limit for the space, such as 90%. This prevents a statement within the space from causing a global out-of-memory issue and interrupting other processes.
Expose for Consumption by Default	Allows default exposure of all new space views (Graphical, SQL, Analytical Model) while modelers can adjust individual view consumption via the "Expose for Consumption" switch
Time Data Time Tables and Dimensions	It creates date-time tables and dimensions. You can generate in one space and create required foundation dimension date-time models and share them with other spaces.

Space Organization Scenarios/Examples:

1. Line of Business (LoBs)

Multiple spaces can be created like Sales, Marketing, Supply Chain, Finance, HR, Service, Analytics, IT Management, etc. To follow Central governance, separate space for Admin and Permissions for Data security (Data Access Control) is recommended.

Administration Space:

Only admin users will be members for authorization and monitoring.
Auditor to access audit logs and tenant activities.
Admin/Security/Developer creates DACs and assigns them to data builder views to enable data security (row level security).
Specific restricted views are shared with the LOBs spaces (e.g. Sales, Marketing). That way only specific business data with row-level security is available to consume for the business users.
Benefits:
- Granular Control: Limits access to authorized personnel (e.g., Business or Security admins) who manage specific values.
- Developer Flexibility: Enables developers to work efficiently without authorization restrictions.
- Secure Business Consumption: Provides secure access for users who only need to consume data, ensuring they see only relevant information.

Permissions Space:

A centralized approach with only assigned users will manage the authorization values table for the data access control for all LOB spaces.
Protection against unauthorized access and value maintenance from common users.
Share and expose authorization value tables/views to Administration or IT Space.

Centrazlied IT Space:

A centralized IT space can be created with connection to multiple sources SAP S/4HANA, SAP BW, SAP SuccessFactors, SAP Concur, Salesforce, Google BQ, etc.
Data is made available as remote tables or replicated tables and modeling using a data builder.
Consume the Permission space shared table and create the permission views. Create a Data Access Control(DAC) object and Assign it to view (e.g. Sales view).
Share the views with different LOB spaces like the Sales view with the Sales department Space.

2. Departments

Similar to LOBs space concept with centralized governance. Create multiple spaces for the key departments in your organization like IT, Finance, Marketing, Operations Management, HR, Sales, Purchasing, etc., and a dedicated Permission space for data security.

3. Data Domains

Create spaces for different data segments like Customer Data, Product Data, Sales Data, Financial Planning & Analysis (FP&A), Social Data, Streaming Data, Financial Data, HR Data, and Manufacturing Data. Enable data sharing among these spaces to encourage reuse while ensuring sensitive data is protected using methods like data masking and authorization. The PERMISSION space authorization table, managed by designated security and administrative users, controls access rights for sharing data across these spaces.

4. Single SAP Datasphere tenant for development and testing using the Space concept.

Leveraging the Spaces concept makes it feasible to utilize a single SAP Datasphere tenant for both development and testing (Dev/Test) purposes. However, it's advisable to adopt a three-tier tenant landscape for Development, Testing, and Production scenarios. Using at least two distinct SAP Datasphere tenants for your data landscape is recommended. This strategy ensures a distinct segregation between your development and testing (Dev/Test) environment and your production environment. The Dev/Test tenant provides a dedicated platform for constructing and validating data models and transformations, safeguarding your production data integrity as the ultimate source of truth.

It can used for small deployments and the initial phase of the project.
Not an ideal approach from the object transport and lifecycle management perspective.
Manual import/export of the objects (CSN/JSON) files across the spaces.
From SAP Datasphere Dev/QA tenant to PROD tenant, transport content network is used.

Example:

5. With the SAP BW bridge

Customers with investments in SAP BW and BW/4HANA who aim to harness the advantages of cloud-based data warehousing can opt for the SAP BW bridge feature. Enabling these optional features in SAP Datasphere results in the creation of a dedicated space within the tenant for importing BW bridge objects as remote tables, which can then be shared with other spaces. Unlike the standard SAP Datasphere space type, creating data builder objects in the SAP Datasphere BW Bridge Space is not permitted. Importing remote tables is allowed in the BW bridge space, and it's advisable to maintain a separate space from a governance perspective. In this setup, space IT BW Models automatically generate SAP Datasphere objects through the entities import feature for corresponding BW queries, Infoproviders, aDSOs, etc. The created objects can be shared with the target Line of Business (LOB) space via cross-space sharing capabilities. Consequently, original BW bridge objects belong to the BW bridge space type, while created objects are part of the IT BW Model managed space.

Example:

General Space Guidelines:

Multiple spaces: It is advisable to create multiple spaces within your tenant for efficient organization of data and resources.
Segregate Access with Dedicated Spaces: Establish separate spaces for administrator, IT, and security permissions, along with multiple spaces for departments, projects, Lines of Business (LOBs), data domains, etc. This practice aids in controlling access to sensitive data and maintaining stability across various environments for distinct purposes.
Maximize Cross-Space Sharing for Reusable Data and Models: SAP Datasphere facilitates sharing tables, views, and models across spaces within the same tenant, fostering reusability and mitigating data duplication. For instance, refrain from accessing or replicating the same SAP S/4HANA CDS view or tables like ACDOCA into multiple SAP Datasphere spaces, as this can strain your SAP S/4HANA system and lead to data duplication within SAP Datasphere. Instead, adopt a strategy of replicating once and consuming N times across spaces
Considerations for Space Restrictions: Direct sharing of data source connections, data flows, transformation flows, replication flows, and task chains between spaces is not supported. If necessary, these elements must be recreated within each space individually. Additionally, objects cannot be copied or pasted from one space to another. Importing and Exporting data builder objects in CSN/JSON files.
Naming Conventions for Spaces are Crucial:
- Space name can be changed at any time, however, Space ID cannot be changed later.
- Avoid using reserved keywords(Refer to Rules for Technical Names) such as SYS, PUBLIC, CREATE, SYSTEM, DBADMIN, PAL_STEM_TFIDF, SAP_PA_APL, Datasphere_USER_OWNER, Datasphere_TENANT_OWNER, Datasphere_AUDIT_READER, Datasphere_GLOBAL, and Datasphere_GLOBAL_LOG. Additionally, refrain from using the prefix SYS or prefixes like Datasphere and SAP_ in space IDs, unless explicitly advised. Moreover, keywords reserved for the SAP HANA database cannot be utilized in a space ID. (Refer to Reserved Words help document)
- Examples(Space ID: Space Name): MASTER_DATA: Master Data, SUPPLY_CHAIN: Supply Chain, LEGAL: Legal, SALES_AND_OPERATIONS: Sales and Operations, CENTRAL_IT_SPACE: Central IT Space, PERMISSIONS: Permissions, HUMAN_RESOURCES: Human Resources, ADMINISTRATION: Administration, GOVERNANCE: Governance, SPEND_ANALYSIS: Spend Analysis, FINANCE: Finance, MARKETING: Marketing, CUSTOMER_DATA: Customer Data, CONFIDENTIAL: Confidential, *_DATALAKE: * Data Lake, OPERATIONAL_ANALYTICS: Operational Analytics etc.
- Cross-space sharing scenario: Problem: When sharing models between spaces A and B, users in space B may not see the shared model in the model list. Instead, it appears as a table or view in the data modeling editors, losing context and affecting user decisions. This can be problematic if the shared model includes a calculated column and relies on data restrictions for detailed reporting. When a modeler in space B uses the restricted column in a selection criterion, the calculation needs to happen before the restriction, potentially causing severe performance issues and memory consumption. Solution: To avoid this, consider naming calculated measures with "CM_" prefix and calculated dimensions with "CD_" prefix to indicate their nature to other developers.

2. Data Integration:

SAP Datasphere offers both remote and replication connections to various source systems. Comprehensive details on supported connection types are available in the SAP Help documentation. Not covering in-depth the data connectivity and configuration as it's not the focus of this article, providing quick high-level guide reference and then shifting to the data integration best practices.

Connection Types Overview: The overview table provides a quick reference for key functionalities supported by various source connection types in SAP Datasphere. Information is focused on functionalities relevant to data access and manipulations. Use the required column filter to select the Connection Type, Remote Tables, Replication Flows, Model Import, etc. Below example: Selected connection types Generic JDBC, Google BigQuery, ABAP, and S4 and next filtered the column Remote Table(yes). Likewise based on the source connection type, this table will provide the information if the source is supported with a remote table (yes, no), Replication Flows (source, target), Data Flows(yes, no), and model import (yes, no).
Preparing and Configuration Connections: The overview lists table clarifies prerequisites for the connection types indicating if a specific connection requires a middleware component like the DP Agent (Data Provisioning Agent) or Cloud Connector (CC) for communication or supports direct connection (without any additional software component). Below example: To enable data integration features such as Remote Table, Replication Flow, or Data Flow, specific connection types require different configurations. For ABAP, SAP S/4HANA, and ECC connections, installation and configuration of DP Agent are necessary. However, for utilizing the Replication Flow with SAP S/4HANA Cloud connections, a Cloud Connector (CC) isn't necessary. Nonetheless, for other connection types, it's crucial, as indicated in the image below. This table serves as a convenient guide to pinpoint the software prerequisites essential for various data integration functionalities.

Data Integration Options and Recommendations:

Integration Feature	Remote or Replicate Data	Use cases, Recommendations
Remote Table	Remote	Access data virtually for real-time operational reporting without replication or duplication. Prefer ABAP CDS views like I_CUSTOMER_CDS and C_SalesDocumentItemDEX_1 over database tables like KNA1 and VBAP for efficient data access. Use a single connection per source system to minimize redundancy and complexity. Deploy remote tables and use cross-space sharing for consistent access and scalability. Utilize existing user authorizations for access control from the source system (HANA,BW or S/4HANA) . During table configuration specify the semantic usage like Dimension, Fact, Hierarchy, etc. Select the required attributes and use the filters to get the best performance. Note: Filtering is not supported for SDA-based connections. Understand the capabilities of SAP HANA SDI adapter SQL to push down filters for optimal performance. Keep in mind that the SDI ABAP Adapter doesn't support pushing down filters currently. Ensure statistics for remote tables are up-to-date, especially when joining or aggregating them, to optimize performance and reduce memory consumption. Trigger statistics runs directly through the data integration monitor within Datasphere. Monitor SQL statements using the remote query monitor. If the required filter condition isn't in the SELECT statement, it retrieves all data and applies the filter afterward, leading to increased memory consumption and decreased performance. Choose between replicating remote tables via snapshot or real-time replication based on your requirements.
Remote Table	Replicate(Snapshot, Real-time replication)	Pull and store on disk (warm tier) for better performance instead of remote data. Recommended for the frequently accessed CDS views/tables and requires efficient performance like master, analytical, and fact data. Recommended schedule table snapshots (full load) where the data does not change regularly e.g. master data or it does not support real-time replication. The Real-time replication for initial load and real-time delta updates using trigger-based change data capture (CDC) for the data with higher volume and regular updates like transactional or fact data. Remove unnecessary columns, and apply filters to minimize the data volume loaded in your remote table. For replicating a larger volume of transactional views/tables, recommended to create partitioning for supported connection types and prevent out-of-memory errors or high-memory tenant usage. Further, improves performance by activating Table Services: Store Table Data in Memory, store table data directly in memory (hot tier). By default, table data is stored on disk (warm tier). Note: Replication is not available if the connection of your remote table is configured as data access: Remote Only.
Replication Flow	Replicate	Offer Extract and Load(EL) for mass data replication from multiple entities from one source use cases. Filter, projection capabilities and accomplish ELT through the Transformation Flow. SAP Note: 3297105 - Important considerations for SAP Datasphere Replication Flows. SAP Note: 3360905- ABAP Integration - Performance when Replication Flows. Replication Scenarios: Data inbound (Source to Datasphere), Data outbound (Datasphere to Target), and Pass-through scenario (Source to Target). Initial data load as well as delta load with parallelization. The default delta load interval is 60 minutes. You can set the delta load-interval between 0-24h:0-59m. The maximum allowed value is 24 hours 0 minutes. Enter 0h:0m for immediate replication. Cloud-to-cloud replication scenarios can be streamlined without the requirement of installing and managing an on-premise component. For instance, there's no necessity for a component like the Data Provisioning Agent for HANA SDI for Replication Flows.
Data Flow	Replicate	Provide ETL functionality for creating an inbound layer with multiple sources directed to a single SAP Datasphere table, with comprehensive transformation capabilities. Prioritize filtering at the beginning of the flow, and use Python script transformations for complex calculations like CKF, RKF, etc. Avoid heavy transformations or complex calculations on remote table sources; consider replicating data before applying them. If facing performance issues with Data Flows, consider dividing them into smaller flows executed sequentially using a Task Chain. If you encounter out-of-memory situations, utilize the Dynamic Memory Allocation.
Persistent View	Replicate	Persist complex logic to pre-calculate and aggregate view results for faster data access and a better user experience. When a view is complex and data-intensive, it uses a lot of memory. Similarly, subsequent views and calculations require more resources. It's best to persist in it for improved performance. Decide whether to persist a view or remote tables based on your performance and data storage needs. Remote tables are exact duplicates of the source, while replicating a view only persists and replicates the view's data. Introduce intermediate view persistencies instead of directly persisting the top view. Review the entire scenario to identify views that aggregate significant data and are potentially utilized in other contexts. These views are excellent candidates for view persistency implementation. Sometimes, dividing a large view's logic into smaller views and persisting them at a lower level is necessary to avoid out-of-memory situations. This can optimize data retrieval and calculations by using internal HANA tables. Run Mode: Performance-Optimized (Recommended) View persistence partitioning can significantly reduce memory consumption by retrieving and storing data in smaller chunks. Ensure filters used for partitioning can be pushed down to the remote source for optimal performance. Note that filter pushdown isn't supported by the SDI ABAP Adapter, affecting connections like SAP ABAP, BW, ECC, and S/4HANA On-Premise. Refer to Reducing Memory Consumption.
ETL tools	Replicate	Use of SAP and Non-SAP ETL tools like SAP SLT, SAP Data Services, SAP Integration Suite, and Precog to replicate data via SAP Datasphere Open SQL Schema.

Choosing Between Remote Tables and Data Replication in SAP Datasphere:

The decision between using remote tables (data federation) and data replication in SAP Datasphere depends on several factors. Here's a breakdown to help you choose the best approach for your operational reporting needs:

Use Remote Tables (Data Federation) When:

Limited Data Pull: You only need a small subset of data from the source system (HANA Calc. Views or S/4HANA Analytic Queries).
Pre-Aggregated Data: The data in the source system is already aggregated to reduce network traffic and latency.
Real-Time Reporting: Business needs reports with the most up-to-date data. Remote tables provide near real-time access.
Filter and Variable Usage: You can restrict data retrieval using filters and variables in your reports, further reducing the amount of data transferred.
Performance Considerations:
- Location: The data center location of both the source and Datasphere can impact performance. Geographically close locations minimize latency.
- Column Selection: Selecting fewer columns reduces data transfer size.
- Aggregated Data: More the aggregated data is, the better the performance.
- Filtering: Specifically on the columns like date, company code, sales org, plant. Avoid filtering on calculated dimension columns.
- Join, Union, Order By Use the join condition on the ID/key columns rather than a description, and specify columns in Order By with ASC, DESC explicitly.
- Data Volume Size (Rows and Columns): A smaller number of records retrieved improves performance.
- Optimize Queries at the Source: When creating views, and queries in S/4HANA, BW, HANA, Hyperscaler, etc. optimal performance on the source side helps overall performance.

Use Data Replication When:

Modeling and Operations: Datasphere needs to perform modeling, transformations, joins, unions, or create layered data marts. Data needs to be persisted for these operations.
Intensive Logic Processing: Business logic requires complex calculations or transformations best done within Datasphere.
Performance vs. Freshness Trade-Off: While replicated data might be slightly delayed compared to remote tables, report performance can be optimized.
Operational Business Needs: Consider the criticality of real-time data vs. performance for reports.

General Guidelines:

Start with Remote Tables: For quick operational reports and less data transfer, use remote tables. They're real-time and reduce network traffic.
Assess for Replication: If reports need complex logic or performance is key, think about replicating data to Datasphere.
Use ABAP CDS Views Instead of Direct Tables: Access data efficiently from SAP S/4HANA systems with ABAP CDS views. They offer a standard way to expose data and work with real-time integration via Change Data Capture (CDC).
Prioritize ABAP CDS views with data extraction and CDC over ODP Data Sources: Use direct connection via ABAP pipeline engine and delta handing using Change Data Capture engine. Here SDI ABAP Adapter (DP Agent) is not required.
Consider Data Profiling: Profile your source data to understand its structure and quality before integrating data. This helps prevent issues during integration.
Secure Sensitive Data: Protect sensitive data during integration by masking or anonymizing it, and following security best practices
Remember: The key is to balance data freshness, report performance, and business requirements.

3. Data Builder Modeling:

SAP Datasphere offers functionalities for data modeling, and here are some best practices to follow for optimal performance, maintainability, and reusability:

General Recommendations:

SAP HANA Cloud Modeling Best Practices Apply to Datasphere as well: Since HANA Cloud powers SAP Datasphere, established best practices for HANA data modeling are directly applicable.
Embrace Reusability and Avoid Giant Views: Instead of monolithic views, create a library of smaller, well-defined basic, intermediate reusable views. These reusable pieces can be put together to make more complicated views, making it easier to work with and maintain them. Large, single views can be cumbersome and impact performance. Design smaller, focused views that cater to specific purposes.
- Example: create separate reusable views with Semantic Type: Dimensions for the master data, Text for the master data text, Hierarchies data, Fact data, etc.
- Use space-cross sharing and re-use the views with other spaces.
Strategic Filtering: Instead of using inner joins for filtering, apply WHERE clause filters on joined datasets. This reduces unnecessary data processing.
Simplify Logic: Keep your data model logic as simple as possible. Complex transformations might be better handled in separate transformation steps within transformation flows or data flows.
Hierarchical Modeling: Utilize hierarchies within your data model to represent relationships between master data elements. This improves data governance and simplifies queries.
Independent Associations: Model dimension, and text views that are associated with master data independently. This allows for reusability across different functional areas.
SQL vs. Graphical Views: For complex business logic, consider using SQL views. Graphical views might be more suitable for simpler models or improved user experience in reporting tools.
Clear and Consistent Naming Conventions are Crucial: Guide.

Layered Modeling Approach for Better Performance, Organization and Management:

Don't underestimate the power of a well-defined modeling approach in SAP Datasphere! Layering your data architecture from the start (even though it's a familiar concept in data warehousing) lays a solid foundation for efficient data integration, reusability, and long-term maintainability. This approach organizes data into distinct layers (inbound, harmonization, optional propagation, and reporting) with specific purposes, simplifying data management and minimizing complexity in the long run. Here's a breakdown of the layers:

Layers	Purpose	Best Practices
Inbound Layer (Remote/Acquire Data, Data Projection )	Ensure data accessibility through federated or replicated formats. Utilize data integration functionalities such as Replication Flow, Data Flow, or alternative tools to ingest data into SAP Datasphere's OpenSQL Schema. Employ methods like remote table snapshots, real-time replication, and scheduling via task chains. Develop inbound layer views with 1:1 mapping from the source, implementing filters and projection only as needed while refraining from any unnecessary data manipulation	Keep a direct column mapping(1:1) between the source tables(CDS views) and the view for faster data transfer. Avoid making unnecessary changes/conversions to data in the view. Filter data as soon as possible, preferably in remote or replicated tables, to reduce processing in Datasphere. Be careful when using JOINs, UNIONS, and WHERE clauses in federated views, especially with the SDI Adapter. Pushing down these operations might not be supported, causing Datasphere to process the entire table data, which could slow things down.
Harmonization Layer (Reusable Views & Data Standardization)	Use layer to create reusable views on top of the inbound layer views. Standardize the inbound data with common semantics. Projection views with distinct column renaming (BUKRS, Comp_code, 0COMP_CODE), and constant filters. Additionally, you can create a Data Access Control (DAC) to limit the specific dataset or use it in the next layer.	Only choose the columns you need. (Don't use SELECT ) Filter early: Apply filters before joining to handle smaller datasets. Be smart with joins: Use WHERE clauses in join conditions for efficient filtering. Always specify join cardinality and select the appropriate join type* based on the scenario: Inner Join: Retrieve rows with matching values in both tables. For example, when joining tables like VBAK with VBAP (Sales Order), LIKP with LIPS (Deliveries), VBRK with VBRP (Billing), EKKO with EKPO (Purchase Order), etc. Left Outer Join: Retrieve all rows from the left table and only matching rows from the right table. For example, when joining tables like VBAP with VBRP, EKPO with ACDOCA, PRCD_ELEMENTS, etc. Think about unions: Sometimes, using UNION nodes is better than other joins. Optimize your joins: Use integer or key columns for joins to speed things up. Use aggregation nodes to deal with duplicate data. Make sure filters and formulas work with the same data types. Try using NOT EXISTS instead of NOT IN for better performance. Keep things simple: Avoid complex functions whenever you can. Limit the number of joins (and join condition), especially complicated ones. Explore different ways to do temporal joins for faster results. Avoid making restricted columns based on calculated ones. If you can, prioritize aggregation over calculations to make things faster.
Propagation Layer (Joins, Combines and Aggregates)	Utilize objects from the Inbound and Harmonization layers for standardized and consistent business data. Create views using joins, unions, calculated columns, aggregations, and dynamic filters as needed. Model dimensions, text, and hierarchical views. For optimized performance, persist complex views or materialize them into separate data marts for specific analytics. Access them through Analytic models or expose them via public OData API for third-party BI clients, tools, and apps, or ODBC if the Expose for Consumption switch is enabled	Same-as-above.
Reporting Layer ( Business Consumption Views)	Leverage Fact views from the Propagation layer to create unified consumption entities like Analytic Models(THE go-to analytic consumption entity), the main choice for analytics. Use them in SAC or Excel Add-in. For other tools, make the OData service available for Analytic Models. Include features like RKF, CKF, and exception aggregation. Support source/filter variables, time-dependent dimensions, texts, currency conversion, and analytical preview. The HANA engine optimizes dimension association through pruning, saving time during the JOIN execution. Apply DAC to add extra reporting restrictions based on user access.	Improve performance by using filtered and harmonized data from lower layers like the Propagation Layer in your Analytic Model. Enhance security by applying data filters, such as where conditions, variable prompts, and data access controls, to restrict sensitive data. Increase flexibility and reusability by defining variables within the Analytic Model to represent dynamic values or parameters for different analysis scenarios. Optimize data usage by selecting only the necessary columns (measures and attributes) needed for specific analytical purposes. Improve efficiency by using associations to map dimensions, texts, etc., instead of direct joins, leveraging capabilities like join pruning and the OLAP engine for navigation and filtering. Ensure accuracy by using the built-in data preview functionality to check the output of your Analytic Model before deploying it.

Corporate Memory Layer(Optional, Preserving Historical Data for Future Use):
The Corporate Memory Layer(CML) can be designed for long-term, persistent storage of the complete historical record of loaded transactional data. This layer offers several benefits:

Controlled Independent Updates: CML filled independently of updates to architected data marts, ensuring a complete historical record is preserved.
Reconstruction Source: CML historical data can be used to reconstruct specific data points or entire data sets without reaccessing the source systems. This is particularly valuable when:
- Source system data is deleted or archived or the system is to be retired.
- Data is needed for AI/ML use cases that often require historical trends.
- Historical business reporting.
Cost-Effective Storage: Often utilizes more cost-effective storage solutions like Embedded SAP HANA Cloud Data Lake to manage large volumes of historical data efficiently.

Outbound Layer(Optional, A Flexible Data Delivery Hub):

SAP Datasphere offers an optional outbound data layer that acts as a versatile data delivery hub. This layer provides temporary storage for data intended for external consumption. By leveraging the outbound data layer strategically, you can enhance data accessibility, streamline data exchange with external systems, and efficiently manage the data lifecycle within your SAP Datasphere environment. Key characteristics include:

Flexible Access (OpenSQL Schema ODBC/JDBC, OData, etc.): Data can be directly accessed by both internal and third-party tools, promoting broader data utilization.
SAP FedML (Data Federation): A scenario for training business data using hyperscalart ML capabilities.
External Delivery (Replication Flow): Data can be pushed to various external destinations, facilitating seamless data exchange with other systems.
Provisioning and Management: This layer acts as the data staging area when provisioning data from Datasphere to requesting target systems.
Data Lifecycle Management: Data can be efficiently deleted from this layer once it's no longer needed to supply the target system, optimizing storage usage.
Reconciliation Support: Timestamping records upon replication to external systems simplifies data reconciliation efforts, ensuring data consistency across systems.

Summary:

Following established best practices acts as a roadmap for efficient data modeling in SAP Datasphere. These practices, like those in SAP BW and HANA, maximize resource usage and performance. While this guide emphasizes tried-and-tested methods, SAP Datasphere's flexibility encourages exploring new functionalities for various modeling approaches.

References:

Why Don't We Use Data and Analytics Group on SAP Community?

2024-04-18T18:28:14.375000+02:00

Hey Data and Analytics Folks! Why Don't We Use Data and Analytics Group on SAP Community instead of Technology?

Of course, it does not matter at the end. As long as if you tag your posts with SAP Managed tags everybody can find your posts. But there is a really one huge difference for usability that here in Interests Groups we can reply-the-reply but under Products and Technology we cannot! Check out this blog post SAP Datasphere is ready to take over the role of SAP BW by @kenneth_dalvik and all responses that are very all boring sequential --there is no reply-the-reply option! 🙃

So let's start using this group Here is already available Data and Analytics. The group will be definitely a perfect fit for SAP Analytics Cloud SAP Datasphere SAP Analytics Cloud, hybrid analytics SAP HANA Cloud, SAP HANA database SAP Analytics Cloud, connectivity SAP Analytics Cloud, analytics designer SAP S/4HANA Cloud, extended edition SAP S/4HANA Embedded Analytics SAP Business Planning and Consolidation, version for SAP NetWeaver SAP Business Warehouse Accelerator BW (SAP Business Warehouse) SAP BW/4HANA BW SAP BEx Analyzer BW SAP BEx Web SAP ASE - BW Enablement BW SAP HANA Data Warehousing SAP Data Services SAP Data Intelligence SAP Data Custodian SAP Big Data Services SAP BusinessObjects - Platform Administration SAP BusinessObjects - Semantic Layer SAP BusinessObjects Mobile SAP BusinessObjects - Semantic Layer - SDK SAP BusinessObjects - Web Intelligence (WebI)

These are welcome too SAP Master Data Governance SAP NetWeaver Master Data Management SAP Data Quality Management for SAP NetWeaver MDM

One thing I've noticed we cannot submit the blog posts directly. We need to "Submit for Review" only. You can still post discussions aka questions directly.

Thanks owners @ColinC, @meganhoy, @moshenaveh, @caroleighdeneen, @craigcmehil for their support!

Regards,
Tuncay Karaca

Quick & Easy Datasphere - When to use Data Flow, Transformation Flow, SQL View?

2024-04-26T13:51:23.154000+02:00

Disclaimer

This blog is based on my experience and current limitations of Datasphere (as of 23.04.2024) and shouldn't be considered as the standard.

Introduction

In SAP Datasphere we can "enhance" a data set using different development artifacts like data flow, transformation flow or SQL view (Query/Table Function). In this blog article, I'll share my point of view and decision process for development artefact selection.

Datasphere Technical Limitations/Design Considerations

Let's first cover the most important factor; persistent data tables performs better than views. (For the sake of clarity, persistent data is pre-computed data set derived from a query or a data flow and stored in a table.). So, if we face sql view performance problems, we should consider writing the results to a table.

1- The choice between "SQL View - SQL Query" and "SQL View - SQLScript (Table Function)" is done regarding 2 factors: The complexity of the requirement and the readability of the code. If a requirement can be coded using one select statement in a readable manner, "SQL View - SQL Query" should be the one.

2- In native Hana developments, graphical views' execution plans are optimized automatically. So, theoretically graphical views should perform better than SQLScript views. I couldn't find a noticeable difference myself...

3- Data Flow Limitation 1: The script operator doesn't allow us to read other tables within the code. We can only use the data of the input of the operator.

4- Data Flow Limitation 2: The script operator (Python) has an unexpectedly poor performance. In my experience it's 40-50 times slower than local Jupyter Notebooks and even slower than SQLScript/SQL view option. As Christian Willi explained in his blog article, python code we write in DS doesn't run within the same Hana instance and this affects performance.

5- Data Flow Limitation 3: Local tables with delta capture capability are currently unavailable as target of Data Flow. Also, surprisingly we can only read active data table of these table as source.

6- Data Flow Limitation 4: We cannot use views with a parameter as source.

7- Local Table Limitation; we cannot turn on or off delta capture capability of a local table.

8- Local Table Property: The delta capture fields (Change_Type, Change_Date) are updated automatically only if data is updated using excel upload or via Data Editor. For data flow or transformation flow updates, these fields should be updated within the data/transformation flow.

9- Even if script operator in data flow has poor performance, in case we are not concerned about long running data loads, we can use data flow for tasks which are much easier to do in python like NLP, Data cleaning, time series analysis and so on.

So, my "decision tree" for choosing one of these artifacts is as seen below. Bear in mind that the code that we write in the node 3 or 4 will be used in a data flow or a transformation flow as source. So, it's not lost time...

Example Scenario

The idea of writing this blog article came to me with this question: "What should I use for a material master self-transformation?". We wanted to flag materials in the material master data table (it's a table with delta capture capabilities) which have not been moved within last 365 days to identify obsolete materials. For this example we'll use 2 tables; Material Movement Data (IT_TR_MM_DOC_DEMO) and Material Master (IT_MD_MATERIAL_DEMO). So, here we are!

Steps/Explanations

1- You can find the material master data and material movements table data screenshots below. As it's pretty straight forward, I'll not walk through data loads. You can load csv files for testing following official documentation.

2- For our scenario, we'll read the material movement data table for each material in material master and change the valıe of material master "Obsolete" field to 'X' if there's no entry for the material in question. According to screenshot above, materials 10000001 and 10000002 are not obsolete but 10000003 is.

3- Go to Data Builder -> Select the space -> Click on "New Transformation Flow" -> Click on "View Transformation" and click on SQL View Transformation icon or the button.

4- Select "SQLScript (Table Function)", copy-paste the code in the appendix.

5- Click on the Columns button and create the output table.

6- Validate the code using the button at the right top of the SQL View Editor, see that the SQL Code is valid and go back.

7- Search for the target table name, drag and drop it on the target box

8- Do the mapping of source and target fields by dragging and dropping them in the Properties Panel.

9- Click on an empty space of the canvas, rename the transformation flow, deploy it and wait for the deployment finished notification.

10- Run the transformation flow, refresh the run status until the status turns to "Completed".

11- Go to data builder, open the target table, click on view data , filter the data for 3 materials we had in the material movements table and validate that none of the "Obsolete" values is null and 10000003 is marked as obsolete because latest movement was on 16.01.2022 which is more than 1 year before at the time of writing this article (22.04.2024).

Conclusion

In SAP DataSphere, creating a self-transformation is very easy using a transformation flow and pretty straight forward for BW/4HANA developers experienced in AMDP transformations (or anyone who codes SQLScript) but this method should only be considered for scenarios where we cannot achieve the desired result using a SQLView (Query or Table Function) due to complexity or performance reasons.

Hope the provided information is useful. Any suggestion and feedback for improvement will be much appreciated.

Appendix

-- Creating an "internal table" for non-obsolete materials
nonObsoleteMaterials = Select distinct 
                        MATERIAL 
                        from IT_TR_MM_DOC_DEMO
                        where DOC_DATE >= To_varchar(add_days(Current_Date, -365), 'YYYYMMDD')
                        ;

-- Deriving OBSOLETE FLAG, assigning delta capture related fields.
return select 
            mm.PRODUCT as MATERIAL,
            case when nom.MATERIAL is null then 'X'
            else ' ' end as OBSOLETE_FLAG,
            'U' as "Change_Type",
            CURRENT_UTCTIMESTAMP  as "Change_Date"
            from IT_MD_MATERIAL_DEMO as mm
            left outer join :nonObsoleteMaterials as nom
            on mm.PRODUCT = nom.MATERIAL
            ;

More Information/Sources

Official documentaiton for limitations: Acquiring, Preparing, and Modeling Data with SAP Datasphere
Blog article by @christian_willi : Data Flows - The Python Script Operator and why you should avoid it

SAP BW/4 - revamp and true to the line 2024

2024-04-26T16:00:06.920000+02:00

last changed: 16th of May 2024

SAP BW/4 - revamp and true to the line 2024

Blog Content

as the rudimental HTML anker functionality is not available anymore in the current SAP Blog capabilites, I had to deactivate the TOC.

where (my) the cool stuff happens ...
SAP First Guidance
SAP BW NLS Solution
SAP BW/4HANA
SAP BW Upgrade
SAP BW Installation/Configuration on/for HANA
SAP BW and BI-JAVA Installation
SAP BW Migration to BWoH
SAP BW System Copy
Event Presentations
Additional Topics

SAP BW/4HANA

SAP Community - SAP BW/4 HANA Community - Application Lifecycle Management
SAP BW? - three things to know...
why SAP BW/4HANA?
Analytics with SAP | SAP HANA 2.0 – An Introduction
SAP Product and Solution Roadmaps
Overview SAP Business Warehouse (legacy Information)
SAP BW(/4) on HANA Features -
Features 7.40 SP05 - Features 7.40 SP08/SP09 - Features 7.50 SP00/SP01 - Features 7.50 SP04/SP05 - Features BW/4HANA SP00 - Features BW/4HANA SP04 - Features BW/4HANA SP08 (FP01) - Roadmap BW/4HANA 2.0 - What's new with SAP BW/4HANA 2.0 SP04 - TechEd-2020 SAP Analytics Q/A Summary (SAP DWC, SAC, BW4HANA) - Day 1 - What's new with SAP BW/4HANA 2.0 SP07 - What’s new with SAP BW/4HANA 2021 - What's new with SAP BW/4HANA 2021 SP04 new!

SAP BW Upgrade

Information for the Upgrade to SAP BW 7.50 and BW/4HANA:

Presentation: Upgrade to SAP BW 7.50 (Last Update: 14th of December 2020)
SAP BEx Community Page
SUM for ABAP - Troubleshooting Guide
Blog: Upgrade BW/4HANA 2.0 - the time is now ...

Additional Information about the former BW release upgrades:

Presentation: Upgrade to SAP BW 7.40
the Legend is back, "the Upgrade Bible": Upgrade to SAP BW 7.0x
Good News - Easier Modeling of the SEM Add-On in Solution Manager

SL related BLOG's:

ASU Toolbox (incl. BW Specific Content) and BW Upgrade pre/post Task List

With the ASU (application specific upgrade) toolbox, customers get one single truth for all pre/post upgrade steps regarding the technical upgrade to SAP BW 7.0x and all following releases.

More detailed information about the ASU toolbox can be found in note 1000009. This tool has been available since 2008 and has been enhanced and allows application specific and technical resources to work together for a successful upgrade to SAP BW 7.50 and higher. Together with the BW Housekeeping Task List, there are also additional Task Lists available to simplify preparation of the application-specific part.

Note 1734333 - BW Pre and Post Upgrade and Migration Tasks
See also the - SAP First Guidance - BW Housekeeping and BW-PCA

SAP BW/4 and BI-JAVA legacy Installation

In addition the SAP BW Installation/Configuration (also on HANA) includes the complete SAP BW basis customizing settings, together with an example configuration of the system parameter.

The technical configuration is an elementary part of setting up and operating SAP system landscapes. For example, you have to perform initial technical configuration to bring a newly installed system into operation. But also during the lifecycle of an SAP system, technical parameters have to be set and adapted.

Blog: BI-JAVA, BEx Web and EP: the real connection...

As a successor for most scenarios, we offer the combined export of the Java system, de-installation of the Java Add-In and installation of a new Java system using the dual-stack split tool available as part of the SL toolset 1.0 (SP05). For more information, see "Dual-Stack Split".

With SAP NetWeaver 7.50 JAVA the Functional Unit Configuration UI (former CTC BI-JAVA Template) is available.

In Advance check the WebAS/SSO Settings after the Upgrade to NetWeaver 7.3x.
The settings are almost identical to NetWeaver BW 7.0x

Migration to SAP BW on SAP HANA (BWoH)

Database Migration Option (DMO) of SUM - Introduction

DMO is an option of SUM (Software Update Manager) for a combined update and migration: update an existing SAP system to a higher Software Release and migrate to SAP HANA database including the unicode conversion of the source database. The procedure is only available for systems based on AS ABAP, hence the executable SAPup is used in background. DMO migrates from an existing relational database type (“anyDB”) to SAP HANA. Software Update Manager (SUM) is the tool for system maintenance: Release upgrades, EHP implementation, applying SP stacks.

Blog: optimizing system downtime is timeless ...

Blog: HANA 1.0 vs HANA 2.0 - plan your Migration wisely ...

Please Note that since Q1/2014 the Presentation -
Migration to BW on HANA - First Guidance concludes all of these manual efforts now.
=> Updated January 2020

SAP First Guidance - Using the new DMO to migrate to BW on HANA

More flexibility with SAP BW Post-Copy Automation

To achieve this, SAP NetWeaver Landscape Virtualization Management offers preconfigured "task lists" used by the ABAP task manager for lifecycle management automation.

SAP Note 886102 (SMP login required) thus becomes obsolete. Using the post-copy automation for SAP BW (BW PCA) in the migration process of SAP BW to SAP BW on SAP HANA, this process can be shortened by weeks and becomes easier, faster and more reliable.

The former presentation TechEd 2014 - Session ITM206 still illustrates the migration to SAP BW on SAP HANA from an end-to-end perspective.

SAP BW System Copy

PDF help: User Guide for SAP BW Note Analyzer
Note 2743291 - PCA for BW/4HANA
Note 2570363 - Availability of BW PCA for BW/4HANA
Note 1707321 - BW System Copy: Post Copy Automation (BW-PCA)
Note 1614266 - System Copy: Post-Copy Automation (PCA) / SAP Landscape Management (LaMa)

Since Release 7.30 SP05, it is now possible to perform a heterogeneous system copy (including unicode migration) to migrate existing systems based on SAP BW 7.30 SP05 and higher to SAP BW on SAP HANA (HDB) based systems.

With this major step forward, a new procedure called "Post Copy Automation (BW PCA)" now supports customers with what can often be complex post-steps before and after the homogenous/heterogeneous BW system copy. This presentation is the delta information to the existing document "SAP NetWeaver 7.30 - BW Systemcopy ABAP" shown above. The technical Improvements with the leaner data model provides advantages with BW on HANA too.

You can also refer to the SAP First Guidance Documents
- SAP First Guidance – SAP BW on HANA – Edition 2021
- SAP First Guidance - BW Housekeeping and BW-PCA

Blog - System Copy Automation for SAP Business Warehouse System Landscapes
Blog - New Note Analyzer for SAP BW PCA and Housekeeping
Blog - System Copy Automation for SAP Business Warehouse System Landscapes (BW PCA)

Note 2534288 - HEC Service "Homogeneous System Copy / System Refresh (ABAP)
Note 2681701 - System Copy: Task Content (12.1 Improvements)

Updating to the minimum level of the mentioned Support Stacks is recommended to minimize the manual effort. For both cases the BW-PCA Task lists support the customer together with the software provisioning manager 1.0 (SWPM) in these software lifecycle management tasks. BW-PCA is embedded in the SAP NetWeaver Landscape Virtualization Management

Event Presentations

Presentation - Hitchhiker’s Guide to NetWeaver or “thank you for the fish …” (simply timeless)

Presentation - Upgrade S/4HANA Version 2020 -Basis View

Additional Topics like References, Experiences, etc.

Product Availability Matrix (PAM) for Business Warehouse Accelerator 7.20 (BWA)
Note 1845809 - Latest Revision for BWA 7.20
Note 2495501 - BWA 7.20: Revision 41
Note 2665383 - BWA 7.20: Revision 42
Note 2887737 - BWA 7.20: Revision 44 (05.02.2020)
Note 3284562 - BWA 7.20: Revision 49 (30.12.2022)

This is a collection of resources from the former SCN Network and its content is not reflecting the findings from this document of future upgrade and enhancements.

Blog - IE11 will no longer be supported by various SAP UI technologies in newer releases
Blog - SAP BW Upgrade: Pre and Post upgrade activities with answer to why?
Blog - SAP BW 7.4 Powered by HANA -- Promising Features (Part 1)
Blog - ABAP CDS in SAP BW
Blog - SAP BI4.x Installation/Update/Patching
Blog - Removal of only Time Dependent Attribute added Accidentally
Blog - Some interesting Facts of Compatibility Views in SAP BW/4HANA and SAP S/4HANA - SAP Cloud Integration into SAP BW/4HANA - further Content from frank.riesner1 (SAP)
Blog - How to load Flat Files from MS Office 365 to BW/4HANA using SDI / DP-Agent

DSAG Forum: "TG Road 2 BW/4HANA" => (DSAG-ID requested) share your experience with other DSAG members.

Roland Kramer, SAP first-guidance
@RolandKramer

“I have no special talent, I am only passionately curious.”

Understanding Data Modeling Tools in SAP

2024-05-02T16:25:43.459000+02:00

Choosing the right SAP data modeling solution can be a challenging task, as there are multiple options available, including cloud-based or on-premise solutions with or without data visualization capabilities etc..so to select the best tool that can meet the project requirements and specifications, several factors need to be considered including, reviewing the raw data source and understanding how it will be used, assessing the need for data warehousing capabilities, evaluating the team's skill sets, and deciding whether a cloud or on-premise solution is preferred.

During the last few years, I've worked with almost all the SAP Data Modeling tools that are available, and In this blog article, I would like to briefly highlight the strength of each tool and where would be the best fit for it 🤗.

Understanding Data Modeling

so what it's data modeling in SAP and why it's important? 🤔

when we talk about Data modeling we are defining the process of creating diagrams that show how data flows in and out of a database. These diagrams define the data formats, structures, and functions required to support the data flow. Once the database is built, the data model becomes documentation for its existence and design. Data models provide a framework of relationships between data elements within a database. They enable different applications to share the same data and create a simple and logical database that eliminates redundancy, reduces storage requirements, and enables efficient retrieval.

SAP HANA Calculation Views

SAP HANA calculation views are the key data modeling object on HANA, it's a graphical object that describes all the data processing steps from raw data to the final, consumable output.

Common data processing steps include filtering data, combining data, aggregating data, calculating new values, converting values, and ranking data. Calculation views are built in layers so that each calculation view can consume other calculation views to form a stack of super-models. This approach promotes the reuse of calculation views at the lower levels.

Strengths:

In-Memory Processing: Data processing occurs directly in memory, ensuring high performance.
Graphical Interface: Intuitive tools make it easy to create and visualize models.
Custom Logic: Ability to integrate custom SQL for tailored data processing.
Advanced Analytics: Supports spatial, graph, text analytics, and predictive/machine learning.

Best Fit: Developing flexible data marts with custom logic requirements.

SAP BW/4HANA

SAP BW/4HANA is an on-premise data warehouse. The main purpose of a data warehouse is to extract data from any data source, integrate the data, store the cleansed data, and provide modeling tools so that data models can be created ready for use by any analytical tool. This is exactly what SAP BW/4HANA can do.

Strengths:

Ready-Made Models: Comprehensive data models are provided for virtual and physical storage.
Data Warehousing Features: Supports dimensional modeling, hierarchies, and efficient data storage.
Graphical Tool: User-friendly interface for efficient model visualization.
On-Premise Deployment: Ideal for industries requiring high security and data control.

Best Fit: Establishing on-premise data warehouses with strong data integration needs.

ABAP CDS Views

ABAP CDS Views enable developers to create data models that are semantically rich. These models are then exposed to UI clients by the application services. CDS Views is the central pillar of S/4HANA development and is used as the core technology in most of SAP's programming models.

Strengths:

High Performance: Data processing is pushed down to the database level, ensuring efficiency.
Ready-Made Models for SAP S/4HANA: Simplifies operational reporting on S/4HANA.
Flexible Development: Allows for code-based customization leveraging SQL skills.

Best Fit: Operational reporting on SAP S/4HANA with ready-made content.

SAP Analytics Cloud

SAP Analytics Cloud is an end-to-end cloud solution that brings together business intelligence, augmented analytics, predictive analytics, and enterprise planning in a single system. It is a solution aimed at business users for self-service analytics.

Strengths:

Integrated Modeling: Modeling seamlessly integrated with reporting tools for streamlined analytics.
Cloud-Based: No need for software installation; data modeling is conducted in the cloud.
Self-Service Analytics: Empowers business users to create their own models.

Best Fit: Organizations seeking self-service analytics with integrated modeling and reporting.

SAP Datasphere

which is so far My Absolute favorite tool 😁! It is a public cloud software as a service (SaaS) data warehouse that supports the business data warehouse architecture. This tool effortlessly harmonizes data across the enterprise, making it a must-have for any business. It includes services for data modeling, data integration, cataloging, and data warehousing across SAP and non-SAP data, making it a one-stop-shop for all data management needs

Strengths:

Comprehensive Data Warehouse Features: Supports dimensional modeling, data history management, and hierarchy modeling.
Scalability: Easily scale resources in the cloud, supporting new innovations.
Cloud Service: Simplifies software management through cloud consumption.

Best Fit: Cloud-based data warehousing with advanced features and scalability.

SAP BusinessObjects BI Semantic Layer (Universes)

An organized collection of objects that called a Universe, which consists of dimensions, measures, and attributes grouped by business topics. The skill of a Universe developer is to create objects that resemble business terms by mapping them to the columns of the database tables. In some cases, SQL coding may be required to generate the value of the objects.

Strengths:

User-Friendly Interface: Graphical tool simplifies data modeling tasks.
SQL-Based Development: Easy to understand for database developers.
Mature Tool: Offers a wide range of features for diverse modeling needs.

Best Fit: Supporting SAP BusinessObjects reporting tools with Universes.

for more information, I would recommend this Learning journey from SAP which will give you an overview of all the SAP data modeling solutions 😊

revamped SAP First Guidance Collection

2024-05-03T17:26:18.581000+02:00

last changed: 3rd of May 2023

SAP First Guidance Collection - revamped

Page - where (my) the cool stuff happens …

I will add additional Documents with the time, reflecting the new design.
SAP First Guidance – SAP BW on HANA - Edition 2022 Last Changed:	Implementation
SAP First Guidance - complete functional scope (CFS) for SAP BW 7.50 Last Changed:	Implementation
SAP First Guidance - complete functional scope (CFS) for SAP BW/4HANA Last Changed:	Implementation
SAP First Guidance - Implement SAP BW/4HANA in the Azure Cloud Last Changed: 19th of May 2022 - Version 1.45	Implementation
SAP First Guidance - Using the new DMO to migrate to BW on HANA Last Changed:	Software Logistics
SAP First Guidance - Implementing BW-MT as the new SAP BW Modeling Experience Last Changed:	BW-MT

SAP First Guidance - SAP NLS Solution with SAP IQ 16.x
Last Changed: 14th of February 2024 - Version 2.70

SAP First Guidance - SAP-NLS with IQ 16.x - Edition 2021
Last Changed: 3rd of December - Version 2.50
This Version still contains all relevant Information prior to SAP IQ 16.1

SAP First Guidance - Q - the SAP IQ Database Installer
Last Changed: 14th of February 2024 - Version 1.71

SAP First Guidance - SAP-NLS with the PBS NLS Add-On
Last Changed: 14th of June 2017 - Version 1.02

SAP-NLS
ILM Software Logistics
NLS Partner Add-On

SAP First Guidance - SEM/BW Modelling in SolMan 7.x with MOPz/MP
Last Changed:

Software Logistics

SAP First Guidance - BW-PCA and Housekeeping Task Lists
Last Changed:

Software Logistics

The First Guidance Documents Collection, is a Series of Information that should help to better understand the end-to-end usage of SAP BW powered by SAP HANA and BW/4HANA. The Documents are still “work in progress”, as important updates will be added when needed. So these guides are not intended to be exhaustive.

SAP First Guidance - SAP BW on SAP HANA Installation/Systemcopy/HANA Revisions

This Document also reflects the released SAP HANA SP/Revisions so far and also contains details for selected HANA Revisions and the usage together with SAP BW.

On base of this information this “SAP First Guidance” document is released to support Basis administrators in running and configuring a Business Warehouse on a SAP HANA system. SAP First Guidance – Business Warehouse on SAP HANA installation provides answers to major questions and issues as well as workarounds and additional details to complement standard SAP Guides and SAP Notes. This SAP First Guidance document has no claim of completeness, but it is the most complete starting point for a successful implementation.
For more information please contact roland.kramer@first-guidance.com

SAP First Guidance - complete functional scope (CFS) for SAP BW 7.50

SAP BW powered by SAP HANA was the very first SAP application that ran completely on top of SAP HANA and has meanwhile reached a great adoption. Customers will benefit not only from performance improvements for data load, query runtime and planning functions but also in simplified data modeling as the number of InfoProviders are highly reduced and all modeling is done within in a new, modern UI that is unique across all modeling tools.
This SAP First Guidance Document put´s is emphasize to the complete functional scope (CFS) to ensure the full functionality right from the start of the Implementation of SAP BW 7.50 SP04 and higher. For more information, please contact roland.kramer@first-guidance.com

SAP First Guidance - complete functional scope (CFS) for SAP BW/4HANA

SAP BW/4HANA is a new SAP product that replaces SAP Business Warehouse in a logical way. BW/4HANA runs only on HANA platform and will be the foundation for a new lineage of data warehousing solutions from SAP.

Furthermore it optimizes and simplifies a customer’s BW environment and experience (similar to S/4HANA). BW/4 HANA 1.0 (DW4CORE) is a new code-line on which all future BW enhancements will take place. Classic BW goes into maintenance mode.
This SAP First Guidance Document put´s is emphasize to the complete functional scope (CFS) to ensure the full functionality right from the start of the Implementation of SAP BW/4HANA 1.0 SP00 and higher. For more information, contact roland.kramer@first-guidance.com

This SAP First Guidance Document concludes the necessary Steps to implement SAP BW/4HANA to the Azure Cloud and also considers the additional tasks to connect the on-premise Systems to the Cloud Infrastructure.

SAP First Guidance - Implement SAP BW/4HANA in the Azure Cloud

SAP First Guidance - Using the new DMO to migrate to BW on HANA

The database migration option (DMO) is an option inside of the software update manager (SUM) for combined update and migration: update an existing SAP system to a higher software release and migrate to SAP HANA database in one technical step. As the technical SUM steps are the same, this “SAP First Guidance” document should make all customer-specific documentation obsolete. It is the complementary documentation to the existing Notes and SUM/DMO Upgrade Guides.

DMO can be used with every BW Release starting from 7.0x and onwards. It makes the two-step approach (upgrade/migration) and the usage of the BW post copy automation (BW-PCA) obsolete. It can also be used within a Release, e.g. to go from 7.40 SP06 on anyDB to migrate to 7.40 SP07 on HANA. For more information, please contact roland.kramer@first-guidance.com

SAP First Guidance - Implementing BW-MT as the new SAP BW Modeling Experience

SAP BW 7.4 SP08 powered by SAP HANA is the next milestone for enterprise data warehousing with BW on HANA and provides the next level of simplification for BW .In addition, SAP BW on HANA Virtual Data Warehouse capabilities have been enhanced for even more flexibility. In midterm the advanced DSO shall replace the main BW InfoProviders with persistency (InfoCube, DSO, and PSA). The classic InfoProviders are of course still supported and do co-exist with the advanced DSOs. For more information, please contact roland.kramer@first-guidance.com

SAP First Guidance - SAP NLS Solution with SAP IQ

This “SAP First Guidance” document provides all the necessary information to help quickly implement this newly released option: Store historical BW data on an external IQ server to optimize the system size when preparing to migrate to SAP BW powered by SAP HANA. The SAP NLS solution with Sybase IQ also helps to keep down the TCO for investing in the SAP In-Memory when historical (“frozen”) data is stored on a less sophisticated device, which acts like a “BW Accelerator on Disk”. SAP Sybase IQ is therefore the perfect smart store for this kind of data. Please note that the SAP NLS solution can be used with all database versions supported by SAP BW 7.3x. SAP HANA is not necessary. The document is a “work in progress” and is not intended to be exhaustive. It does however contain all information required for successful implementation of the SAP-NLS solution with Sybase IQ. SAP-NLS can be used with every SAP supported database, where SAP IQ will be the secondary database for data reallocation.
For more information, please contact roland.kramer@first-guidance.com

SAP First Guidance - combining SAP-NLS with the PBS NLS Add-On

The SAP-NLS solutions offers core functionalities for the usage of the SAP IQ database for the storage of historical data, despite if you are using SAP HANA or any other supported RDBMS together with SAP BW.
However, when it comes to the implementation several functionalities are not delivered by SAP itself, as by the development Partner PBS. Furthermore, some of the additional capabilities developed sine Q1/2013 are only available with the latest SAP BW Releases 7.40/7.50. This is where the additional capabilities from the PBS NLS Add-On come into place as almost all of them are available from SAP BW 7.0x onwards.

SAP First Guidance - SEM/BW Modelling in SolMan 7.1 with MOPZ

Due to constant Questions about the Upgrade to NetWeaver 7.3x and 7.40 including SEM Add-On Components, we created a SAP First Guidance Document which describes the successful Definition of a SAP BW 7.0/7.01 System with the SEM Add-On Installed on top. With this Information you will be able to integrate the stack.xml in the SUM (software update manager) process and the DMO (database migration option) DMO process included in SUM as the first input is the location of the stack.xml which defines the download directory for SUM. Furthermore, the interaction of the stack.xml in the upgrade process enables you a smooth Integration into the Upgrade Process included in DMO. For more information, please contact roland.kramer@first-guidance.com

SAP First Guidance - BW Housekeeping and BW-PCA

The system copy procedure of SAP BW systems and landscapes is complex for a number of reasons. There is a large number of configuration settings (such as connections and delta queue handling for data loading) and system copy scenarios of SAP BW (each with different landscape aspects). These have to be handled as part of every system copy, regardless of whether the system copy is part of the migration to SAP HANA or if you want to perform regular system copies of your SAP BW landscape. BW-PCA can be used from SAP BW 7.0 onwards depending on the SPS level.

Additionally see the usage and implementation of the BW Housekeeping Task List and the Pre/Post Task Lists for Upgrade/Migration. These are Included in the database migration option (DMO) as part of the software update manager (SUM). Additional Details also can be found on the revamped SAP BW ALM Page. For more information, please contact roland.kramer@first-guidance.com

if the TechEd Cat would know this earlier ...

Roland Kramer, SAP first-guidance
@SAPFirstGuidance

“I have no special talent, I am only passionately curious.”

SAP Community - BW SAP HANA Data Warehousing

New SAP BW/4HANA Learning Journey

SAP Datasphere - the next generation of SAP Data Warehouse Cloud

Hope this blog post finds you well. Goal with this post is to provide helpful resources and support documentation to assist you in navigating the latest news.

SAP BW/4HANA & BOBJ Dashboard Reporting (Blog1)

1.1 Overview

1.2 Functional Requirement

1.2.1 Dashboard REPORTING SCOPE

1.3 Business Process Landscape

1.4 SOLUTION ARCHITECTURE

1.4.1 Option 1: Extraction by table/view

1.4.2 Option 2: Extraction by function module with memory id

1.4.3 Option 3: Extraction by function module

1.4.4 Technical design steps and dataflow

1.5 Testing

SAP BW/4HANA & BOBJ Dashboard Reporting (Blog 2)

1.1 Overview

1.2 Functional Requirement

1.2.1 Dashboard REPORTING SCOPE

1.3 DESIGN (B/W4HANA Modelling)

1.4 DESIGN (SAP Businessobjects Analysis for OLAP)

1.5 DESIGN (BOBJ WEBI Dashboards)

Consuming data from SAP Datasphere into Power BI via ODBC connector

Inventory Management in BW/4HANA

Sierra’s InFocus: SAP Datasphere Readiness Assessment

Solution Architecture :

Where can I develop the skills to implement a data warehouse using SAP BW/4HANA?

How to map SAP ERP fields to SAP BW/4HANA InfoObjects?

Introduction

Solution

Conclusion

Safeguard your SAP BW conversion with SAP Enterprise Support services

CONVERSION GUIDANCE

SUPPORT SERVICES

Technical Performance Optimization (TPO)

Business Process Performance Optimization (BPPO)

Implementation Service

Data Volume and Archiving

Further Support and Empowerment via SAP Enterprise Support Value Maps

Quicklinks

Exploring Datasphere & BW Bridge : Technical Insights

SAP IQ NLS-The Cold Storage Solution for SAP BW/4HANA

How to Debug DTP Filter Routine

Getting Started with SAP BW Request Housekeeping

SAP Datasphere - Space, Data Integration, and Data Modeling Best Practices

Motivation:

1. Managing Your Datasphere Spaces:

What is the Space and What are the benefits?

What are the Space types and Important Configuration Parameters?

Important Configurations Parameters

Space Organization Scenarios/Examples:

1. Line of Business (LoBs)​

2. Departments

3. Data Domains

4. Single SAP Datasphere tenant for development and testing using the Space concept.

5. With the SAP BW bridge

General Space Guidelines:

2. Data Integration:

Data Integration Options and Recommendations:

Choosing Between Remote Tables and Data Replication in SAP Datasphere:

Use Remote Tables (Data Federation) When:

Use Data Replication When:

General Guidelines:

3. Data Builder Modeling:

General Recommendations:

Layered Modeling Approach for Better Performance, Organization and Management:

Layers

Purpose

Best Practices

Summary:

References:

Why Don't We Use Data and Analytics Group on SAP Community?

Quick & Easy Datasphere - When to use Data Flow, Transformation Flow, SQL View?

SAP BW/4 - revamp and true to the line 2024

SAP BW/4 - revamp and true to the line 2024

Blog Content

SAP BW/4HANA

SAP BW Upgrade

SAP BW/4 and BI-JAVA legacy Installation

Migration to SAP BW on SAP HANA (BWoH)

1. Line of Business (LoBs)