Inline ABAP 

eCATT-Befehlsvorrat

Die Standardbefehle von eCATT ermöglichen Ihnen das Bearbeiten aller üblichen Prozesse, die für Testanwendungen erforderlich sind. Unter bestimmten Voraussetzungen könnten diese Befehle nicht das gewünschte Ergebnis liefern, das jedoch durch Hilfsfunktionen für das Durchführen von komplexen Aufgaben zu erreichen ist. In einigen Fällen sind beispielsweise Auswahlmöglichkeiten erforderlich, die Sie dynamischer gestalten wollen oder die mehr als einen Einzelsatzzugriff benötigen. Sie wollen möglicherweise auch auf Informationen zugreifen, die nicht in Datenbanken sondern im Speicherbereich abgelegt sind.

Diese speziellen Anforderungen könnten von separat erstellten Funktionsbausteinen oder Reports abgedeckt werden, was jedoch den Nachteil hätte, dass die Hilfsfunktionen (die von FUN oder TCD aufgerufen werden) über eine völlig außerhalb von eCATT liegenden Programmentwicklung in alle betroffene Zielsysteme verteilt sein müssten. Mit Inline ABAP von eCATT vermeiden Sie diesen Nachteil.

Struktur

Sie fügen den auszuführenden ABAP-Code in das eCATT-Skript zwischen den eCATT-Befehlen ABAP und ENDABAP ein.

ABAP.

<ABAP-Code.>

ENDABAP.

Zur Laufzeit wird eine FORM-Routine in dem vorgesehenen Remote-System generiert. Die Routine wird praktisch kontextfrei über ein externes PERFORM aufgerufen.

FORM inline.

ABAP code.

ENDFORM.

Bei einer kontextfreien Ausführung ist die FORM-Routine nicht Teil eines Modul-Pools, einer Funktionsgruppe, einer ABAP-Objektklasse oder eines Reports. Deswegen gibt es keine globale Daten, auf die Sie im ABAP-Code referenzieren können. Sie können jedoch den Moduskontext verwenden, der durch vor und nach der Routine ausgeführten eCATT-Befehle im gleichen Remote-System bestimmt wird. Sie haben also Zugriff auf die gleichen SPA/GPA- und Speicherbereiche.

Datenschnittstelle

Die in der generierten FORM-Routine aufgelisteten Variablen entsprechen den lokalen Variablen, die im aktuellen eCATT-Skript definiert sind. Beachten Sie, dass die Liste nicht die Import- und Exportparameter des Skripts enthält. Für das Verständnis ist die Betrachtung des Versionierungskonzepts in eCATT hilfreich. Ein Testskript kann verschiedene Versionen haben, die in unterschiedlichen Releases verwenden werden sollen. Releases können sich unterscheiden, weil sich Datenbankschnittstellen und die grundlegenden ABAP-Dictionary-Referenzen unterscheiden. In eCATT-Testskripten stellen die lokalen Variablen die Datendefinitionen dar, die versionsabhängig auf verschiedene Releases referenzieren können. Die Import- und Export-Parameter sind niemals versionsabhängig und stellen für die eCATT-Skripte die versionsunabhängige Schnittstelle nach außen dar. Wenn die Import - und Exportparameter auch in der Übergabeschnittstelle von Inline ABAP enthalten wären, würden Generierungsfehler beim Transfer von einem Release zum anderen auftreten. Das sinnvolle Beschränken auf lokale Variablen bietet die größte Sicherheit dafür, dass in den Remote-Systemen die Referenzen für die ABAP-Dictionary-Objekten geeignet sind.

Ihre Programmierung des eCATT-Skripts, das Inline ABAP enthält, sollte festlegen, welche Daten an das entfernte System übergeben werden. Die Schnittstelle wird im eCATT-Skript als lokale Variablen mit den ABAP-Dictionary-Referenzen angelegt, die im Remote-System wirksam werden. Der Datentransfer von Importparametern und zu Exportparametern muss weiterhin außerhalb von Inline ABAP mithilfe von eCATT-Befehlen programmiert werden.

