Ansicht
Dokumentation

ABENCL_OSQL_REPLACE - CL OSQL REPLACE

General Material Data   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

CL_OSQL_REPLACE, Ersetzungsdienst

Die Systemklasse CL_OSQL_REPLACE realisiert einen Ersetzungsdienst, mit dem während der Ausführung von Modultests in ABAP Unit der Zugriff auf Datenquellen in -Anweisungen umgelenkt werden kann. Die Systemklasse CL_OSQL_REPLACE kann nur in Testklassen von ABAP Unit verwendet werden.

Ersetzungsregeln definieren

Für die Definition der Ersetzungsregeln dient im Wesentlichen die statische Methode ACTIVATE_REPLACEMENT der Systemklasse CL_OSQL_REPLACE.

• Dem Parameter REPLACEMENT_TABLE wird eine dreispaltige interne Tabelle übergeben:

• Die erste Spalte SOURCE enthält den Namen einer im ABAP Dictionary definierten Datenquelle, d.h. eine DDIC-Datenbanktabelle, eine DDIC-View oder eine nicht-abstrakte CDS-Entität.

• Die zweite Spalte TARGET enthält den Namen eines Datenbankobjekts der aktuellen Datenbank, auf das ein -Zugriff auf die in der ersten Spalte genannten Datenquelle umgelenkt werden soll.

• Die dritte Spalte SCHEMA enthält den Namen eines Datenbankschemas, in dem nach dem Datenbankobjekt aus der zweiten Spalte gesucht wird. Ist die dritte Spalte leer, wird das ABAP-Datenbankschema verwendet.

• Dem Parameter FLG_DML kann eine Kennung übergeben werden, die festlegt, ob die Umlenkung auch für schreibende -Anweisungen gilt:

• Wird dem Parameter FLG_DML der Wert von abap_false übergeben, gilt die Umlenkung nur für Queries, d.h. für die Hauptqueries von lesende Zugriffen und für die Subqueries aller Zugriffe.

• Wird dem Parameter FLG_DML der Wert von abap_true übergeben, gilt die Umlenkung auch für die zu ändernden DDIC-Datenbanktabellen von schreibenden Zugriffen.

• Dem Parameter FLG_SURVIVE_SUBMIT kann eine Kennung übergeben werden, die festlegt, ob die Umlenkung auch für aufgerufene Programme gilt:

• Wird dem Parameter FLG_SURVIVE_SUBMIT der Wert von abap_false übergeben, gilt die Umlenkung nur für das aktuelle Programm.

• Wird dem Parameter FLG_SURVIVE_SUBMIT der Wert von abap_true übergeben, gilt die Umlenkung auch für mit SUBMIT, CALL TRANSACTION und CALL DIALOG aufgerufene Programme.

Die Umlenkung kann auf beliebige Datenbankobjekte erfolgen, also insbesondere auf die Ausprägungen von im ABAP Dictionary definierten DDIC-Datenbanktabellen oder DDIC-Views. Die Datenbankobjekte, auf die umgelenkt wird, müssen den selben Aufbau wie das umgelenkte Objekt haben, ansonsten ist das Ergebnis datenbankabhängig und undefiniert und es kann zu Ausnahmen kommen.

Eine erfolgreiche Umlenkung gilt während der gesamten Ausführung eines Modultests bis die interne Sitzung beendet wird oder bis eine erneute Umlenkung erfolgt. Die Übergabe einer leeren internen Tabelle an die Methode ACTIVATE_REPLACEMENT beendet eine Umlenkung explizit.

Hinweise

• Technisch gesehen werden bei einer Umlenkung die Namen der Datenbankobjekte in den plattformabhängigen SQL-Anweisungen ersetzt, welche die Datenbankschnittstelle aus den -Anweisungen erzeugt und an das Datenbanksystem übergibt.

• Eine Umlenkung der von verwendeten Datenquellen dient in der Regel dazu, während eines Modultests mit Testtabellen und Testdaten zu arbeiten, statt mit den tatsächlichen Tabellen und deren Daten. Dies ermöglicht insbesondere auch den Test von Systemprogrammen, die auf Systemtabellen zugreifen.

• Bei einer Umlenkung in aufgerufenen Programmen mit dem Parameter FLG_SURVIVE_SUBMIT ist ein Programmaufruf mit der Anweisung SUBMIT ohne den Zusatz AND RETURN nicht sinnvoll.

Weitere Methoden

Neben der Methode ACTIVATE_REPLACEMENT hat CL_OSQL_REPLACE im Wesentlichen folgende Methoden:

• Mit den Methoden IS_REPLACEMENT_ACTIVE und IS_REPLACEMENT_ACTIVE_DML kann überprüft werden, ob eine Umlenkung aktiv ist und ob sie auch für schreibende Zugriffe gilt.

• Mit den Methoden SET_ACTIVE_FOR_DML und TOGGLE_ACTIVE_FOR_DML kann für eine bestehende Umlenkung die Einstellung für schreibende Zugriffe gesetzt bzw. verändert werden.

Einschränkungen und Besonderheiten

Datenquellen von lesenden Zugriffen

Für die Datenquellen von lesenden Zugriffen gilt:

• Damit eine Datenquelle eines lesenden Zugriffs auf ein im ABAP Dictionary definiertes Objekt umgelenkt werden kann, muss letzteres auch unter seinem im ABAP Dictionary definierten Namen auf der Datenbank ausgeprägt sein.

• Um einen Lesezugriff von einer DDIC-Projektions-View auf eine andere Datenquelle umzulenken, kann eine Umlenkung der zugrundeliegenden DDIC-Datenbanktabelle durchgeführt werden.

