Kontakt

Ansicht
Dokumentation

ABENDATABASE_ACCESS_RECOMM - DATABASE ACCESS RECOMM

ABENDATABASE_ACCESS_RECOMM - DATABASE ACCESS RECOMM

Vendor Master (General Section)   Vendor Master (General Section)  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Regeln für den Zugriff auf ABAP-verwaltete Datenbankobjekte

Die vorhergehenden Abschnitte

Darauf beruhen die folgenden Regeln für den Zugriff auf ABAP-verwaltete Datenbankobjekte.

Grundregel

Die von ABAP verwalteten Datenbankobjekte sind ausschließlich für die Verwendung durch ABAP-Programme des AS ABAP und den Zugriff über dessen Datenbankschnittstelle vorgesehen.

Die Ausprägung der von ABAP verwalteten Datenbankobjekte liegt in der alleinigen Verantwortung des AS ABAP. Die konkrete Implementierung kann sich bei einem Release-Wechsel inkompatibel ändern. Bei einem Zugriff über nicht von ABAP verwaltetem Native SQL gelten zum einen die gleichen Einschränkungen wie bei einem Zugriff über von ABAP verwaltetem Native SQL (siehe unten) und zum anderen gibt es keine Zwischenschicht in Form der Native-SQL-Schnittstelle, die solche Änderungen abfangen könnte. Beispielsweise sind nicht einmal die Namen der von ABAP-verwalteten Datenbankobjekten wie CDS-verwaltete DDIC-Views, AMDP-Prozeduren oder AMDP-Funktionen garantiert. Zugriffe, wie z.B. die Verwendung einer CDS-verwaltete DDIC-View als Datenquelle einer SAP-HANA-View oder der Aufruf einer AMDP-Funktion in einer nicht von ABAP verwalteten Datenbankprozedur können jederzeit ungültig werden. Weiterhin sind die ABAP-spezifischen Sitzungsvariablen der SAP-HANA-Datenbank, von denen die Funktionalität von ABAP verwalteten Datenbankobjekten abhängen kann, nicht gesetzt und ein Verwendungsnachweis ist nicht mit ABAP-Mitteln möglich. Wenn die Datenalterung berücksichtigt werden soll, muss dies selbst programmiert werden.

Hinweis

In Ausnahmefällen können Anwendungen die Grundregel umgehen, wenn sie akzeptieren, dass sie von der Infrastruktur des AS ABAP keine technische Unterstützung erhalten, wenn es durch den Zugriff auf ABAP-verwaltete Datenbankobjekte von außerhalb des AS ABAP zu Fehlersituationen kommt. Eine Anwendung muss selbst solchen Fehlern vorbeugen und gegebenenfalls für deren Behebung sorgen:

  • Von SAP ausgelieferte Anwendungen müssen so abgesichert sein, dass es zu keinen Fehlern kommen kann. Gegebenenfalls müssen die Voraussetzungen für den Zugriff auf ABAP-verwaltete Datenbankobjekte von außerhalb des AS ABAP in SAP-Hinweisen beschrieben werden.
  • Partner und Kunden sollten nur dann von außerhalb des AS ABAP auf ABAP-verwaltete Datenbankobjekte zugreifen, wenn dies von SAP erlaubt ist, wenn die zugehörigen Voraussetzungen bekannt sind und wenn diese eingehalten werden können.

Regeln zur erlaubten Verwendung

Innerhalb der Datenbank darf der Zugriff auf ABAP-verwaltete Datenbankobjekte nur aus anderen ABAP-verwalteten Datenbankobjekte erfolgen. Der Zugriff auf ABAP-verwaltete Datenbankobjekte aus ABAP-Programmen sollte primär über erfolgen. Nur wenn nicht ausreicht sollte AMDP verwendet werden. Und nur wenn AMDP nicht ausreicht darf ABAP-verwaltetes Native SQL verwendet werden. Ein Zugriff durch nicht von ABAP verwaltetes Native SQL ist wegen der Grundregel nicht vorgesehen.

ist der primär vorgesehene Zugriff auf ABAP-verwaltete Datenbankobjekte. Nur unterstützt alle funktionalen und semantischen Eigenschaften ABAP-verwalteter Datenbankobjekte. Interne Änderungen an ABAP-verwalteten Datenbankobjekten werden von der -Schnittstelle behandelt und sind für das ABAP-Programm transparent.