SAP empfiehlt, für jede Inline ABAP-Routine eine separates eCATT-Skript anzulegen und sie jeweils über REF aufzurufen. Im Gegensatz zu anderen eCATT-Befehlen wie FUN, SAP GUI und TCD kann mit dem Befehl ABAP kein explizites Zielsystem angegeben werden. Sie können nur das Zielsystem bestimmen, in dem Sie Inline ABAP ausführen, indem Sie den REF-Aufruf eines Testskripts mit Inline ABAP verwenden oder die globale Destination für die Ausführung setzen.

Programmieren in Inline ABAP

Im Allgemeinen ist der gesamte ABAP-Befehlsvorrat für die Verwendung innerhalb von Inline ABAP verfügbar. Sie müssen jedoch ein paar Dinge beachten.

Sie verwenden DATA-Anweisungen für das Deklarieren von lokal verwendbaren Variablen, doch müssen Sie beachten, dass TYPE-Referenzen in dem entsprechenden Zielsystem wirksam werden. Datenbankzugriffe sind jederzeit unter diesen Referenzen möglich.

Sie können alle CALL-Mechanismen für das Aufrufen der entsprechenden Objekte verwenden – CALL FUNCTION ..., CALL TRANSACTION (USING ...) ..., SUBMIT REPORT ... AND RETURN, CREATE OBJECT ... und CALL METHOD ....

Da Sie sich in einer FORM-Routine befinden, können Sie keine zusätzlichen FORM-Routinen definieren. Externe PERFORM-Aufrufe in andere bereits bestehende FORM-Routinen sind allerdings möglich.

Ein wesentlicher Teil des ABAP-Codes außerhalb von eCATT ist die Dialog-Programmierung. Sie sollte in Inline ABAP vermieden werden. Mit Inline ABAP soll die Gestaltung von Tests verbessert werden. Die meisten dieser Tests sind Massentests, die wiederholt und ohne aktive Beteiligung des Benutzers ausgeführt werden. Jeder Dialog, der durch eine Hilfsfunktion ausgelöst wird, würde den Testverlauf beeinträchtigen. Bei Massenstarts im Hintergrund oder in Batch-ähnlicher Umgebung würden Dialoge zu Programmabbrüchen führen. Es gilt deswegen die Regel, dass keine Funktionen aufgerufen werden sollten, die Dialoge auslösen.

Es gelten außerdem Einschränkungen für Befehle, die die Programmausführung steuern. Benutzen Sie Befehle wie LEAVE (TO TRANSACTION, SCREEN), MESSAGE mit dem Typ ‘E’ oder ‘A’ oder SUBMIT REPORT nicht ohne die Erweiterung AND RETURN. Diese Befehle zerstören den Stack vom Aufruf und trennen somit die RFC-Verbindung zum System, das getestet wird.

Fehler in Inline ABAP

Wie bei jeder ABAP-Programmierung kann auch in Inline ABAP fehlerhafte Programmierung vorkommen.

Syntaxfehler im generierten Programm

Syntaxfehler treten auf, wenn Referenzen zum ABAP Dictionary fehlen. Sie sind möglicherweise für lokale Variablen im Pflegesystem vorhanden gewesen, sind aber im aktuellen Zielsystem für die Ausführung nicht verfügbar.

Es kann auch sein, dass Syntaxfehler auf unvollständiges Programmieren durch den eCATT-Entwickler zurückzuführen sind.

Eine Syntaxprüfung für Inline ABAP ist möglich, wenn eCATT gegen ein Remote-System ausgeführt wird. Sie können Sie unter Testskript  ®  Prüfen  ®  Erweitert aufrufen. Wenn jedoch ein Syntaxfehler auftritt, wird der fehlerhafte Code auch im Remote-System im Programm ECATFRAME gespeichert. Führen Sie folgende Schritte für die Fehleranalyse aus:

       1.      Melden Sie sich beim Zielsystem an.

       2.      Zeigen Sie das Programm ECATFRAME in SE38 an.

       3.      Wechseln Sie von der aktiven zur inaktiven Quelle.

       4.      Rufen Sie die Prüffunktion auf.

Die Syntaxprüfung läuft nun unter den gleichen, korrekten Systembedingungen wie bei der ursprünglichen Ausführung.

Laufzeitfehler im ausgeführten Programm

Wenn Inline ABAP lokal ausgeführt wird, führt ein Laufzeitfehler sofort zu einem Testabbruch mit Dump-Anzeige.

