Changelog für Kommentare in einer Query anzeigen

Motivation

Kommentare sind in Planungsanwendungen sehr häufig erforderlich. SAP bietet zwei Möglichkeiten, Kommentare zu speichern:  

  • Über eine Dokumentenablage  
  • Attribute als Kennzahl  

Eine kurze Einführung in die verschiedenen Möglichkeiten finden Sie z.B. in den folgenden Blogs: 

https://www.nextlytics.com/de/blog/integrierte-kommentarfunktionen-in-sap-analytics-cloud-und-bw/4hana 

https://evosight.com/comments-in-bw-ip-using-characteristic-as-key-figure 

Wir verwenden die Methode, ein Attribut als Kennzahl zu verwenden, häufig aus den folgenden Gründen:  

  • Kommentare sind direkt in der Abfrage sichtbar  
  • Berichte können auf Kommentaren aufgebaut werden   
  • Bei der Verwendung eines Dokumentenspeichers sind die Kommentare nur als Excel-ähnliche Kommentare sichtbar und Sie müssen auf jede Zelle klicken, um den Kommentar zu lesen.  
  • Ältere und stabilere Lösung  
  • Die Beschränkung auf 250 Zeichen ist in den meisten Fällen nicht kritisch  

Nun bestand die Anforderung, die Historie der Kommentare in einem Bericht anzuzeigen. Da es sich hierbei nicht um eine Standardlösung handelt, möchten wir unseren Ansatz mit Ihnen teilen.  

Durch die Aktivierung des Audit-Trails in einem Composite-Provider ist es möglich, die Historie der Änderungen für Kennzahlen ohne Programmierung anzuzeigen. 

Leider funktioniert dies nicht für Kommentare. Der Audit-Trail zeigt keine Request – Nummer für Kommentare und der Historie der Kommentare wird nicht angezeigt. 

Die Historie der Kommentare wird jedoch in der Tabelle „Changelog“ gespeichert. Dies ist der Ausgangspunkt für unsere Lösung. Wir zeigen Ihnen zwei Möglichkeiten, um diese Informationen aus dem Changelog innerhalb einer Abfrage bereitzustellen:  

  • über eine HANA-Berechnungsansicht  
  • über ABAP CDS-View  

Beide Möglichkeiten führen zu einem identischen Ergebnis. Welche Sie verwenden, hängt von Ihren Kenntnissen und / oder Einschränkungen bei der Verwendung von HANA-Artefakten ab.  

Natürlich wird das Lesen von Daten aus der Changelog-Tabelle in einem Bericht nicht offiziell von SAP unterstützt, da SAP den Namen oder die Struktur dieser Tabellen ändern kann, aber es funktioniert recht stabil.   

Die Protokollierung von Änderungen über BADI BADI_RSPLS_LOGGING_ON_SAVE wäre eine weitere Möglichkeit. Da diese Option jedoch mehr Entwicklungsaufwand erfordert, wird diese Lösung hier nicht untersucht. Für weitere Details siehe: 

https://help.sap.com/docs/ABAP_PLATFORM_NEW/12af290e80264faab3b1e6ac283950a2/4cae4e3fdd6e3b9ee10000000a42189b.html?locale=de-DE&version=202310.000 

Warum funktionieren Audit-Trails bei Kommentaren nicht? 

Zunächst wollen wir sicherstellen, dass wir keine Option übersehen haben und herausfinden, warum Audit-Trails für Kommentare nicht verfügbar sind.  

