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

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. 

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. 

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. 

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 

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.