Wenn Inline ABAP remote ausgeführt wird und ein Laufzeitfehler auftritt, wird der remote gestartete Modus mit einem Dump abgebrochen, die RFC-Verbindung getrennt, und der eCATT-Befehl ABAP als fehlerhaft markiert. Die Fehlerbehandlung erfolgt gemäß der Startoptionen.

Für die Dump-Analyse dieser Fehler können Sie im zu testenden System die Transaktion ST22 verwenden.

Das Einfügen der Anweisung BREAK-POINT in den ABAP-Code stellt eine große Hilfe in der Entwicklungsphase Ihres Inline ABAP dar. Wenn Sie den Code im Zielsystem ausführen, stehen Ihnen alle Optionen für das ABAP-Debugging zur Verfügung. Vor dem produktiven Einsatz Ihrer Skripte müssen die BREAK-POINT-Anweisungen entfernt werden, weil sie im Zielsystem Dialoge auslösen.

Berechtigungen in Inline ABAP

Generell sollten während der Ausführung von Inline ABAP für Hilfs- und Prüffunktionen in den eCATT-Tests keine Berechtigungsprobleme auftreten. Jeder Tester mit ausreichenden Berechtigungen für Tests kann auch die zusätzlichen Funktionen von Inline ABAP ausführen, ohne dass zusätzliche Berechtigungen erforderlich sind. Die Ausführung von eCATT in Remote-Systemen wird durch entsprechende Mandanten-Einstellungen gesteuert (Tabelle T000). Sie legen im Einzelnen fest, ob eCATT in einem bestimmten Mandanten gestartet werden kann. Es ist möglich, den Zugriff über eine Trusted RFC-Verbindung zu beschränken. Eine Einstellungsoption erlaubt es sogar, dass eine reguläre RFC-Verbindung für das Starten mehrerer Skripte ausreicht. Sie macht jedoch eine Trusted RFC-Verbindung für das Starten von Skripten innerhalb von Inline ABAP und FUN erforderlich.

Beim Programmieren in Inline ABAP sollten Sie darauf achten, dass der Code sinnvoll im Rahmen von Tests anstatt nur als eine weitere Programmierungsoption ausgeführt wird. Es ist ratsam, die eCATT-Skripte vor dem Anlegen unter diesem Aspekt zu überprüfen.

Generierungsgrenzen

Erfahrene Programmierer sollten beachten, dass 36 dynamisch generierte Programme die oberste Grenze darstellt. Das heißt, ein Maximum von 36 Programm kann innerhalb eines Zielsystem während eines Starts von Inline ABAP generiert werden. Dieses Problem wird in eCATT gelöst, indem nach Erreichen der 36 generierten Programme die RFC-Destination automatisch geschlossen und gleich darauf erneut geöffnet wird, um das nächste generierte Programm auszuführen.

Wenn ein Modus automatisch beendet und nach 36 Generierungen erneut geöffnet wird, verlieren Sie den Kontext im verwendeten Modus (d.h. alle SPA/GPA- und Speicherbereiche sind wieder initial), und in allen aufgerufenen Funktionsgruppen sind globale Variablen wieder initial. Wenn dadurch Fehler in Ihrem eigenen Programmkontext verursacht werden, weil beispielsweise ein Inline ABAP-Block auf Daten referenzieren muss, die von einem anderen ABAP-Block generiert wurden, können Sie zusammenhängende Blöcke von generierten Programmen anlegen. Mithilfe des eCATT-Befehls RESCON schließen Sie die für das aktuelle Zielsystem verwendete RFC-Destination. Nach den 36 generierten Programme beginnt die Zählung nun wieder von vorne, wenn Sie die RFC-Verbindung mit einem anderen eCATT-Befehl wiederherstellen. Deswegen wird dieser bestimmte Kontext für die nächsten 36 generierten Programme erhalten bleiben.

Wenn Programme lokal und ohne Zielsystem ausgeführt werden, verursacht das Überschreiten der Grenze den Abbruch des eCATT-Startvorgangs. Dieses Problem wird umgangen, wenn ein Zielsystem mit der RFC-Destination NONE angegeben wird, weil eCATT dann ebenfalls lokal ausgeführt wird.