Wenn Sie den Audit-Trail in einem Composite-Provider aktivieren, stellt das System nur die Informationen aus den Lade-Requests im Bericht zur Verfügung. Sobald Sie die Plandaten aktivieren, gehen die Request – Informationen verloren und der Audit Trail zeigt keine Informationen mehr an. Technisch gesehen werden die Daten von Tabelle 1 in Tabelle 2 des aDSO verschoben (z.B. für aDSO ### sind dasTabellen /BIC/A###1 und /BIC/A###2).   

Weitere Details zu den Arten eines aDSO und die dazugehörigen Tabellen siehe z.B.:  https://learning.sap.com/learning-journeys/upgrading-your-sap-bw-skills-to-sap-bw-4hana/working-with-the-datastore-object-advanced-_b1fbbc9a-e6ad-44bf-bfce-d5b2defa3ccb 

Aber nur für ein aDSO vom Typ Data Mart basiert das Reporting auf einem Join der Eingangstabelle 1 und der Tabelle 2. Bei allen anderen Arten von aDSOs basiert das Reporting immer nur auf der Tabelle 2 mit den aktivierten Daten ohne Request und damit Audit-Trail Informationen!  

Da das Data Mart alle Attribute als Schlüsselfelder benötigt, sind Attribute als Kennzahlen bei dieser Art von aDSO nicht möglich. Aus diesem Grund sind auch keine Audit Trails für Kommentare verfügbar.  

Wenn Sie jedoch das Änderungsprotokoll für das Standard-Datenspeicherobjekt aktivieren, ist die Historie in Tabelle *3 des aDSO einschließlich der Historie der Kommentare verfügbar! 

Weitere Details sind verfügbar unter: https://community.sap.com/t5/financial-management-blogs-by-sap/bpc-embedded-model-auditing-feature-in-adso-and-infocube/ba-p/13357497 

Demo Szenario 

In unserem Beispiel haben wir Kennzahlen und Kommentare zu Demozwecken in der einem aDSO. Normalerweise würden wir empfehlen, Kennzahlen in einem aDSO vom Typ Data Mart und Audit-Informationen und Kommentare in einem separaten aDSO zu speichern.  

Unser aDSO ist ein „Standard Data Store Object“ mit aktiviertem Änderungsprotokoll und Planung. 

Dieses aDSO hat folgenden Feldern und ein Attribut als Kennzahl 

In der Tabelle „Änderungsprotokoll“ sehen Sie die historischen Kommentare. Benutzer, Datum und Uhrzeit der Änderung sind in der Request – nummer (REQTSN) verborgen. 

Lösung über die HANA Calculation View 

In dieser Lösung verwenden wir eine HANA-Calcualation view, die von einem Compoiste Porvider konsumiert werden kann.  

Zunächst erstellen wir eine Calculation View, um die Informationen aus der Änderungsprotokolltabelle verfügbar zu machen und verknüpfen auch die Tabelle RSPMREQUEST, um Benutzer und Zeitpunkt der Anfrage auf praktische Weise zu ermitteln.  

Außerdem filtern wir nach dem Speicherort CL (Änderungsprotokoll) in der Request – Tabelle (RSPMREQUEST), um nur eine Zeile je Request – Nummer zu bekommen:
 

Details des left outer join: 

Nun erstellen wir einen Composite Provider mit dem ursprünglichen aDSO und unserem Calculation View mit dem Changelog. 

Wir ordnen die Felder des Changelogs den gleichen Feldern zu wie die ursprüngliche aDSO mit den zusätzlichen Changelog – Informationen. Achtung, nun erhalten Sie Kennzahlen und Kommentare mehrfach im Bericht, da wir eine aktuelle Berichtsansicht mit der historischen Ansicht verbinden. Aber das hilft, das Changelog mit aktuellen Werten zu überprüfen. 

Eine Abfrage über diesem Composite Provider zeigt die Historie der Änderungen an. Die Summe aller Änderungen für die Kennzahlen ist identisch mit dem aktuellen Wert im Infoprovider (letzte Zeile). 

Diese Abfrage kann nun an Ihre Änderungen angepasst werden, z.B. Recordmode X ausschließen, wenn Sie nur den neuen Kommentar sehen und zu viele Zeilen vermeiden wollen. 

Nutzen von ABAP CDS Views

Falls Sie nicht die Möglichkeit haben, HANA-Calculation-Views im System zu verwenden, können Sie das gleiche Ergebnis auch mit ABAP CDS-Views erreichen! 

Allgemeine Informationen zur Verwendung von CDS-Views im BW finden Sie in den folgenden SAP-Hinweisen und im Blog: 

https://me.sap.com/notes/2198480 

https://me.sap.com/notes/2673267 

https://community.sap.com/t5/technology-blogs-by-members/sap-s-4hana-amp-sap-bw-data-integration-via-odp-abap-cds-views/ba-p/13224473 

Wir werden dieselben Tabellen verwenden (Änderungsprotokolltabelle /bic/azum_ad023 mit Anforderungsinformationen RSPMREQUEST) und sie in der ABAP CDS-Ansicht zusammenführen. Es wird derselbe Filter angewendet. 

Stellen Sie sicher, dass Sie die folgenden Annotationen hinzufügen, damit der Open-ODS-View die Daten verwenden kann: 

@Analytics.dataCategory: #CUBE 

@Analytics.dataExtraction.enabled : true
 

Um eine CDS-View zu verwenden, müssen wir zunächst eine Datenquelle auf der Grundlage der CDS-Ansicht und eine Open ODS-Ansicht auf der Grundlage dieser DS erstellen, die in einem Composite Provider verwendet werden kann: 

Datenquelle: 

Mit dem open ODS View 

Nun verwenden wir den ODS-View zusammen mit unserer ursprünglichen aDSO in einem Composite Provider und mappen wieder alle Felder. 

Der Datenfluss hat nun einige weitere Schichten mehr als die Lösung mit dem Calculation View, aber wir brauchen keinen HANA User! 

 

Am Ende können wir eine Abfrage mit dem identischen Ergebnis wie in der Lösung mit dem HANA Composite Provider erstellen! 

Fazit

Wir haben Ihnen zwei Möglichkeiten gezeigt, wie Sie den Verlauf von Kommentaren in einer Abfrage verfügbar machen können. Beide sind recht einfach und liefern die gewünschten Informationen. Welchen Weg Sie nutzen möchten, bleibt Ihnen überlassen. 

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.