Review der File Upload Funktionalität aus einer Story in der SAC 

August 2025 / Update November 2025

Einführung

Seit dem Q3 2024 Release der SAP Analytics Cloud (SAC) können Planungsuser über einen Button in einer Story Daten aus einem File starten und das Ergebnis sofort sehen. Diese Möglichkeit erlaubt es den Business-Usern, viele Daten direkt aus der Story zu laden, ohne über den Modeler gehen zu müssen. Dies verschlankt den Datenladeprozess beachtlich und reduziert die Abhängigkeit von einem Administrator bei Routine-Datenimporten. 

In diesem Blog wird erklärt, wie man diese neue Upload-Funktionalität einrichtet, wie sie in der SAC Story funktioniert und wo wir noch Verbesserungsmöglichkeiten sehen. 

In folgenden Blogs gibt es noch mehr Information zu diesem Thema: 

Plan Data Upload Starter – Directly upload plan da… – SAP Community
New End User File Upload in SAP Analytics Cloud QR… – SAP Community
How to configure a dynamic file upload in SAP Anal… – SAP Community

Update Nov. 2025 – Version Q4/2025 

Wie angekündigt, kam mit der Version Q4/2025 die neue Funktion, beim Upload die Daten nach bestimmten Merkmalen vorab zu löschen. Jetzt kann bei der Definition des Upload Jobs in den Jobeinstellungen einen neue Importmethode „Teilmenge der Daten bereinigen und ersetzen“ ausgewählt werden. Wird diese Option gewählt, muss man noch die Merkmale angeben, nach denen die zu bereinigenden Daten selektiert werden sollen. 

Details sind in folgendem Blog beschrieben: 

New Clean and Replace Feature for SAC End User File Upload  

 

Einrichten des Uploads

Im ersten Schritt richtet der Administrator oder Modellierer den Upload-Job in der datenverwaltung ein. Hier muss ein Template-File (.csv/ xlsx und .txt sind unterstützt) hochgeladen werden, wobei gegebenenfalls nötige Transformationen definiert werden können. Im letzten Schritt ordnet man die Spalten des Files den Dimensionen des Modells zu. In den Job-Einstellungen wird zusätzlich festgelegt, ob der Import als Update/Aktualisieren oder als Anfügen/Anhängen erfolgen soll und ob das Vorzeichen nach Kontotyp gedreht werden soll.

Abbildung 1: Jobeinstellungen Import Job

Seit dem Q3/2025-Release kann man hier auch einstellen, ob und nach welcher Hierarchie sichergestellt werden soll, dass nur Daten für Blätter und keine Knoten geladen werden. 

Abbildung 2: Jobeinstellungen Import Job – Validierung

In der Datenzeitleiste der Datenverwaltung sieht man alle durchgeführten Ladejobs, auch die eines PlanungsUsers und kann hier erneut den Bericht der abgelehnten Zeilen laden. 

Abbildung 3: Neue Option für die Definition von Upload Jobs in der Datenverwaltung mit demn Potokollen in der Datenzeitleiste

Wenn der UploadJob angelegt ist, muss der Story Designer einen „Starter für Upload“Button in die Story einfügen. Der Button funktioniert ähnlich wie ein DataActionWidget für konsistente BenutzerErfahrung. Beim Konfigurieren der Story muss für diesen Starter zuerst das Modell ausgewählt und anschließend der zuvor angelegte UploadJob selektiert werden. Ebenso kann festlegt werden, wie die Zielversion bestimmt wird und ob die Daten automatisch veröffentlicht werden sollen oder nicht. Diese Optionen können entweder fest vorgegeben oder über ein Prompt den User bei der Ausführung bestimmen lassen. Wenn Planungsbereiche bei großem Datenvolumen verwendet werden, kann das Verhalten beim Upload weiter spezifiziert werden. Ist alles eingerichtet, ist die Story bereit für einen Daten-Upload. 

Abbildung 4: Einstellungen für den Datenupload Starter

Upload Prozess

Aus Endbenutzersicht ist der Prozess einfach: Wenn die Story geöffnet wird, erscheint ein Button zum Laden von Daten – versehen mit einer zuvor definierten Beschreibung, z. B. „Hochladen Vertriebsplanung“.  
Wird der Button gedrückt, öffnet sich ein Fenster, in dem die Datei – und falls nötig die Zielversion – ausgewählt werden kann. Unterstützt werden folgende Formate: CSV, XLSX und TXT. 

Wie oben bereits erwähnt, kann beim Anlegen des Upload-Jobs definiert werden, ob die Daten beim Laden aktualisiert oder angehängt werden sollen. Sehen wir uns nun an, wie sich diese beiden Methoden im Upload-Vorgang verhalten. 

