Hands On mit dem neuen Modell auf der SAP Analytics Cloud

Im März kamen durch das Q2 2021 Release mehrere neue Funktionen zur SAC hinzu. Unter anderem eine Möglichkeit, die Datenmodellierung flexibler und effektiver zu gestalten. Ein neues Modell wird dem Modellierer zur Verfügung gestellt, mit dem jetzt auch Kennzahlenmodelle erstellt werden können.

Bis jetzt war es in der SAP Analytics Cloud nicht möglich, Kennzahlenmodelle abzubilden. Wenn die Datenquelle in einem System als Kennzahlenmodell vorlag, musste mit einem zusätzlichen Aufwand ein Mapping von einem Kennzahlen- zu einem Kontenmodell vorgenommen werden, damit die Daten auswertbar/planbar wurden. Jetzt ist dies endlich Geschichte. Die SAC ermöglicht beides in einem Modell.

Dieses neue Datenmodell wird in diesem Artikel als Hybridmodell bezeichnet. Hybrid, weil aus einem Hybridmodell sowohl ein Kennzahlen- und/oder ein Kontenmodell erstellt werden kann. Dieses Modell wird, so scheint es, zukünftig das alte Datenmodell (hier bezeichnet als Classic Account Model (siehe Abbildung 1)) ersetzen und rückt somit in den Fokus für neue Entwicklungen und Funktionen.

 

Das neue Datenmodell auf der SAC kann genutzt werden, indem Sie…

  • Start with a blank model auswählen und dann bei der Auswahl in der unteren Abbildung 1 auf New Model klicken oder
  • Bei einem bestehenden Modell (Classic Account Model) die Funktion Migrate to New Model Type unter Edit auswählen (siehe Abbildung 2)

Abbildung 1: Create New Model -> Blank Model -> New Model

Abbildung 2: Workspace Model Structure -> Edit -> Migrate (rot markiert)

In diesem Artikel soll ein Einblick in das Hybridmodell gegeben werden, wie es zu handhaben und was bei einer Migration von bestehenden Modellen (Classic Account Models) zu beachten ist.

 

Erste Eindrücke

Das Hybridmodell ermöglicht es endlich, Kennzahlenmodelle zu erstellen und somit völlig neue Szenarien aufzubauen. Es wird wichtiger sich Gedanken zu machen, wie seine Modelle auf der SAC modelliert werden sollen, weil dadurch Datenmengen verringert und verbessert werden können. Des Weiteren ermöglicht es auch bestehende Datenmodelle aus anderen Systemen, die bis dahin noch nicht anbindbar waren (außer mit zusätzlichen Mapping auf ein Kontenmodell), an die SAC anzuschließen.

Weiter Unterschiede

Neue Zahlentypen

Eine weitere Neuerung, die mit dem Hybridmodell kommt, sind neue Zahlentypen z.B. Integer. Es wird somit ermöglicht in Zukunft endlich ganze Fahrräder zu planen, ohne den Workaround mit Nachkommerstellen einzurichten, mit der Gefahr, dass bei Berechnungen im Hintergrund aufgerundet wird.

Kein automatisches Anlegen von Stammdaten

Bei dem Classic Account Model werden neue Stammdaten beim Beladen automatisch angelegt. Dies geht bei dem Hybridmodell (noch) nicht. Beim Beladen ist somit sicherzustellen, dass vorher alle Stammdaten gepflegt sind.

Währungsumrechnung

Ebenso sind die Möglichkeiten zur Währungsumrechnung während der Planung erweitert. Jetzt kann man z.B. Werte in Transaktionswährung erfassen und während der Eingabe direkt in Buchungskreis- und Konzernwährung umrechnen lassen, bevor man die Daten überträgt! Dies erleichtert eine konsistente Erfassung.

Berechnete und eingeschränkte Kennzahlen

Außerdem können nun berechnete und eingeschränkte Kennzahlen erstellt werden, ohne diese über Account erstellen zu müssen.

 

Datenmodell aus Datensatz erstellen zu lassen, geht nur für Kontenmodelle

Diese neuen Funktionen ermutigen, Neuentwicklungen im Hybridmodell zu erstellen. Leider kann das Hybridmodell nicht aus einem Datensatz generiert werden, es muss immer erstellt werden. Es macht keinen Unterschied, ob die Datenquelle als Konten- oder Kennzahlenmodell vorliegt. SAP generiert immer ein Kontenmodell, dass manuell in ein Hybridmodell migrieren kann (s. nächstes Kapitel).

Migration

Das Auffallendste bei einer Migration ist, dass der bekannte Data Wrangling Editor entfällt. Das bedeutet, dass es seitens der SAC noch keine Funktionen gibt, welche Anpassungen ermöglichen, bei der Übertragung der Modelle. Dort wäre eine Mappingfunktion gut aufgehoben gewesen, um aus einer Kennzahl mehrere zu befüllen (abhängig von der Account Dimension). Nach dem Aktivieren Migrate to New Model Type wird das alte Modell gelöscht und SAC erstellt ein Hybridmodell. Wenn ich mit der Migration nicht zufrieden bin, gibt es kein Undo! Somit ist es sehr wichtig, dass vorher einige Schritte vorbereitet werden.