AMDP

AMDP ist im Vergleich zu Native SQL eine höherwertige Verschalung von datenbankspezifischem SQL. Wenn der Sprachumfang von nicht ausreicht soll zuerst versucht werden, AMDP für den Zugriff auf ABAP-verwaltete Datenbankobjekte zu verwenden. Dies betrifft im Wesentlichen den Aufruf von Datenbankprozeduren, der in nicht unterstützt wird, aber auch die Verschalung von SQL-Elementen, die in noch nicht vorhanden sind und für die es dort keine adäquate Alternative gibt, wie z.B. die Verwendung noch nicht unterstützter eingebauter Funktionen.

Prinzipiell soll AMDP nur so verwendet werden, wie vorgesehen:

  • Möglichst kein Aufruf aus Native SQL

Bei der Verwendung von AMDP sind zwar einige Restriktion von Native SQL aufgehoben oder entschärft, es gibt aber bei weitem nicht die gleiche Unterstützung der funktionalen und semantischen Eigenschaften von ABAP-verwalteter Datenbankobjekten wie in .

Die im folgenden aufgeführten Regeln für Native SQL gelten größtenteils genauso auch für die Implementierung von AMDP-Methoden, insbesondere was schreibende DML-Zugriffe angeht.

Hinweis

Es hat keinen Sinn, SQL-Anweisungen in AMDP-Methoden auszulagern, die auch in formuliert werden können. Siehe ausführbares Beispiel.

von ABAP verwaltetes Native SQL

ABAP-verwaltetes Native SQL (ADBC, EXEC SQL) unterliegt fast den gleichen Einschränkungen wie nicht von ABAP-verwaltetes Native SQL. Die im ABAP Dictionary definierte Feldreihenfolge ist genauso wenig bekannt wie die semantischen Eigenschaften. Ein Mapping zwischen ABAP-Typen und Datenbanktypen ist nur für bestimmte Typen möglich. Es gibt keine implizite Mandantenbehandlung und der Tabellenpuffer wird immer umgangen. Von CDS-Entitäten müssen die aktuellen Ausprägungen auf der Datenbank bekannt sein, wie etwa die Ausprägung eines CDS-Views mit Eingabeparametern als SQL-View oder als Datenbankfunktion. Dabei sind inkompatible Änderungen möglich. Die CDS-Zugriffskontrolle wird umgangen. Durch den Zugriff über die Native-SQL-Schnittstelle bestehen zwar einige Vorteile gegenüber nicht von ABAP-verwaltetem Native SQL, wie z.B. das Vorhandensein von Umfeldinformationen in Sitzungsvariablen (nur auf HANA und nicht beeinflussbar) oder die Berücksichtigung der Datenalterung, eine Verwendung sollte aber nur erfolgen, wenn die Mittel von AMDP nicht ausreichen. In diesem Fall sollten folgende Regeln eingehalten werden:

  • Es sollten ausschließlich lesende DML -Anweisungen verwendet werden.
  • Die lesenden Anweisungen sollten von keinen anderen Eigenschaften der ABAP-verwalteten Datenbankobjekte außer deren Namen und dem Namen von Komponenten abhängen. Dabei ist zu beachten, dass beim Zugriff auf Datenbankobjekte von CDS-Entitäten selbst der Name nicht garantiert ist.

  • Ein Mapping zwischen ABAP-Typen und Datenbanktypen ist nur für bestimmte Typen möglich. In allen anderen Fällen kann es zu unerwarteten Ergebnissen oder Fehlern kommen. Dies betrifft insbesondere das plattformabhängige Abschneiden oder Auffüllen von Werten.

  • Die Feldreihenfolge ist nicht definiert und nicht stabil. Es sollten z.B. keine Zugriffe mit SELECT * erfolgen.

  • Es ist damit zu rechnen, dass ein ABAP-verwaltetes Datenbankobjekt durch eine andere Art von Datenbankobjekt ersetzt wird, z.B. eine Datenbanktabelle durch eine View.

  • Wenn notwendig, müssen die ABAP-spezifischen Eigenschaften, die in automatisch berücksichtigt werden, bei der Verwendung von Native SQL explizit programmiert werden, wie z.B. Mandantenbehandlung, spezielle Typkonvertierungen, usw.

  • Schreibende DML-Anweisungen wie INSERT, UPDATE oder DELETE sind problematisch und sollten vermieden werden. Zusätzlich zu den Punkten bei Lesezugriffen ist zu beachten:
  • Es fehlen ABAP-spezifische Typkonvertierungen und die Vermeidung von Null-Werten, was zu Datenschiefständen und Problemen bei folgenden Zugriffen in ABAP-Programmen führen kann.

  • In bestimmten Phasen der Systemauslieferung oder eines Upgrades können ABAP-verwaltete Datenbankobjekte, die einen Schreibzugriff erlauben, temporär durch Datenbankobjekte ersetzt werden, die keinen Schreibzugriff erlauben, wodurch Schreibzugriffe auf solche Objekte zu Fehlern führen würden.

  • Vollständig zu vermeiden sind DDL-Zugriffe auf ABAP-verwaltete Datenbankobjekte. DDL ist zwar technisch nicht ausgeschlossen, Änderungen an der Definition von ABAP-verwalteten Datenbankobjekten ist aber alleinige Sache der entsprechenden Frameworks wie ABAP Dictionary oder AMDP. Die direkte Verwendung von DDL für ABAP-verwaltete Datenbankobjekte kann im schlimmsten Fall einen AS ABAP unbrauchbar machen.

