Planung mit Power BI 

Januar 2026

Planung mit Power BI 

Inzwischen ist es auch mit Power BI möglich, Werte in Microsoft Fabric zurückzuschreiben. In diesem Blog wollen wir beleuchten, was mit dieser Funktion möglich ist und ob wir das schon Planung nennen können. 

Dazu betrachten wir die Möglichkeiten, Werte über das Power BI -Tool selber und über Excel zurückzuschreiben. Wir zeigen auf, was damit möglich ist und für welche Anforderungen diese Technik in Frage kommt. 

Einführung 

Mit dem Translytical Task Flow stellt Power BI ein leistungsfähiges neues Feature bereit, das es ermöglicht, gezielte Endnutzerinteraktionen direkt in Reports zu integrieren. Dadurch lassen sich klassische, rein analytische Reports zu interaktiven Anwendungen erweitern, in denen Nutzereingaben aktiv in Verarbeitungslogiken einfließen.  

In Kombination mit den Microsoft Fabric User Data Functions eröffnet sich erstmals die Möglichkeit, Werte aus Power-BI-Reports heraus kontrolliert in Fabric-Datenbanken zurückzuschreiben. Dieses Rückschreibeszenario stellt ein lang erwartetes Feature vieler Kunden dar und schafft somit die Grundlage für eine Planungsfunktionalität, weshalb das Feature direkt für uns in den Fokus gerückt ist. Die Fabric User Data Functions fungieren dabei als serverseitige, benutzerdefinierte Logikschicht innerhalb von Microsoft Fabric und lassen sich schnell mittels Python Funktion umsetzen. Sie ermöglichen die Validierung, Transformation und persistente Speicherung von Nutzereingaben und bieten zugleich eine saubere Trennung zwischen Frontend (Power BI) und Backend (Fabric). Durch die native Integration in das Fabric-Ökosystem können bestehende Artefakte wie Lakehouses, Warehouses oder andere Datenspeicher direkt genutzt werden und über ein Package von Microsoft werden Werkzeuge für den Entwickler mitgeliefert, die zum Beispiel Fehlerzustände und Validierungsprobleme standardkonform über HTTP-Response-Codes an den Client zurückgeben.

Weiterführende Informationen zu den Konzepten, Einsatzmöglichkeiten sowie den derzeitigen Limitationen des Features finden sich in der offiziellen Microsoft-Dokumentation:
https://learn.microsoft.com/en-us/power-bi/create-reports/translytical-task-flow-overview 

In unserem vorherigen Blog 

Databricks und Planung oder einfacher Eingabe

haben wir beschrieben welche Anforderungen für Planungsanwendungen ein Tool erfüllen muss, um einfache oder komplexe Planungsszenarien abzubilden. In diesem Blog werden wir prüfen, welche davon mit den neuen Features in Power BI möglich sind und wo die Grenzen liegen. 

Erfassung über das Power BITool 

Mittels der Translytical Task Flow, lässt sich ein Trigger auf den Save Button hinzufügen, der eine zuvor entwickelte User Data Function mit den werten aus der Textbox parametrisiert aufruft.  Der entsprechende Kontext wird aus der markierten Zeile eines Berichtes übernommen und ebenfalls mit übergeben.  

Hier erkennt man schon, dass es eine Trennung zwischen den Werten in der Tabelle und dem zurückzuschreibenden Wert gibt, den ich aus einem getrennten Feld lesen muss. Der zweite Punkt ist, dass ich nur ein Feld für die Rückgabe habe und keine Tabelle zurückgeben kann. 

Abbildung 1: Power BI Layout mit Erfassungsmöglichkeit für ein Feld

