Not yet on BW/4 - What to do? - Considerations and experiences of our customers

In discussions with customers, the question often arises as to how to proceed with a BW 7.5 and smaller. When should the migration to BW/4 be carried out or should a completely new path be taken? Therefore, we would like to compile some aspects that can support the decision. 

We will look at the following aspects: 

  • Guidelines for new development in BW 7.5 on HANA
    How should new BW projects be implemented: Is it already worth using the new objects (aDSO, Composite) or even AMDPs for the development of complex transformations?
  • Planning in third-party tools
    Third-party tools have lost their terror. The first tools are already successfully in use today. Why are these tools not also used for planning, which must be additionally licensed in BW/4?
  • Still SAP-BW or a completely different tool?
    The effort for the migration to BW/4 is very high. Why not switch to another tool?
  • Why switch to BW/4 HANA?

Guidelines for new development in BW 7.5 on HANA

As soon as your BW release has arrived at BW 7.5 on HANA, the question arises as to which new techniques should be used. At this stage, the "old" and the "new" worlds with multicubes and composite providers coexist on an equal footing. Development can take place in both worlds. Only when migrating to BW/4 does a migration of all old data models become mandatory. 

Today, the functionality as well as the stability of the new data models (composite / aDSO etc.) are so mature that the question no longer arises as to which model should be developed in. All new projects should only be developed in the new data model, as the learning effort is low and the simultaneous benefit through new functionality is high. Existing data models, however, do not have to be converted, they will continue to run.

A different question is whether only AMDP processes may be used in transformations. This is desired by some customers, but not absolutely necessary. A transformation into aDSO with ABAP routines is also still executable in BW/4. However, against the background of performance, the transformation with ABAP is not pushed to HANA and therefore runs slower. Before in-house developments are used, alternative formulas or new functionalities (e.g. reading from an aDSO) could solve the problem. These are pushed to HANA and are easier to maintain than convoluted coding. To develop an AMDP routine, a new development language must be learned. This requires appropriate practice for more complex requirements. Then it has to be considered individually whether such a high volume of data is to be expected and what skills are available in the development team as well as in the support of the application. 

Planning in third-party tools

In the meantime, even on a BW 7.5, the SAP world is no longer a closed universe. Many companies have third-party tools in use, such as Tableau or Power BI for a fancy reporting interface. This has lowered the inhibition threshold to integrate third-party systems into the BW world. Additional licences are required in BW/4 for the use of planning. With BW 7.5, additional licences were only necessary if planning was to be pushed to HANA on the performance side. Therefore, BW planning will have to compete against the cost of a third-party tool. When introducing external planning tools, there are a few stumbling blocks to consider that are often forgotten in a tool selection and can jeopardise the project and drive up costs shortly before completion. 

Data replication for actual and planned figures in and out of the external planning tool

In contrast to a reporting tool, which "only" has read access to the BW data, a planning tool needs its own data storage for the plan figures. In most cases, the actual figures are also stored there. This means that data replication is necessary for the actual figures from BW and often back into BW. This results in another reporting interface. Alternatively, the planned figures are not available until the planning has been completed and replicated again. It should not be forgotten that extensions to the data model also always have to be polished by another system. 

Understanding the data model

In addition to the pure physical replication of the data, the data model must also be adapted to the new tool in terms of content and structure. Each tool has slightly different methods and data to store. This is rarely a real problem, but it can easily lead to misunderstandings that delay development.  

Authorisation and user matching

User maintenance must also be stored in an additional tool. Often the effort is not the actual user creation, but the updating of responsibilities. 

BW or a completely new tool

There are many rumours and fears about the effort required for migration. Many fear a very high effort, similar to a new implementation. This is a reason to question the use of SAP BW and to evaluate other tools. 

How high is the migration effort to BW/4 really?

As always, the effort depends on one's own situation. If you have been migrating to BW 7.5 on HANA for some time and have already realised projects with the new tools, there is no longer any migration effort. 