• Eine Umlenkung ist nicht möglich auf:

• Projektions-Views

• CDS-Entitäten

• Wenn die Datenquelle einer Subquery in der WHERE-Bedingung einer schreibenden Anweisung auf das Ziel des schreibenden Zugriffs umgelenkt wird, ist das Verhalten undefiniert und es kann zu unabsehbaren Fehlen kommen.

• Für CDS-Entitäten ist zu beachten:

• Wenn ein Lesezugriff auf eine CDS-View oder eine CDS-Tabellenfunktion umgelenkt wird, auf die im Rahmen der CDS-Zugriffskontrolle eine oder mehrere CDS-Rollen definiert sind, werden die zugehörigen Zugriffsbedingungen unabhängig vom Ziel der Umlenkung ausgewertet. CDS-Rollen, die für das Ziel einer Umleitung definiert sind, werden nicht beachtet.

• Für CDS-Tabellenfunktionen ist zu beachten:

• Eine CDS-Tabellenfunktion kann nur auf eine Tabellenfunktion umgelenkt werden. Diese muss aber keine AMDP-Funktion sein.

• Wenn ein direkter oder indirekter Lesezugriff auf eine CDS-Tabellenfunktion auf eine andere Datenquelle umgelenkt wird, wird dennoch der statische Konstruktor der AMDP-Klasse ausgeführt, in welcher die zugehörige AMDP-Tabellenfunktion implementiert ist.

• Wenn ein Lesezugriff auf eine beliebige Datenquelle auf eine AMDP-Tabellenfunktion umgelenkt wird, die im aktuellen AS ABAP bekannt ist, legt das AMDP-Framework falls notwendig die zugehörige Ausprägung auf der Datenbank an und es wird der statische Konstruktor der zugehörigen AMDP-Klasse ausgeführt.

• Wenn Quelle oder Ziel einer Umlenkung eine im ABAP Dictionary definierte DDIC-Datenbanktabelle des ABAP-Datenbankschemas ist, für die ein Vertreterobjekt definiert ist, wird erst die Umlenkung ausgewertet und dann das Vertreterobjekt:

• Falls eine Datenquelle eines Lesezugriffs auf eine DDIC-Datenbanktabelle umgelenkt wird, für die ein Vertreterobjekt definiert ist, wird auf das Vertreterobjekt umgelenkt.

• Falls eine DDIC-Datenbanktabelle umgelenkt wird, für die ein Vertreterobjekt definiert ist, wirkt die Umlenkung. Das Vertreterobjekt wird nicht berücksichtigt.

• Falls für eine DDIC-Datenbanktabelle ein Vertreterobjekt definiert ist und das Vertreterobjekt umgelenkt wird, hat die Umlenkung keine Wirkung. Es wird auf das Vertreterobjekt zugegriffen.

• Eine Umlenkung umgeht immer die Tabellenpufferung.

Ziele von schreibenden Zugriffen

Für das Ziel eines schreibenden Zugriffs gelten falls anwendbar die gleichen Einschränkungen wie für die Datenquellen lesender Zugriffe. Zusätzlich sind Ziele von Schreibzugriffen nicht auf folgende im ABAP Dictionary definierte Objekte umlenkbar:

• DDIC-Views

• DDIC-Datenbanktabellen mit eingeschalteter Tabellenpufferung

• DDIC-Datenbanktabellen mit eingeschalteter Protokollierung

Schreibzugriffe auf eine Projektions-View können nicht umgelenkt werden, wenn die zu ändernden Zeilen über einen Arbeitsbereich oder eine interne Tabelle bestimmt werden. Eine Umlenkung der Zugriffe auf die DDIC-Datenbanktabelle eines DDIC-Projektions-Views ist also nur möglich, wenn es keine schreibenden Zugriffe auf die View gibt, außer mit den Anweisungen DELETE mit WHERE-Bedingung oder UPDATE mit dem Zusatz SET. Andernfalls kommt es zu einem Laufzeitfehler.

Beispiel

Siehe das Programm DEMO_CL_OSQL_REPLACE.

• Eine produktive Klasse prod liest in der Methode select Daten aus der DDIC-Datenbanktabelle SCARR und löscht in der Methode delete eine Zeile aus dieser Tabelle.

• Die Testklasse test_prod testet die Methoden der produktiven Klasse.

• In der Methode setup wird der Zugriff auf SCARR für lesende und schreibende -Anweisungen mit cl_osql_replace=>activate_replacement auf eine Testtabelle DEMO_TEST_SCARR umgelenkt, die im ABAP Dictionary als Kopie von SCARR definiert wurde. Das Datenbankschema von DEMO_TEST_SCARR wird hier zur Demonstration explizit übergeben, was für Datenbankobjekte aus dem ABAP-Datenbankschema aber nicht notwendig ist.

• Die Testtabelle DEMO_TEST_SCARR wird in der Methode setup aus einer internen Tabelle testdata mit zwei Zeilen Testdaten versorgt.

• In der Methode test wird die Methode select aufgerufen und der Rückgabewert mit der internen Tabelle testdata verglichen. Durch Aufruf der Methode delete wird eine Zeile der Testdaten aus der Testtabelle gelöscht und überprüft, dass es die gelöschte Zeile nicht mehr gibt.

• In der Methode teardown werden die Testdaten aus der Testtabelle gelöscht.

Eine Ausführung des Modultests sollte unabhängig vom Inhalt von SCARR immer erfolgreich sein.

SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up   Fill RESBD Structure from EBP Component Structure  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 15761 Date: 20240523 Time: 183655     sap01-206 ( 178 ms )