Cashflow Forecast mit SAP BDC und SAP Databricks: Der ultimative End-to-End-Leitfaden

Das Herzstück unseres Cashflow-Forecast-Szenarios ist der einfache und sichere Zugriff auf die relevanten S/4HANA-Daten. Der BDC (Business Data Cloud) Cockpit dient hierbei als zentrale Drehscheibe für die Bereitstellung standardisierter SAP-Datenprodukte. 

Dieses Video demonstriert den Zero-Copy Data Sharing Principle. Ziel ist es, den Data Scientists direkten Zugang zu den SAP-verwalteten Datenprodukten zu verschaffen, ohne dass eine aufwendige Datenkopie oder Replikation erforderlich ist. 

Delta Sharing wird hiefür verwendet, ein offenes Protokoll, das von Databricks und Linux Foundation entwickelt wurde. Es ermöglicht den sicheren, plattformübergreifenden Datenaustausch in Echtzeit über Clouds und Regionen hinweg. 

Im Video demonstrierte Schritte: 

Für das Sharing des Datenprodukts Cashflow sind ADMIN-Rechte in der SAP Business Data Cloud erforderlich. 

1. Anmeldung im SAP Business Data Cloud Cockpit und Navigation über Search zum Data Catalog. 

2. Suche nach dem Datenprodukt Cashflow und Öffnen der Kachel. 

3. Klick auf den Share-Button auf der Detailseite, um den Dialog zu öffnen. 

4. Eingabe eines Share Name und Auswahl des Ziel-SAP Databricks Workspace, Klick auf Share. 

5. Anmeldung bei SAP Databricks und Navigation zum Unity Catalog. 

6. Navigation zu Delta Shares Received, Suchen der Tabelle cashflow und Klick auf den Tab Sample Data. 

7. Klick auf Select Compute, Auswahl des Serverless Starter Warehouse, anschließend Start and Close. 

8. Vorschau der cashflow Sample-Daten zur Validierung des Zugriffs. 

Nachdem wir im ersten Schritt den sicheren Zugang zu den S/4HANA-Daten in unserer Databricks-Umgebung hergestellt haben, widmet sich dieser Abschnitt der Datenanreicherung und Vorbereitung für unser Zeitreihen-Forecasting-Modell. 

Ziel ist es, das Cash Flow-Datenprodukt so umzuformen, dass es für die Vorhersage des Cashflows in den kommenden Perioden optimal nutzbar ist. Das folgende Notebook demonstriert den gesamten Workflow, der später in die SAP Datasphere in der SAP Business Data Cloud (BDC) zurückgespielt wird. 

Den vollständigen Code, der in diesem Video demonstriert wird, ist hier zufinden: Notebook

Demonstrations-Workflow umfasst die folgenden vier Hauptschritte: 

1. Pakete installieren und importieren 

Wichtig: Zur Isolierung der erstellten Daten-Assets erstellen wir einen Katalog (<CATALOG_NAME>, z.B. uc_cash_liquidity_forecast) und ein entsprechendes Schema (<SCHEMA_NAME>, z.B. grp041) im Databricks Unity Catalog. 

2. Datenprodukt Cashflow laden 

Aus dem BDC stellen wir eine Delta-Enabled lokale Tabelle über die Delta-Share bereit, die uns eine Tabelle mit mehreren Einträgen für denselben Primärschlüssel liefert. 

Der Datensatz enthält die Spalte __OPERATION_TYPE, die die Transaktionsart (Insert, Update, Delete) kennzeichnet, sowie die Spalte __TIMESTAMP, die angibt, wann diese Änderung erfolgt ist. 

Da wir die Cashflow-Transaktionssätze verwenden möchten, transformieren wir unseren Datensatz so, dass pro Primärschlüssel der aktuellste Eintrag geliefert wird. 

Falls der aktuellste Eintrag eine Löschung darstellt, wird dieser Datensatz herausgefiltert. 

3. Daten für Zeitreihen-Forecasting vorbereiten 

Die Datenvorbereitung ist entscheidend für die Qualität der Prognose. Wir modellieren die Daten auf einer monatlichen Zeitreihe, basierend auf dem Buchungsdatum (Posting date), da dieses den Zeitpunkt der Cashflow-Buchung markiert. 

Folgende Transformationsschritte werden durchgeführt: 

1. Ersetzen leerer Strings durch Nullwerte. 

2. Auswahl notwendiger Spalten und Filtern ungültiger Datumsangaben/Nullwerte im Buchungsdatum. 

3. Abrunden des Buchungsdatums auf den Monat (floor) und Umbenennung der Datums- und Wertspalten. 

4. Gruppierung der Daten nach Datum und Summierung des Cashflows pro Monat. 

5. Erzeugung einer kontinuierlichen Zeitreihe zwischen dem minimalen und maximalen Datum der Daten. 