Es sollte niemals ein Modell, welches genutzt wird, migriert werden. Dies ist auch nicht möglich, da Stories nicht migriert werden können. Besser ist es, ein Duplikat von dem zu migrierenden Modell zu erstellen. Dieses Duplikat hat keine Verbindungen zu Stories und kann somit migriert werden. Die Stories müssten entweder neu händisch gebaut werden oder Sie versuchen es, indem Sie die Stories auch duplizieren, und das Hybridmodell als neue Datenquelle hinterlegen/austauschen.

Es ist außerdem zu beachten, dass die Währungsumrechnung ausgeschaltet wird, sonst kann keine Migration erfolgen. Nach der Migration kann die Währungsumrechnung wieder angestellt werden. Import Jobs werden auch nicht migriert. Somit sollten alle migrierten Modelle darauf untersucht werden.

Ein weiterer wichtiger Punkt ist, dass bei der Migration von bestehenden Kontenmodellen die Eigenschaften der Einheit wegfallen. Auf dem alten Classic Account Model kann über die Dimension Account die Einheit & Währung eingestellt werden, wie in der Abbildung 3 zu sehen ist.

 

Abbildung 3: Classic Account Model: Dimension Account

Eine Story auf diesem Modell zeigt auch die Einheiten & Währungen aus der Dimension Account entsprechend mit den Symbolen (siehe Abbildung 4).

 

Abbildung 4: Story auf einem Classic Account Model

Auf der Abbildung 5 ist zu erkennen, dass die Währungssymbole nach der Migration entfallen. Dies kommt daher, dass das Hybridmodell keine gemischten Kennzahlen kennt. Die automatisch generierte Kennzahl hat ein Feld, wo auch die Einheit & Währung eingestellt werden können. Jedoch muss man sich entscheiden, ob diese Kennzahl Einheiten oder Beträge enthält. In dem gezeigten Beispiel sind im zu migrierendem Kontenmodell Mengen- und Währungseinheiten. Nach der Migration werden die Kennzahlen entweder alle als Erträge oder Mengen interpretiert. Es gibt jedoch auch die Möglichkeit eine einheitlose Kennzahl zu erstellen. Diese Einstellung ist in der unteren Abbildung zu sehen. Dabei muss bei der Berichtserstellung darauf geachtet werden, dass der Anwender seine Kennzahlen korrekt interpretiert.

 

Abbildung 5: Story auf einem Hybriden Model (nach einer Migration)

Dies ist noch das größte Problem des Hybridmodells. Um die Migration vollständig zu beenden, müssen die Kennzahlen auf mehrere Kennzahlen (Betrag, Menge) aufgeteilt werden (siehe folgendes Gedankenspiel).

Gedankenspiel

Um eine vollständige Migration zu ermöglichen, ist dann doch noch manueller Mehraufwand nötig. Eine Idee wäre, dass das zu migrierende Classic Account Model so oft dupliziert wird, wie verschiedene Einheiten in dem ursprünglichen Model vorliegen. Jedes der duplizierten Classic Account Modelle müsste nun auf eine Einheit im Modell gestutzt werden, sodass in unserem Fall ein Modell mit nur Mengeneinheiten und ein Modell mit nur Währungen vorliegen. Diese könnten dann einzeln migriert werden. Nach der Migration muss der automatisch erstellten Kennzahl die entsprechende Einheit zugeordnet werden.

In einer Story könnten dann die beiden Modelle hinterlegt und miteinander verknüpft werden. Diese Funktion heißt Data Blending. Hierbei gibt es jedoch zu Limitationen. Weitere Informationen zu Data Blending (https://blogs.sap.com/2019/11/05/sap-analytics-cloud-blending-information-part-1/).

Alternativ könnten durch eine DataAction die Werte eines Modells in eine neue Kennzahl des anderen kopiert werden.

Dadurch könnte ermöglicht werden, dass die Daten gemeinsam auswertbar bleiben.

 

Fazit

Das Hybridmodell erfüllt schon einen lang ersehnten Wunsch, Kennzahlenmodelle nun auch abbilden zu können. Dies ermöglicht Flexibilität in der Datenmodellierung, sowie mögliche Performancevorteile. Außerdem können nun weitere Datenquellen an die SAC angeschlossen werden, die vorher durch ihr Kennzahlenmodell nicht angeschlossen werden konnten. Neu erstellte Datenmodelle werden meistens auf dem Hybridmodell entwickelt werden, weil dies mehr Flexibilität bietet.

Bei der Migration von einem Classic Account Model auf ein Hybridmodell gibt es jedoch noch Verbesserungsbedarf. Das Verlieren von Einheiten ist eine Herausforderung, die nicht dazu ermutigt Classic Account Modelle zu migrieren. Es bleibt abzuwarten, ob sich die SAP dieses Problems annimmt.

Spannend ist es auch abzuwarten, ob SAP den Standard-Content migriert oder neuen Content erstellt.

 

Weitere Informationen finden sich unter dem Link (https://saphanajourney.com/sap-analytics-cloud/resources/sap-analytics-cloud-new-model/) oder in der Hilfe in der SAC. Die anderen Erkenntnisse leiten sich durch Try & Error ab (Stand 28.04.2021).

Ansprechpartner

Julius Nordhues

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.

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.