Damit ist es zwar möglich, einen Wert technisch zurückzuschreiben, aber eine Änderung mehrere Werte in einer bestehenden Tabelle ist derzeit nicht möglich. Damit eignet sich dieses Interface in dieser Form erst mal nur für die Erfassung einzelner Werte oder Texte. Achtung, bei der Implementierung der User Data Functions gilt es zu beachten, dass in dem Funktionsset nur Simple Input Datentypen erwartet werden dürfen. Ist auch nur eine Funktion mit einem komplexen Input Datentypen wie einer Liste definiert, erkennt Power BI keine der definierten Funktionen mehr.

Erfassung über Excel 

Obwohl Power BI immer mehr Verwendung findet, ist die Planung über Excel als Interface weiterhin sehr beliebt. Neben der Integration in Power BI liefern die User Data Functions auch eine Rest API Schnittstelle, die wir zur Datenübertragung aus Excel verwenden können.  Dazu ist zuerst die Authentifizierung zu implementieren.  Anders als in anderen Programmiersprachen wie Python gibt es in VBA keine Standard Library von Microsoft, die eine Authentifizierung mit der Microsoft Entra ID abwickelt, weswegen die Authentifizierung an dieser Stelle selber in VBA implementiert werden muss.   

Als nächstes wird eine in Fabric implementierte User Data Function benötigt, die die Werte aus Excel entgegennimmt, aufbereitet und dann in eine Tabelle schreibt oder aktualisiert. An dieser Stelle bietet die Database in Microsoft Fabric den präferierten Datenspeicher, weil die Fabric Warehouses derzeit nicht für punktuelle Schreibzugriffe und Updates optimiert sind. Es werden aktuell noch unnötig viele File Operationen im Hintergrund erstellt, was die Performance erheblich beeinflusst. 

Abbildung 1: Aktionen zur Erfassung über Excel

Neben der Schreibfunktionalität können weitere benötigte Prüfungen oder Funktionalitäten in die User Data Function implementiert werden. Denkbar wäre beispielsweise die Sicherstellung, dass Zahlen nur in bestimmten Zeiträumen zurückgeschrieben werden dürfen oder gegen eine zentrale Sperre der Planung geprüft werden.

Abbildung 1: Mögliches Layout zur Erfassung über Excel und ein API 

Im Gegensatz zu der Verwendung in Power BI, lassen sich mit dieser Lösung bereits ganze Tabellen zurückschreiben und damit eignet sich diese Möglichkeit z.B., wenn die Aufbereitung der Zahlen schon in einer Excel-Arbeitsmappe erfolgt. Alle Funktionen, die während der Erfassung nötig sind, wie z.B. Anzeige von gesperrten Monaten, Berechnungen während der Erfassung müssen im Excel implementiert werden. Funktionen, die erst beim Sichern erfolgen können, können in der User Data Function hinterlegt werden. Generell ist es zu präferieren, den Großteil der Logik zentral in der User Data Function zu implementieren, damit der Code in der Client Applikation nicht manipuliert werden kann und sich Änderungen zentral verwalten lassen. Denkbar ist es auch fundamentale Planungsfunktionalitäten wie das Splash Down in der API zu implementieren und damit den Funktionsumfang der Lösung erheblich zu erweitern. Die Möglichkeiten sind groß, allerdings auch immer verbunden mit Entwicklungsaufwand, während die Standardfunktionalitäten begrenzt bleiben. 

Fazit

Eine komplexe Planung, wie in unserem Blog Databricks und Planung oder einfache Eingabe beschrieben, ist mit Power BI noch nicht möglich. Erfassung von Parametern z.B. für eine Steuerung geht ohne viel Aufwand über das Power-BI-Interface. Laden von im Excel erzeugten Tabellen mit selbst entwickelten Funktionen ist über ein selbst entwickeltes API möglich. Gerne helfen wir ihnen, diese APIs zu entwickeln oder die für ihren Usecase passende Lösung zu finden.

Für komplette und komplexe Lösungen muss man noch auf Zusatztools (z.B. https://www.pmone.com/technologie/acterys/ ) zurückgreifen. 

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.

Ansprech­partner

Ilya Kirzner
Consultant
biX Consulting
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.