The migration tools are now so sophisticated that many models can be migrated automatically. If a system has a lot of historical legacy, the wealth of experience built into the data models should not be underestimated. On the other hand, this can also be an opportunity to "clean up" and make the system leaner through new techniques.  

Governance through BW not so present in other systems

In another tool, one or the other solution can certainly be built quickly. However, it should be taken into account that in a BW, the tools for development as well as transports, data loading and control are well established and comfortable. This is not possible in such a lean way in all systems.  

Naming conventions and authorisations have also been established for the BW systems in order to distinguish different areas from each other. This comprehensive knowledge has to be set up again in new systems. 

What are the reasons for switching to BW/4?

Before an upgrade, therefore, a clear decision should be made in favour of the upgrade before considering different points of view. How does this look with BW/4? Since BW 7.5 is already a quite mature product, there are hardly any general and important new functions. In detail, there are some improvements. Those who work with large amounts of data and sometimes remodel their data model will find some aspects useful, such as data tiering to move older data out of the main memory.  

In planning, you can now also plan master data and enter new master data in a planning layout. This enables some new planning scenarios. However, it is mandatory to purchase additional licences if you want to use planning. 

Conclusion

It is undisputed that the migration to BW/4 is a big leap that raises many questions. Whether the new functions require a faster upgrade must be weighed up. By 2030 at the latest, the end of the extendend maintenance of BW 7.5, this decision should be made. Especially against the background of the SAP Data Warehouse Cloud on the horizon and the general cloud strategy of SAP...  

Hopefully, the blog has provided a few ideas on some of these questions around this complex of topics.  

If you have any further questions or need help, please feel free to contact us. 

Contact Person

Dr. Ulrich Meseth

Senior Consultant

Data Products Setup

I’ll start with Data Products setup. If you’re new to the concept, this recent video is a great starting point, but here’s a short summary. A data product is a well-described, easily discoverable, and consumable collection of data sets.

Creating a Data Product in Datasphere

Note that in this article I create Data Products in the Data Sharing Cockpit in Datasphere. This functionality is expected to move into the Data Product Studio, but that had not taken place at the time writing.

Before creating a Data Product in Datasphere, I need to set up a Data Provider profile, collecting descriptive metadata like contact and address details, industry, regional coverage, and importantly define Data Product Visibility. Enabling Formations allows me to share the Data Product with systems across your BDC Formation – Databricks, in this case.

With the Data Provider set up, I can go ahead and create a Data Product. As with the Data Provider, I’ll need to add metadata about the product and define its artifacts – the datasets it contains. Only datasets from a space of SAP HANA Data Lake Files type can be selected. Since this Data Product is visible across the Formation, it is available free of charge.

For this demo, the artifact is a local table containing ten years of Ice Cream sales data. Since this is a File type space, importing a CSV file directly to create a local table isn’t an option (see documentation).

I used a Replication Flow to perform an initial load from a BW aDSO table into a local table.

Once Data Product is created and listed, it becomes available in the Catalog & Marketplace, from where it can be shared with Databricks by selecting the appropriate connection details.

Jump into Databricks

To use the shared object In Databricks, I need to mount it to the Catalog – either by creating a new Catalog or using an existing one.

Databricks appends a version number to the end of the schema – ‘:v1’ – to maintain versioning in case of any future changes to the Data Product.

Once the share is mounted, the schema is created automatically, and the Sales actual data table becomes available within it. From there, I can access the shared table directly in a Notebook.

Creating a Data Product in Databricks

To create a Data Product in Databricks, I first need to create a Share – which I can either do via the Delta Sharing settings in the Catalog:

Or directly out of the table which is going to become a part of the Share:

Since a single Share can contain multiple tables, I have the option to either add the table to an existing Share, or create a new one:

To publish the Share as a Data Product, I run a Python script where I define the target table for the forecast and describe the Share in CSN notation, setting the Primary Keys. Primary Keys are required for installing Data Products in Datasphere.

Jump back into Datasphere

Once the Databricks Data Product is available in Datasphere, I install it into a Space configured as a HANA Database space – since my intention is to build a view on top of the table and use it for planning in SAC.