Nehmen wir an, wir haben ein File, das die Zahlen enthält, die nach einem ersten Laden im Aktualisieren-Modus zu folgendem Bild führt: 

Abbildung 5: Laden eines Files mit „aktualisieren“, das alle angezeigte Daten enthält

Wird dasselbe File im Modus „Aktualisieren“ ein weiteres Mal geladen, bleiben die Zahlen in der SAC so, wie sie im File stehen – sie werden entsprechend aktualisiert. 

Wenn dieselben Daten hingegen ein zweites Mal im Modus „Anhängen“ geladen werden, werden die Inhalte zusätzlich eingefügt – die Werte verdoppeln sich dadurch. 

Was passiert nun, wenn im Modus „Aktualisieren“ ein File geladen wird, das nicht alle Zahlen ändert und z.B. die Daten für das Produkt A001 nicht beinhaltet? In diesem Fall werden alle Daten aus dem File als geändert markiert. Die Zahlen für das Produkt A001 bleiben jedoch unverändert (s. folgende Abbildung). 

Abbildung 6: Geänderte Zahlen nach em Laden eines Files ohne die Daten für A011 und Non_PRD_SRV

Im Aktualisieren-Modus erwartet man, dass die Daten ersetzt werden. Aber Achtung mit fehlenden Zeilen, diese werden nicht geändert. 

Jetzt liegt es am Anwender oder Entwickler wie fehlende Zeilen bei einem zweiten Laden im Aktualisieren-Modus behandelt werden sollen. Wenn erwartet wird, dass alle Zahlen aktualisiert werden, müssen die bestehenden Daten vorher manuell gelöscht werden. Erfolgt dies per Skript, ist besondere Vorsicht geboten: Der Fall, dass der Benutzer den Upload abbricht, muss dabei berücksichtigt werden (s. unten). SAP hat angekündigt, diese Verhalten mit dem Q4/2025-Release zu verbessern. 

Nach jedem Ladenvorgang erscheint eine Meldung, ob die Daten erfolgreich geladen wurden oder nicht: 

Abbildung 7: Meldung nach erfolgreichem Laden

Abbildung 8: Meldung nach dem Laden mit abgelehnten Zeilen

Wenn die Daten nur teilweise geladen wurden, kann eine Zusammenfassung der abgelehnten Zeilen als CSV – File heruntergeladen werden. Dieses File gibt einen Überblick über die abgelehnten Zeilen mit einem Grund für die Ablehnung. Typische Fehlerursachen sind Berechtigungsprobleme, fehlende oder falsche Stammdaten, Sperren oder im System definierte Datenprüfungen. In diesen Fällen muss der Planer die Fehler identifizieren, beheben und das File anschließend erneut über die SAC-Story laden. 

Die Zusammenfassung der abgelehnten Zeilen ist ein nützliches Hilfsmittel für eine erste Analyse und die Gründe für die Ablehnung. In der Praxis kann dies zeitaufwendig werden, die tatsächliche Ursache zu finden. Die Zusammenfassung zeigt zwar, welche Zeile fehlerhaft war, aber spezifiziert nicht, welche Stammdaten betroffen sind und ob dies eine Dimension betrifft oder mehrere. 

Lädt man beispielsweise ein File mit 10 Dimensionen und 200 Zeilen, von denen die Hälfte der Zeilen wegen Stammdatenproblemen abgelehnt wurde, wird die Suche nach den Fehlern aufwendig. Genauere Informationen zu den Ablehnungsgründen würden die Benutzerfreundlichkeit deutlich verbessern. 

Skript – Optionen

Beim Upload-Job gibt es zwei Zeitpunkte, bei denen man per Skript eingreifen kann: onBeforeExecute und onAfterExecute. Das onBeforeExecute Skript wird ausgeführt, bevor der Upload Bildschirm erscheint, das onAfterExecute Skript läuft, nachdem der Ladeprozess beendet ist. 

Als Entwickler ist es wichtig zu beachten, dass die Skripte auch ausgeführt werden, wenn der Anwender den Prozess im Popup abbricht oder wenn die Daten nur teilweise geladen werden oder der Upload komplett fehlschlägt. Um sicherzustellen, dass die Befehle nur ausgeführt werden, wenn der Prozess vollständig erfolgreich war, kann man folgendes Coding in der onAfterExecute-Methode verwenden (oder natürlich den Status Warnung bzw. Fehler entsprechend abfragen): 

if (status === DataUploadExecutionResponseStatus.Success ) { 

…; 

} 

Dieser Status ist im Event onBeforeExecute nicht bekannt! Achten Sie daher darauf, dass Änderungen aus dem onBeforeExecute-Skript wieder rückgängig gemacht werden, wenn der Anwender den Vorgang abbricht oder es Probleme mit abgelehnten Zeilen gab. 