6. Verknüpfung der generierten Zeitsequenz mit den Cashflow-Daten, um eine lückenlose Zeitreihen-Datenstruktur zu erhalten. 

7. Auffüllen von Nullwerten mit 0 (da an diesen Tagen kein Cashflow erfasst wurde). 

8. Konvertierung des Spark Dataframes in einen Pandas Dataframe für die ML-Modellierung. 

4. Vorbereitete Zeitreihendaten speichern  

Um sicherzustellen, dass für das Training und die spätere Prediction exakt dieselben vorbereiteten Daten verwendet werden, speichern wir den transformierten Daten im Databricks Feature Store. Dies eliminiert die Notwendigkeit, das Datenvorbereitungsskript in beiden Notebooks zu wiederholen. 

Nach erfolgreicher Ausführung ist die erstellte Tabelle prepared_cash_flow_time_series im Unity Catalog unter dem entsprechenden Schema Ihres Benutzers abrufbar. 

Nach der gründlichen Datenvorbereitung in der zweiten Demo widmen wir uns nun dem Herzstück des Workflows: dem Training eines Zeitreihen-Forecast-Modells. In diesem Schritt erweitern wir das Cash Flow-Datenprodukt, indem wir die Prognosewerte für die kommenden Perioden berechnen. 

Die Aufnahme demonstriert die Hyperparameter-Optimierung und die Modell-Selektion mithilfe der AutoTS-Bibliothek, sowie das nachgelagerte Tracking des besten Modells mit MLFlow. 

Den vollständigen Code, der in diesem Video demonstriert wird, ist hier zufinden: Notebook

Workflow-Schritte: 

1. Pakete installieren und importieren 

Für diesen Prozess sind zwei Hauptpakete erforderlich: 

• mlflow: Zur Verfolgung (Tracking) des Machine-Learning-Modell. 

• AutoTS: Eine Time-Series-Bibliothek, die automatisch die Hyperparameter-Optimierung über eine Vielzahl von Zeitreihenmodellen durchführt. 

2. Laden der vorbereiteten Zeitreihen-Tabelle 

Die im Feature Store persistierte und bereinigte Tabelle aus dem vorangegangenen Schritt wird als Input verwendet. Wir laden die vorbereiteten Daten aus dem Unity Catalog, um sicherzustellen, dass das Training auf konsistenten Daten basiert. 

<PREPARED_TABLE_NAME> prepared_cash_flow_time_series  

3. Training des Forecasting-Modells mit AutoTS und MLFlow 

Wir trainieren den Zeitreihen-Algorithmus unter Verwendung der AutoTS-Bibliothek. Der Vorteil von AutoTS liegt in seiner Fähigkeit, verschiedene Modelle und Datenvorbereitungsschritte parallel auszuführen und zu validieren, um so die optimale Konfiguration zu finden. 

MLFlow Tracking: Alle relevanten Aspekte des Trainings werden unter dem MLflow Experiment namens Time Series protokolliert. Da das AutoTS-Paket kein automatisches Logging (Autologging) des Modells bereitstellt, erstellen wir eine spezielle Python-Klasse für den prediction, um die MLflow-prediction nutzen zu können. 

Wichtige AutoTS-Parameter: 

Die Performance des Modells hängt von diesen Parametern ab: 

Nach erfolgreicher Ausführung solltest du das trainierte Modell cashflow_ts_model im Unity Catalog unter deinem Schema finden. 

Nach dem erfolgreichen Training unseres AutoTS-Modells geht es in diesem Schritt darum, die Cashflow-Prediction tatsächlich anzuwenden und die resultierenden, angereicherten Daten für die weitere Nutzung bereitzustellen. 

In diesem Notebook verwenden wir das protokollierte und trainierte Modell aus MLflow, um den Cashflow für die kommenden Perioden zu forecasten und die Ergebnisse in einer Delta-Tabelle zu speichern. 

Den vollständigen Code, der in diesem Video demonstriert wird, ist hier zufinden:  Notebook

Workflow-Schritte: 

1. Pakete installieren und importieren 

Zuerst werden alle notwendigen Pakete importiert, um die Spark Session einzurichten und das im vorherigen Schritt protokollierte Modell abrufen zu können. 

2. Spark Session Setup und Datenprodukt-Konsum 

Die Spark Session wird konfiguriert, um auf die notwendigen Ressourcen zuzugreifen. Hier konsumieren wir die prepared_cash_flow_time_series Tabelle, das als Input für den prediction dient. 

3. Anwendung des Zeitreihen Forecast (Time Series Forecasting) 

Der zentrale Schritt ist die Anwendung der prediction Model. 

• MLflow Modell abrufen: Wir suchen in unserem MLflow Experiment die zuletzt erfolgreiche Run ID aus der Trainingsprozedur und verwenden diese, um das trainierte Modell zu laden. Dies gewährleistet, dass wir die beste Modellversion für die prediction verwenden. 