There are two installation options: as a Remote table for live data access, or as a Replication Flow, in which case the data is physically copied into the object store in Datasphere.

Since I want live access, I install it as a Remote Table:

and build a Graphical view of type Fact on top:

Forecast calculation

With my Data Products set up and Sales actual data are available in Databricks, I create a Notebook to calculate the Sales Forecast.

The approach combines Sales and Weather data to train a Linear Regression model. I import the Weather data *https://zenodo.org/records/4770937 from an external server directly into Databricks, select the relevant features from the weather dataset, and combine them with the Sales actual data:

* Klein Tank, A.M.G. and Coauthors, 2002. Daily dataset of 20th-century surface
air temperature and precipitation series for the European Climate Assessment.
Int. J. of Climatol., 22, 1441-1453.
Data and metadata available at http://www.ecad.eu

Using the “sklearn” library, I build and train a Linear regression model:

Once trained, the model predicts the Sales forecast for Rome in June 2026 based on the weather forecast, and I save the results to my Catalog table:

Seamless planning data model

Seamless planning concept is built around physically storing planning data and public dimensions directly in Datasphere, keeping them alongside the actual data.

Since the QRC4 2025 SAC release, it has also been possible to use live versions and bring reference data into planning models without replication.

In this scenario, I build a seamless planning model on top of the Graphical view I created over the Remote table. This lets me use the forecast generated in Databricks as a reference for the final SAC Forecast version.

 

The model setup follows these steps:

Create a new model:

Start with data:

Select Datasphere as the data storage:

From there, I define the model structure and can review the data in the preview.

For a deeper dive into Seamless Planning, I recommend this biX blog.

Process Flow automation

Multi-action triggers Datasphere task chain

The final step is automating the entire forecast generation by using SAC Multi-actions and a Task-Chain in Datasphere – so that my user can trigger the calculation with a single button click from an SAC Story.

The model setup follows these steps:

Create a new model:

Triggering Task Chains from Multi-actions is a recent release. This blog post walks through how to set it up.

For details on how to trigger a Databricks Notebook from Datasphere, I recommend referring to this blog.

With everything in place, I create a Story, add my Seamless planning Model, and attach the Multi-action:

Running the Multi-action triggers the Task Chain, which in turn triggers the Databricks Notebook.

I can monitor the execution details in Datasphere:

and in Databricks:

Once the calculation completes, the updated forecast appears in the Story:

The end-to-end calculation took 2 minutes 45 seconds in total. The Task Chain in Datasphere is triggered almost instantly by the Multi-action, the Databricks Notebook execution itself took 1 minute 29 seconds, with the remaining time spent on Serverless Cluster startup.   

 

From here, I can copy the calculated forecast into a new private version:

adjust the numbers as needed, and publish it as a new public version to Datasphere:

Conclusion

With SAP Business Data Cloud, it is possible to build a forecasting workflow that feels seamless to the end user — even though it spans multiple systems under the hood.

Companies using BW as the main Data Warehouse and Databricks for ML calculations or Data Science tasks can benefit from using the platform, as the data no longer needs to be physically copied out of BW.

What this scenario demonstrates is that once wrapped as a Data Product, BW sales data can be shared with Databricks via the Delta Share protocol. Databricks, in turn, can then create its own Data Products on top of the calculation results and share them back with Datasphere as a Remote Table.

A Seamless Planning model in SAC sits on top of that Remote Table, giving planners live access to the generated forecast. A single Multi-action in an SAC Story ties it all together, triggering a Datasphere Task Chain that kicks off the Databricks Notebook — completing the full cycle in under three minutes.

As SAP Business Data Cloud continues to mature, scenarios like this one are becoming achievable – leaving the complexity in the architecture and not in the workflow.

Contact

Ilya Kirzner
Consultant
biX Consulting
Privacy overview

This website uses cookies so that we can provide you with the best possible user experience. Cookie information is stored in your browser and performs functions such as recognizing you when you return to our website and helps our team to understand which sections of the website are most interesting and useful to you.