Leider steht die Information zu den Ablehnungen nicht im Skript zur Verfügung. 

Release Q3/2025

Data Upload: control visibility to rejected records in end-user data upload and data load jobs 

Anwender können nicht abgehlehnte Sätze herunterladen, wenn sie die Daten nicht sehen dürfen 

 

Plan Entry: enforce loading to leaf members during data file upload 

Sicherstellen, dass nur Blätter und nicht Knoten eines Merkmals geladen werden können. 

Bessere Fehlerbearbeitung 

Die Fehlerbearbeitung ist umständlich. Es wäre wünschenswert, fehlerhafte Zeilen direkt in einem Popup-Fenster korrigieren zu können: 

https://influence.sap.com/sap/ino/#/idea/221946 

Beispiel für die File-Struktur

Anwender müssen wissen, wie das File aufgebaut sein muss. Daher sollte ihnen ein Beispiel-File zur Verfügung gestellt werden – idealerweise über einen Link in der Story. Aktuell bietet SAC keine Möglichkeit, ein solches Beispiel-File automatisch aus der Definition des Ladeprozesses zu generieren. 

Kein Laden von Stammdaten möglich 

In der aktuellen Lösung können während des Ladevorgangs nur Bewegungsdaten geändert werden. Stammdaten müssen hingegen vorab in einem separaten Prozess angelegt werden. Derzeit besteht lediglich die Möglichkeit, eine Story anzulegen, in der Stammdaten per Script hinzugefügt werden. SAP hat diese Einschränkung in einem Blog bereits thematisiert und eine Lösung in einem zukünftigen Update angekündigt: 

New End User File Upload in SAP Analytics Cloud QRC3 2024  

Nur feste Spalten im File möglich

In dem Fall, dass z.B. Daten für einen rollierenden Forecast geladen werden sollen, enthalten die Spalten die zu planenden Quartale. Diese ändern sich mit jedem Zyklus. In der aktuellen Lösung müssen die Spaltenüberschriften jedoch fest definiert sein.  

Dies ist in folgendem Blog mit einem Workaround erklärt: 

How to configure a dynamic file upload in SAP Analytics Cloud 

Neben dem Workaround, der hier erklärt wird, kann auch mit einem Hilfs-Datenmodell arbeiten, das beispielsweise immer vier zu planende Quartale enthält. Im Skript nach dem Hochladen könnten die Daten dann aus dem Hilfs-Datenmodell in die aktuellen Planperioden des richtigen Modells geladen werden. 

Die Verbesserungswünsche zu diesem Problem: 

Data Upload Starter with updating Local Dimension Member Option 

Import Job – pivoting on Date dimension doesn’t allow dynamic values 

Daten löschen während des Ladeprozesses 

Bessere Verarbeitung von fehlenden Daten im File im „Aktualisieren“ Fall, wie oben schon erwähnt: 

Data Upload Starter Clean/Replace and Clean/Replace Subset not available 

Dies ist für das Release Q4/2025 geplant: 

Plan Entry: clean and replace for data file upload 

Update Nov. 2025: Diese Funktionalität wurde wie angekündigt zur Verfügung gestellt (Details s. oben)! 

Fazit

Die Lade-Aktivität ist vollständig nachvollziehbar und bietet Transparenz und Nachvollziehbarkeit für alle von Endbenutzern vorgenommenen Datenänderungen. Administratoren können den Verlauf der Daten-Uploads auf der Registerkarte „Datenverwaltung“ einsehen, während das Aktivitätsprotokoll eine detaillierte Nachverfolgung der durch den Upload-Prozess vorgenommenen Änderungen ermöglicht. Derzeit ist es jedoch nicht möglich, die spezifische Zelle zu ermitteln, die das Problem verursacht hat. Dies würde den Benutzern helfen, die Ursache für Ablehnungen leichter zu identifizieren und den gesamten Fehlerbehebungsprozess deutlich verbessern. 

Schließlich erlaubt die Ablehnungsübersicht keine direkten Datenkorrekturen. Benutzer müssen die fehlerhaften Daten manuell in einer neuen Datei anpassen und anschließend über die SAC-Story-Oberfläche erneut hochladen. 

Insgesamt verbessert der neue integrierte Story-Trigger für Flatfile-Uploads in SAC den Planungsworkflow erheblich, da Planer Daten direkt aus Stories hochladen können, ohne auf Modellierer oder Administratoren angewiesen zu sein. Dies rationalisiert den Prozess, unterstützt eine flexible Konfiguration und gewährleistet die Rückverfolgbarkeit durch Upload-Verlauf und Aktivitätsprotokolle. Der Ablehnungsübersicht fehlen jedoch detaillierte Einblicke in Stammdatenfehler, was die Fehlerbehebung bei komplexen Datensätzen zeitaufwändig macht.  

 

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.