Forum wide moderators
Hallo S,
wenn es bei einem Consumption View nur an der Freigabe scheitert, dann ist das Wrappen des bestehenden CDS Views wahrscheinlich die beste Option, solange alles 1:1 passt. Wenn noch Anpassungen notwendig sind, würde ich eine Kopie anlegen.
Viele Grüße,
Jörg
Hallo S.
Grundsätzlich sollte mit den CDS View Entities die gleichen Dinge machen können wie mit den DDIC based CDS Views. Der Hauptunterschied ist, dass man bei den CDS View Entities keine zwei unterschiedlichen Namen braucht. In den analytischen Anwendungen (Embedded Analytics & CDS Extraktoren) verwendet man für die DDIC based CDS Views den SQL-View Namen. Bei den CDS View Entities ist der SQL-View Name und der CDS Entity Name identisch.
Hallo S. ,
vielen Dank für Deine Frage. Das wird höchstwahrscheinlich an Berechtigungen liegen. Denn den CDS View Entities sollte das total egal sein, ob sie Lokal ($TMP) oder in einem Pakt liegen.
Also am besten mal in der SU53 nachschauen, ob da eine Berechtigung fehlt. Vielleicht bei S_DEVELOP?`
Viele Grüße,
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.
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.
| 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% |
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% |
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.
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 );
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.
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.
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.
Nur der Vollständigkeit halber. Wer viel semantische Gruppierung nutzt, für den könnte das ein Argument für BW/4HANA sein.
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.
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.
