Semantische Gruppierung mit AMDP unter BW on HANA 7.5

[Gast]

Hallo Jörg,

ich meine mich zu erinnern, dass das Thema im Kurs besprochen wurde: Wir arbeiten noch auf einem älteren BW on HANA 7.50-System und benötigen für eine bestehende AMDP semantische Pakete. Soweit ich es verstehe, wird die Standard-BW-Funktion in diesem Release aber nicht mit AMDPs unterstützt.

Gibt es dafür bekannte Workarounds oder bleibt nur die Möglichkeit, eine eigene Lösung mit einer zusätzlichen Schicht zu entwickeln?

[Jörg]

Hallo,

vielen Dank für Deine Frage. Hatte ich tatsächlich kurz angesprochen. Aber auf unserer Website habe ich auch mal einen kurzen Artikel dazu geschrieben: https://www.brandeis.de/blog/2024/semantic-grouping-in-bw75

Hier der Artikel:

---

Leider funktioniert im BW 7.50 bei der HANA-Ausführung die semantische Gruppierung nicht, um damit alle Datensätze mit gleichen Teilschlüssel im gleichen Paket zu haben. Das ist aber manchmal notwendig, wenn in unseren Routinen Berechnungen durchgeführt werden. Im BW/4HANA besteht dieses Problem nicht mehr, siehe SAP Dokumentation. In diesem Artikel will ich ein paar Lösungsansätze aufzeigen.

Beispiel für semantische Gruppierung

Es soll berechnet werden, wie groß der prozentuale Anteil einer Position an einem Beleg ist. Das lässt sich nur berechnen, wenn alle Daten eines Belegs im gleichen Paket sind.

---

Alles in einem Paket ➔ Richtiges Ergebnis

Beleg	Position	Betrag
4711	10	100
4711	20	300
4711	30	500
4711	40	100

➔

Beleg	Position	Betrag	Anteil
4711	10	100	10%
4711	20	300	30%
4711	30	500	50%
4711	40	100	10%

---

Verteilt auf zwei Pakete ➔ Falsches Ergebnis

Paket 1

Beleg	Position	Betrag
4711	10	100
4711	20	300

Paket 2

Beleg	Position	Betrag
4711	30	500
4711	40	100

➔

Paket 1

Beleg	Position	Betrag	Anteil
4711	10	100	25%
4711	20	300	75%

Paket 2

Beleg	Position	Betrag	Anteil
4711	30	500	83,33%
4711	40	100	16,66%

Lösungsansätze

Es gibt mehrere Möglichkeiten, um die Semantische Gruppierung bei HANA Ausführung in BW 7.50 zu ersetzen. Was der beste Weg ist, hängt natürlich wie immer von den Gegebenheiten ab.

Die Lösung im SQLScript

Dieser Ansatz löst das Problem im AMDP. Wir lesen zu den Daten in der INTAB alle Datensätze aus der aktiven Tabelle des Quell-DSO, entsprechend der semantischen Gruppierung. Damit erstellen wir eine neue Tabellenvariable INTAB_NEW, die in sich konsistent ist. Wenn jetzt eine semantische Gruppe auf zwei Pakete verteilt ist, dann werden alle Datensätze der Gruppe doppelt verarbeitet.

Wir gehen aber davon aus, dass es sich beim Ziel um ein Standard-DSO handelt. Das bedeutet, das wenn ein Datensatz mit gleichem Schlüssel in zwei oder mehreren Paketen ist, dann wird er sich beim Aktivieren mit dem jeweils exakt gleichen Werten überschrieben.

Hier der Quellcode, mit dem wir die INTAB_NEW aufbauen:

METHOD GLOBAL_EXPERT BY DATABASE PROCEDURE FOR HDB LANGUAGE SQLSCRIPT OPTIONS READ-ONLY
using /BIC/AZBR_E2_S2.

    intab_new = select * 
                  from "/BIC/AZBR_E2_S2"
                 where ( budat, account ) in ( select distinct budat, 
                                                               account
                                                 from :intab ); 

Nachteil der Semantischen Gruppierung in SQLScript

Mit der gezeigten Logik erreichen wir, dass immer alle Datensätze zusammen bleiben. Aber damit werden auch Daten doppelt verarbeitet. Das stört im Ergebnis inhaltlich nicht, da die Logik in allen Paketen stets zum gleichen Ergebnis kommt. Aber es werden mehr Datensätze erzeugt, als tatsächlich benötigt werden. Das kann die Laufzeit etwas beeinflussen.

In meinen Tests waren das bei dem Beispiel für ca. 3.1 Mio Datensätzen und 4 Paketen eine Überlappung unter 5%. Das ist im Vergleich mit den anderen Optionen auf jeden Fall akzeptabel. Ich weiss aber nicht, ob man den Wert verallgemeinern kann. Wie hoch die Redundanz tatsächlich ist, merkt man bei der Aktivierung an der Differenz der Anzahl der Datensätze zwischen Eingangstabelle und aktiver Tabelle. Vermutlich hilft eine feine Granularität der Gruppen dabei, die Redundanz gering zu halten.

Ein großes Paket

Wenn man die Paketgröße so wählt, dass niemals zwei Pakete gebildet werden, dann hat man das Problem nicht. Allerdings kann auch eine HANA Datenbank nicht mit unendlich vielen Daten gleichzeitig umgehen. Darum ist das nur eine Option, wenn man absehen kann, dass das Volumen überschaubar bleibt. Ich gehe davon aus, dass wenige Millionen Datensätze akzeptabel sind.

Und falls die Datenmenge unvorhergesehen zunimmt? Der Parameter für die Paketgröße muss so gesetzt werden, dass dieser wirklich niemals überschritten wird. Sonst bekommen wir falsche Daten. Wenn es hingegen Abbrüche gibt, dann ist das zwar ärgerlich, aber zur Not bekommt man die Daten dann mit dem nächsten Lösungsansatz ins System.

Mehrere DTPs mit disjunkter Datenmenge

Wenn man zu viele Daten für ein Paket hat, gerade wenn man mit dem vorherigen Ansatz Probleme bekommen hat, dann ist es eine Option, dass man manuell partitioniert. Damit meine ich, dass man mehrere DTPs anlegt, die anhand der Filterkriterien die Datenmenge aufteilen. Das ist nicht schön, da es die Wartbarkeit des Systems reduziert. Ist aber immer möglich.

Upgrade auf BW/4HANA

Nur der Vollständigkeit halber. Wer viel semantische Gruppierung nutzt, für den könnte das ein Argument für BW/4HANA sein.

Auf ABAP Ausführung umstellen

Die letzte Option ist die Umstellung auf ABAP. Das ist gerade für kleinen Datenmengen bzw. wenn die Ausführungszeit kein Problem darstellt, eine valide Option. Nicht schön, geht aber garantiert.

Fazit

Es ist schade, dass die semantische Gruppierung für die HANA Ausführung erst mit BW/4HANA sauber funktioniert. Aber es gibt einige praktikable Workarounds. Im SQLScript ist das wenig kompliziert.

Ich hoffe, der Artikel ist nützlich. Über Anmerkungen und Erfahrungen damit freue ich mich natürlich sehr.