Hinweise

  • Wie bei der Verwendung von nicht von ABAP verwaltetem Native SQL ist eine Anwendung, die von ABAP verwaltetes Native SQL verwendet, für alles selbst verantwortlich, was nicht von der Native-SQL-Schittstelle unterstützt wird. Ein Beispiel wäre ein Zugriff auf eine CDS-verwaltete DDIC-View, in deren DDL-Quelltext die CDS-Sitzungsvariable client verwendet wird. Diese wird im Datenbankobjekt durch die HANA-Sitzungsvariable CDS_CLIENT repräsentiert, die nicht von der Native-SQL-Schnittstelle gesetzt wird. Die Anwendung muss selbst für den gewünschten Wert sorgen oder darf einen solchen Zugriff nicht durchführen.
  • Zukünftige inkompatible Änderungen an von ABAP-verwalteten Datenbankobjekten können eventuell von der Native-SQL-Schnittstelle behandelt werden, das wird aber nicht garantiert.

Gemischte Zugriffe

Die verschiedenen Zugriffe auf ABAP-verwaltete Datenbankobjekte können technisch gesehen gemischt auftreten. D.h. für eine oder mehrere Anwendungen ist es möglich über , AMDP oder Native SQL auf ein und dieselben Datenbankobjekte zuzugreifen. Hierbei besteht die Gefahr, dass bei einer Vermischung von Datenbankzugriffen über mit AMDP und Native SQL dadurch Fehler entstehen, dass auch für letztere ABAP-spezifisches Verhalten erwartet wird, was aber nur bei der Verwendung von gegeben ist. Beispiele:

  • unterschiedliche Konvertierungsregeln beim Mapping nicht passender Typen
  • unterschiedliche Behandlung von Null-Werten
  • unterschiedlich gesetzte Umfeldinformationen

Aus diesem Grund muss in der Regel immer darauf geachtet werden, bei Zugriffen mit AMDP und Native SQL auf ABAP-verwaltete Datenobjekte, auf die auch über zugegriffen wird, die Semantik der-Anweisungen zu erhalten.

  • Beim Lesen von Daten mit AMDP oder Native SQL müssen die Typkonvertierungen bei unpassenden Typen berücksichtigt werden und gegebenenfalls müssen die Werte ABAP-spezifisch nachbearbeitet werden.
  • Beim Schreiben dürfen Daten mit AMDP und Native SQL nicht so verändert werden, dass sich nachfolgende -Anweisungen anders verhalten als nach einer Änderung über .

Bei gemischten Zugriffen sollten die Möglichkeiten, die sich in der Implementierung einer AMDP-Methode oder bei der Verwendung von Native SQL bieten also nur soweit ausgeschöpft werden, dass sie die Konsistenz eines ABAP-verwalteten Datenmodells nicht gefährden.






General Data in Customer Master   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 17205 Date: 20240523 Time: 181723     sap01-206 ( 248 ms )