• Prediction: Das abgerufene Modell wird genutzt, um die Spark Dataframe mit den Cashflow-Daten an die predict-Funktion zu übergeben. Die Funktion liefert anschließend die Prediction-Werte zurück. 

4. Erstellung der Cashflow Prediction Tabelle 

Die gewonnenen Daten werden in einer neuen Delta-Tabelle namens cashflow_prediction gespeichert.  

Wichtig: Die erstellte Prediction-Tabelle enthält einen Constraint Key, der aus den Spalten "date" und "CompanyCode" besteht, um die Eindeutigkeit der Werte zu gewährleisten. 

Nach erfolgreicher Ausführung validiere die neu erstellte Tabelle cashflow_prediction im Unity Catalog in deinem erstellten Schema und dort die Prediction-Daten in der Vorschau anzeigen lassen. 

Wir haben die Cashflow-Daten erfolgreich vorbereitet, ein Forecast-Modell trainiert und die Cashflow Prediction Tabelle generiert. Im finalen Schritt muss dieses angereicherte Datenprodukt die cashflow_prediction den SAP-Systemen (BDC Data Catalog und Datasphere) wieder zur Verfügung gestellt werden. 

Diese Aufnahme demonstriert, wie die Prognoseergebnisse zur Veröffentlichung in den Data Catalog der SAP Business Data Cloud gelangen. Wir erstellen hierfür ein benutzerdefiniertes Datenprodukt unter Verwendung der Python-Bibliothek sap-bdc-connect-sdk. 

Der Schlüssel: Wir nutzen erneut das Delta Share Protokoll. Die Ergebnistabelle bleibt physisch in SAP Databricks gespeichert (Zero-Copy), ist aber über den BDC Data Catalog remote zugänglich. 

Den vollständigen Code, der in diesem Video demonstriert wird, ist hier zufinden: Notebook

Notwendige Schritte für die Veröffentlichung: 

1. Pakete installieren und laden 

Um das erweiterte Datenprodukt in die SAP Business Data Cloud zurückzuspielen, ist die Installation und das Laden des SAP SDK (sap-bdc-connect-sdk) zwingend erforderlich. 

2. Client für sap-bdc-connect-sdk erstellen 

Es werden zwei Client-Objekte initialisiert: 

• Der DatabricksClient, der die Databricks-Dienstprogramme (dbutils) zur Informationsbeschaffung aus der Databricks-Umgebung erhält. 

• Der BdcConnectClient, der wiederum den DatabricksClient als Parameter nutzt, um die Verbindung zur BDC aufzubauen. 

3. Delta Share erstellen 

Ein Share ist der Mechanismus für den plattformübergreifenden Zugriff auf die Daten. Die Erstellung oder Aktualisierung eines Shares beinhaltet die Aufnahme spezifischer Attribute (wie @openResourceDiscoveryV1) in den Anforderungstext, die mit dem Open Resource Discovery (ORD) Protokoll übereinstimmen müssen. 

4. Empfänger zum Share hinzufügen 

Um das Datenprodukt spezifisch für die BDC freizugeben, muss sap-business-data-cloud als Empfänger (Recipient) für den neu erstellten Share ausgewählt werden. 

5. Open Resource Discovery (ORD) Objekt erstellen 

Das ORD-Protokoll stellt sicher, dass der Share ordnungsgemäß strukturiert und nach standardisierten Vorgaben beschrieben wird. Hierbei werden Parameter wie <DATA_PRODUCT_NAME>, <SHORT_DESCRIPTION> und <LONG_DESCRIPTION> ausgefüllt. Dies ist essenziell für die Auffindbarkeit im Data Catalog. 

6. Core Schema Notation (CSN) Objekt erstellen 

Die Core Schema Notation (CSN) dient als standardisiertes Format zur Konfiguration und Beschreibung von Shares. Es wird empfohlen, den CSN-Inhalt in einer separaten Datei vorzubereiten und diesen in den Anforderungstext aufzunehmen, um die Genauigkeit und die Einhaltung der CSN-Spezifikationen zu gewährleisten. 

7. Datenprodukt veröffentlichen 

Ein Datenprodukt stellt eine Abstraktion dar, die Daten oder Datensätze innerhalb eines Systems repräsentiert. Es bündelt Ressourcen, um einen effizienten Datenzugriff und die Nutzung durch integrierte Systeme zu ermöglichen. Die Veröffentlichung erlaubt es den SAP-Systemen, auf die neu erzeugten Cashflow_Prediction zuzugreifen und diese zu konsumieren. 

8. Veröffentlichtes Datenprodukt im BDC Data Catalog validieren 

Nach erfolgreicher Veröffentlichung kann man das neue Datenprodukt (grp041 Cashflow Predictions Data Product) im BDC Data Catalog validieren. Es ist nun in der SAP-Landschaft zur weiteren Berichterstattung (z.B. in SAP Datasphere) verfügbar.