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.

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

➔

Verteilt auf zwei Pakete ➔ Falsches Ergebnis

Paket 1

Paket 2

➔

Paket 1

Paket 2

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.

Betrifft nicht nur SAPUI5, sondern zeigt, dass man immer immer immer im Backend Berechtigungen prüfen muss und niemals Geheimnisse an das Frontend geben darf.

https://www.linkedin.com/posts/lilith-wittmann_die-sicherheitslücken-die-ich-in-der-software-activity-7307724681183174656-y-Yd?utm_source=share&utm_medium=member_desktop&rcm=ACoAABGPzNgB3s8eekBT15-R-olJyCCB6At8KGI

Hier können alle Fragen gestellt werden. Auch für listings, Screenshots etc.

Chat mit einer gut unterrichteten Quelle zu dem Thema:

Du hattest die Tage mal wegen Debugging von Reduce Statements gefragt.
Ist auch in ADT möglich mit dem Step Size Feature. Geht aktuell aber nur in der Cloud.

Und warum geht das nicht on Premise?

Recht einfach. Wir mussten das für ADT erstmal enable nim Backend. Und das ist erst vor kurzem passiert. Feature ist noch recht neu in ADT.
Daher kommt es erst mit dem nächsten on-premise Release in 2025. Ich denke einen Downport werden wir nicht angehen. Ich kann da aber noch mal anfragen ob das machbar wäre.

Das Ziel des Forums ist, eine möglichst effektive Unterstützung bei Euren Entwicklungstätigkeiten zu erreichen. Nach der Schulung habt Ihr Zugang und könnt nach Belieben Fragen stellen. Dafür gelten ein paar einfache Regeln:

• seid freundlich und respektvoll zueinander
• Niemand wird diskriminiert oder beleidigt
• Werbung für Produkte oder Dienstleistungen ist nicht erlaubt
• Abwerben von Mitarbeitern ist ebenfalls nicht erlaubt
• Nicht nur die Trainer dürfen antworten. Wir freuen uns über jeden Beitrag und jede Erfahrung.
• Alle Fragen und Antworten sind für offen sichtbar. Bitte nur solche Inhalte teilen, für die das in Ordnung ist. Insbesondere dürfen keine Geschäftsgeheimnisse und keine personenbezogene Daten geteilt werden.

Nachbearbeitung von Themen

Die Trainer/Moderatoren können Eure Beiträge und Fragen editieren und ggf. auch einzelne Antworten löschen. Das geschieht zur besseren Lesbarkeit bzw. zum Korrigieren inhaltlicher Fehlern. Nach dem eine Diskussion fertig ist, sollte es möglichst einfach sein, die richtige Lösung für ein Problem zu sehen.

Alle Inhalte sind für jeden öffentlich einsehbar.

Mit dem Konstruktoroperator CONV können wir beim Aufruf einer Methode bequem den Datentypen eines Parameters anpassen. Allerdings hebeln wir damit die Typprüfung des ABAP aus. Der EXACT-Konstruktoroperator ist aber oft die bessere Wahl, weil er zusätzlich prüft, dass keine Daten verloren gehen.

Die Herausforderung

Ein typisches Problem beim Methodenaufruf sind unpassende Datentypen. Im Gegensatz zu Funktionsbausteinen wird der Datentyp zur Designzeit geprüft und die Klasse lässt sich nicht aktivieren, wenn die Datentypen von Methodenaufrufen nicht stimmen.

Beispiel

Methodendefinition

METHODS my_method IMPORTING text TYPE char8.

Aufruf mit DATS

Ergibt einen Fehler, wenn wir es mit einem Datum vom Datentyp DATS aufrufen, weil der Datentyp nicht genau passt:

"SYST-DATUM" is not type-compatible with formal parameter "TEXT"

Der zweite Fehler ist hier nicht relevant. Der kommt daher, dass wir auf einem Cloudsystem sind und SYST-DATUM dort überhaupt nicht mehr verwendet werden darf.

Die klassische Lösung mit Hilfsvariable

Wenn der Datentyp nicht passt, dann eben eine passende Variable anlegen, mit den Daten füllen und diese an die Methode übergeben. Wir nutzen aus, das im ABAP bei einer Zuweisung Äpfel zu Birnen gemacht werden können. Und solange die Inhalte kompatibel sind, wird das gut funktionieren.

  METHOD demo_conv.
    data lv_text type char8. 
    lv_text = sy-datum. 
    my_method( text =  lv_text ).
  ENDMETHOD.

Haben wir schon 1000 mal so gemacht. Ist aber wenig elegant.

Die moderne Lösung mit CONV - Eleganter aber genauso ungenau

Mit dem Konstruktoroperator CONV können wir erreichen, dass der Datentyp passend gemacht wird. Durch das # wird automatisch der passende Zieldatentyp aus der Methodensignatur verwendet.

  METHOD demo_conv.
    my_method( text =  CONV #( lv_text ) ).
  ENDMETHOD.

Das Verhalten entspricht genau dem mit Hilfsvariable.

Das Problem mit dem Datenverlust

Es kann zu Datenverlust kommen, wenn der Datentyp des Parameters nicht alle Daten aufnehmen kann.

Wenn zum Beispiel manche Klassen den Datentyp für das Material noch mit CHAR(18) definiert haben und an anderen Stellen mit CHAR(40) gearbeitet wird, dann passen die Datentypen nicht. Das kann man mit einer passenden Hilfsvariable anpassen. Wenn aber irgendwann ein Material mit mehr als 18 Zeichen im System ist, dann wird einfach abgeschnitten. Die Probleme können dann an ganz anderer Stelle auftreten als dort, wo die Ursache dafür war.

<div class="warning">Was passiert, wenn bei der Zuweisung ein Datenverlust auftritt. </div>

Die Variante mit EXACT - Elegant und sicher

Der Operator EXACT kann ebenfalls den Datentypen passend machen. Dabei stellt er sicher, dass der Zieldatentyp die Daten auch vollständig aufnehmen kann. Wenn das nicht der Fall ist, reagiert die ABAP Laufzeit mit einer Exception vom Typ CX_SY_MOVE_CAST_ERROR.

Wenn wir sicher sind, dass der Datentyp passt, dann ist EXACT kein Mehraufwand. Wenn wir uns aber geirrt haben, werden Daten nicht einfach abgeschnitten und dann mit den falschen Daten weitergearbeitet. Statt dessen bekommen wir einen Dump und wissen sofort, welches Problem wir haben.

  METHOD demo_conv.
    my_method( text =  EXACT #( lv_text ) ).
  ENDMETHOD.

Alternativ zum Dump kann man natürlich auch die Exception abfangen. Aber das wird man nur dann machen, wenn man mit dieser Situation rechnet.

Fazit

Modernes ABAP erlaubt uns, mit dem Konzept der Ausdrücke unnötige Hilfsvariablen zu vermeiden. Der CONV-Operator ist dafür sehr praktisch. Der EXACT-Operator kann sogar noch mehr: Er verhindert versehentlichen Datenverlust.