19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Dieses Buch bietet einen einfachen Einstieg in die Welt der ABAP-Schnittstellen. Es führt in alle relevanten klassischen Technologien für die System-zu-System-Kommunikation mit ABAP ein, einschließlich synchroner und asynchroner Techniken.
Im Mittelpunkt steht zunächst das RFC-Protokoll, mit dem Sie Anwendungen erstellen und das Ihnen als Grundlage für moderne Schnittstellen wie Web Services in ABAP dient. Erfahren Sie, wie Sie in nur drei Minuten einen RFC (Remote Function Call ) anlegen und begleiten Sie den Autor anschließend durch ein detailliertes Beispiel. Tauchen Sie ein in das Erstellen und Verwenden von BAPIs, IDocs und ALE und verschaffen Sie sich einen Überblick über SAP Connectors. Schließlich lernen Sie zusätzliche wichtige Aspekte der Verwendung von Funktionsbausteinen in SAP S/4HANA kennen.
Am Ende der Lektüre können Sie entscheiden, welche Schnittstellentechnologie für Ihr Projekt zu wählen ist und direkt mit der Implementierung beginnen.
- Überblick über klassische SAP-ABAP-Schnittstellentechniken
- Remote Function Call (RFC) und BAPIs
- IDoc und ALE für System-System-Kommunikation
- Einsatz von Remote Function Module (RFM) und BAPIs in SAP S/4HANA
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 206
Veröffentlichungsjahr: 2019
Ähnliche
Dr. Boris Rubarth
Schnittstellen-Programmierungin SAP® ABAP
Teil 1: Klassische Schnittstellen
Dr. Boris Rubarth Schnittstellenprogrammierung in SAP® ABAP
ISBN:978-3-96012-153-4
Lektorat:Anja Achilles
Korrektorat:Stefan Marschner
Coverdesign:Philip Esch
Coverfoto:© peterschreiber.media | ID 68900453 – stock.adobe.com
Satz & Layout:Johann-Christian Hanke
Alle Rechte vorbehalten
1. Auflage 2019
© Espresso Tutorials GmbH, Gleichen 2019
URL:www.espresso-tutorials.de
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Bahnhofstr. 2, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback:Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos: https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren: http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Boris Rubarth:
Schnelleinstieg in ABAP: Das Einsteigerbuch
Thomas Stutenbäumer:
SAP-Praxishandbuch ABAP – Teil 1: Konzeption, Entwicklung, Debugging
Thomas Stutenbäumer:
SAP-Praxishandbuch ABAP – Teil 2: Performance, Erweiterungen und Transportwesen
Rüdiger Deppe:
ABAP-Programmierung unter SAP HANA
Christoph Lordieck:
SAP-Schnelleinstieg: ABAP-Entwicklung in Eclipse
Rüdiger Deppe:
Schnelleinstieg in SAP ABAP Objects – 2., erweiterte Auflage
Maximilian Rupp,
Alexander Rupp: Praxishandbuch SAP UI5 – Von der Idee zur App
Einführung
Dieses Buch bietet einen einfachen und direkten Weg in die Welt der ABAP-Schnittstellen. Es führt in alle relevanten Technologien für eine System-zu-System-Kommunikation mittels ABAP ein.
Die Vielfalt der Schnittstellentechniken von ABAP ist groß, was manchmal zu Verwirrung führen kann. Gleichwohl bieten sich dadurch Lösungsmöglichkeiten für zahlreiche Szenarien, was wiederum faszinierend ist. Ich habe dieses Buch geschrieben, um Ihnen einen leichten Einstieg in die Details der Techniken zu bieten.
Warum sollten wir weiterhin RFC nutzen, obwohl alle üblichen Geschäftsanwendungen auch mit Web Services umgehen können? Was ist der Vorteil der asynchronen Kommunikation, obwohl sie doch keine direkte Antwort liefert? Wenn Sie nach Antworten auf derartige Fragen suchen, dann haben Sie das für Sie passende Buch gefunden.
Die Etappen dieser Reise durch die relevanten ABAP-Schnittstellentechniken bauen aufeinander auf. Sie werden eine Beispiel-Anwendung nutzen, die Sie entwickeln und erweitern, um praktische Erfahrungen im Umgang mit den Techniken zu erlangen.
Auf der Reise werden Sie vielleicht bereits bekannte Stationen passieren, von denen manche gleichwohl aus einer anderen Perspektive betrachtet werden. Deshalb lade ich Sie ein, vom Anfang bis zum Ende zu folgen, auch wenn Ihnen die ersten Schritte auf dem Pfad zunächst sehr einfach erscheinen.
Um die Erläuterungen in diesem Buch nachvollziehen zu können, benötigen Sie ABAP-Vorwissen; Sie sollten mindestens mit den Konzepten aus Schnelleinstieg in ABAP (Dr. Boris Rubarth, Espresso Tutorials, 2013) vertraut sein. Sie benötigen außerdem Zugriff auf zwei ABAP-Systeme (oder wenigstens auf zwei Mandanten in einem System), um an den Übungen zu arbeiten.
Nach der Lektüre des Buches werden Sie in der Lage sein, zu entscheiden, welche Schnittstellentechnologie für Ihr Projekt zu wählen ist, und Sie können direkt mit der Implementierung beginnen.
Download aller Listings
Zur einfacheren Nutzung der im Buch aufgeführten Code-Beispiele bieten wir Ihnen diese unter https://de.espresso-tutorials.com/_ABAP_P3.php in einer Datei zum Download an.Um die Lesbarkeit des Quellcodes in Ihrem E-Book-Lesegerät zu verbessern, empfehlen wir außerdem, den Quellcode im Querformat zu betrachten.
Danksagung
Dieses Buch widme ich meiner geliebten Frau. Ohne ihre Unterstützung und Güte wäre dessen Realisierung nicht möglich gewesen. Ein besonderer Dank gilt dem großartigen Team von Espresso Tutorials für die umfassende und flexible Unterstützung.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Gender-Anmerkung
Um den Lesefluss nicht zu beeinträchtigen, wird im vorliegenden Buch bei personenbezogenen Substantiven und Pronomen zwar nur die gewohnte männliche Sprachform verwendet, stets aber die weibliche Form gleichermaßen mitgemeint.
Hinweis zum Urheberrecht
Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Remote Function Call (RFC) nutzen
Ein Verständnis für das RFC-Protokoll ist wichtig – nicht nur, um Anwendungen zu erstellen, die diese vielfältige und gut etablierte Kommunikationstechnik nutzen; es bildet mit den remotefähigen Funktionsbausteinen auch eine bedeutsame Grundlage für moderne Schnittstellentechniken wie Web Services in ABAP.
Unsere Reise startet mit dem Anlegen eines RFCs in nur drei Minuten. Danach erweitern wir das Beispiel und fügen fehlende Aspekte hinzu. Der Weg verläuft parallel über den Client- und den Server-Aspekt, wird Schritt für Schritt komplexer sowie umfangreicher und führt schließlich zu einem eigenen Szenario.
1.1 RFC in drei Minuten implementieren
Angenommen, Sie entwickeln eine ABAP-Anwendung, in der Sie Zugriff auf Daten benötigen, die von einem anderen ABAP-System über einen Funktionsbaustein angeboten werden. Der Zugriff auf die Daten ist recht einfach: Sie nutzen einen Remote Function Call (RFC). Abbildung 1.1 zeigt eine vereinfachte Sicht auf das Prinzip des Datenzugriffs: Ihre Anwendung initiiert den RFC, und das Remote-System bietet den Funktionsbaustein.
Abbildung 1.1: Vereinfachtes Prinzip eines Remote Function Calls
Wenn Sie mit der ABAP-Anweisung CALL FUNCTION vertraut sind, nutzen Sie einfach den Zusatz DESTINATION, und Ihr (lokaler) Funktionsaufruf wird zu einer RFC-Anweisung:
CALL FUNCTION '<NAME_OF_FUNCTION_MODULE>' DESTINATION '<NAME_OF_DESTINATION>'
Der Zusatz DESTINATION referenziert eine RFC-Destination, welche die Information über die Verbindung zum Server enthält. Wir werden uns diese Konfiguration in Kürze ansehen.
Da Ihre ABAP-Anwendung (im Quellsystem) den Aufruf initiiert, wird sie als RFC-Client bezeichnet. Das entfernte (remote) ABAP-System (Zielsystem), auf dem der Funktionsbaustein bereitgestellt ist, agiert als RFC-Server.
1. Der Client initiiert die Kommunikation und sendet die Anfrage (Request).
2. Der Server nimmt den Request und übergibt die Daten an den jeweiligen Funktionsbaustein.
3. Der Server gibt dann die Antwort (Response) des Funktionsbausteins über die bestehende Verbindung zurück an den Client, wie Abbildung 1.2 skizziert. Deshalb benötigt der Server selbst keine RFC-Destination, um die Antwort an den Client zurückzusenden.
Abbildung 1.2: RFC-Client/-Server-Sicht
Kommunikations-Terminologie
Auf unserem Weg der Schnittstellenentwicklung werden wir nicht nur Techniken diskutieren, sondern auch relevante Begriffe diskutieren.
Abbildung 1.2 zeigt Client- und Server-Seiten des RFCs, und beide haben eine Kommunikations-Schnittstelle. Eine Schnittstelle (Interface) ist die technische Möglichkeit eines Anwendungssystems, Daten mit anderen Systemen oder Anwendungen auszutauschen. Die Schnittstelle kann beide Teile des Datenaustausches enthalten: Request und Response.
Ein erstes vereinfachtes Beispiel für einen Report mit RFC könnte aussehen wie im Listing 1.1:
Listing 1.1: Report Z_RFC_IN_THREE_MINUTES
Das Beispiel scheint O. K. zu sein, und es funktioniert sogar – aber dies ist weder ein echter Remote Function Call noch saubere Programmierung. Wir haben in mehreren Aspekten geschummelt.
Fangen wir mit dem Remote-System an: Remote bedeutet, dass es sich um einen ABAP-Mandanten (oder ein ABAP-System) ungleich jenem handelt, in dem die RFC-Client-Anwendung ausgeführt wird. Das Beispiel in Listing 1.1 nutzte für den Namen der Destination eine Variable gv_dest mit dem Inhalt SPACE, wodurch der Funktionsbaustein lokal ausgeführt wird. Prüfen Sie den Inhalt von rfchost und rfcsysid in der Struktur gs_rfcsi, so zeigen sie lokale Werte. Wir müssen also für einen Remote Function Call eine RFC-Destination anlegen, die auf ein anderes (Remote-)System zeigt: entweder auf ein anderes ABAP-System oder wenigstens auf einen anderen ABAP-Mandanten im gleichen System. Nachdem wir das in Abschnitt 1.2 erledigt haben, werden wir andere Aspekte diskutieren, um das vereinfachte Coding-Beispiel zu verbessern.
Konventionen für programminterne Namen
Wir halten uns an die Namenskonvention der SAP, die in der ABAP-Dokumentation hinterlegt ist. Sie finden diese Konvention im SAP Help Portal. Für SAP_BASIS 7.50 siehe:
https://help.sap.com/doc/abapdocu_750_index_htm/7.50/de-de/abennaming_conventions.htm.
1.2 RFC-Destination anlegen (Ziel: ABAP)
Sie definieren eine RFC-Destination mittels der Transaktion SM59. Wir diskutieren hier nur ein einfaches Beispiel, weil die Pflege von RFC-Destinationen typischerweise die Aufgabe eines System-Administrators ist, und nicht die eines Entwicklers.
In der Transaktion SM59 wählen Sie Anlegen. Auf dem Pflegebild geben Sie den Namen der Destination an (in Großbuchstaben), wählen Verbindungstyp »3« (für ein ABAP-Zielsystem) und pflegen einen Beschreibungstext (notwendig!) – hier Destination Typ 3. Jetzt drücken Sie Eingabe, um die Parameter auf den gewählten Typ (ABAP-Verbindung) anzupassen, zu sehen in der Mitte von Abbildung 1.3.
Abbildung 1.3: Anlegen einer RFC-Destination vom Typ 3
Auf dem Register Technische Einstellungen wählen Sie Lastverteilung ja, um dem Zielsystem die Entscheidung zu überlassen, welcher Server genutzt wird (statt einen spezifischen Server fest zu hinterlegen) – das ist der empfohlene Ansatz. Im Feld Zielsystem ID geben Sie die System-ID des Zielsystems ein. Im Feld Messageserver hinterlegen Sie den Hostnamen des Message-Servers, und im Feld Gruppe geben Sie eine vorhandene Logon-Gruppe des Zielsystems an (SPACE gibt es in jedem System).
Wechseln Sie zum Register Anmeldung & Sicherheit und hinterlegen Sie den ABAP-Mandanten vom Zielsystem. Sichern Sie die Einstellungen und wählen Sie dann Verbindungstest. Wenn der Test erfolgreich ist, können Sie die Destination in Ihrem Programm nutzen. Wenn Sie keinen Ziel-Benutzer (und Passwort) angeben, also diese Felder leer lassen, wird Ihnen später während des Aufrufs (aus Ihrem Programm) vom Zielsystem das Anmeldebild gezeigt.
Destination unabhängig von Ziel-Funktionsbaustein
Wie wir gesehen haben, referenziert die RFC-Destination keinen speziellen Funktionsbaustein. Die Destination ist generisch für das Server-System und kann in unterschiedlichen RFC-Client-Anwendungen (und aus allen ABAP-Mandanten des Systems) genutzt werden. Beachten Sie: Der Begriff »Client-Anwendung« dient zur Abgrenzung von der Server-Anwendung und hat nichts mit dem englischen Begriff für »Mandant« zu tun.
Wenn Sie in der Destination für das Zielsystem einen gültigen Benutzer vom Typ Dialog inkl. Passwort hinterlegt haben, dann können Sie sich aus der Anzeige der Destination heraus über Remote-Login direkt mit diesem Benutzer am Zielsystem anmelden.
Benutzer erforderlich für Background-Processing
Eine Destination ohne Benutzer/Passwort verhindert, dass Ihre Client-Anwendung, sofern sie diese Destination nutzt, im Hintergrund (background processing) genutzt werden kann.
Natürlich hinterlegen Sie in Ihrer Anwendung nie einen festen Namen für die RFC-Destination. Änderungsaufträge für den Transport von Entwicklungsobjekten entlang der Entwicklungslandschaft enthalten keine RFC-Destinationen (die ja Konfigurationsobjekte sind), da die entsprechenden Zielsysteme sowieso andere Verbindungsdaten benötigen.
Listing 1.2 zeigt die verbesserte Version des Reports Z_RFC_IN_THREE_MINUTES.
Listing 1.2: Verbesserter Report Z_RFC_IN_THREE_MINUTES
Für den Parameter hat die Referenz auf rfcdes-rfcdest den Vorteil, dass dann auf dem Selektionsbild die F4-Hilfe angeboten wird.
Vordefinierte Destinationen ′NONE′ und ′BACK′
Die vordefinierte Destination ′NONE′ entspricht der Verwendung einer Variablen mit Inhalt SPACE: Der Aufruf wird weiterhin über das lokale Gateway geleitet (erläutert in Abschnitt 1.7).
′BACK′ ist eine Destination, die Sie innerhalb von Funktionsbausteinen nutzen können, um zum aufrufenden Client-System zurückzugehen. Besondere Sicherheitsanforderungen sind hierbei notwendig und umsetzbar mittels einer sogenannten callback whitelist. SAP-Hinweis 1686632 erläutert Details dazu.
Transaktion SM59 listet ′BACK′ und ′NONE′ unter Interne Verbindungen. In Ihrer Anwendung müssen Sie diese Destinationen als String referenzieren, also innerhalb von einfachen Hochkommata (im Gegensatz zu SPACE, welches eine ABAP-Variable ist).
Wie bereits erwähnt, benötigt das Zielsystem selbst keine Destination, um den Request zu erhalten oder um direkt zu antworten. Gleichwohl muss das Zielsystem konfiguriert werden, um generell eine RFC-Kommunikation zu ermöglichen, und das umfasst mehr als die Existenz eines Benutzers, der in der RFC-Destination angegeben werden kann. Lassen Sie uns deshalb kurz die RFC-Anforderungen für das Zielsystem ansehen.
1.3 Zielsystem konfigurieren
Es ist selbstverständlich, dass der Funktionsbaustein, der aufgerufen werden soll, im Zielsystem vorhanden sein muss. Und Sie benötigen einen gültigen Benutzer, wie bereits erwähnt.
Zugriff auf Destinationen beschränken, die einen Login-Benutzer enthalten
Das Client-System wird die Benutzer-/Passwort-Informationen aus der Destination (falls hinterlegt) für die Anmeldung am Server-System nutzen. Dieser Benutzer unterscheidet sich üblicherweise von dem Login-Benutzer, mit dem Sie sich am Client-System angemeldet haben. Das Feld Berechtigung für Destination erlaubt Ihnen die Angabe einer Berechtigung, sodass Benutzer ohne diese Berechtigung die Destination nicht verwenden dürfen. Sie sollten beispielsweise verhindern, dass alle Login-Benutzer eine Destination nutzen können, die das Ändern der Gehaltsdaten im Zielsystem ermöglichen würde – leider.
Beim Einrichten der Kommunikation zwischen SAP-Systemen sollte Ihr Administrator die folgenden beiden Aspekte berücksichtigen:
1. Die Konfiguration einer Secure Network Communication (SNC) sichert die Kommunikation zwischen den Systemen über Datenverschlüsselung.
2. Ergänzend ist es möglich, eine Trusting/Trusted RFC-Verbindung zwischen ABAP-Systemen einzurichten, die den Benutzern eine passwortfreie Anmeldung sowie Single Sign-on bietet.
Der Benutzer im Zielsystem benötigt einige Berechtigungen. Eine generelle Anforderung referenziert das Berechtigungsobjekt S_RFC für den jeweils gerufenen Funktionsbaustein. Dessen Ausführung bedarf der Aktivität 16 – Abbildung 1.4 zeigt das Beispiel eines Berechtigungsobjekts, das erlaubt, den Funktionsbaustein RFC_SYSTEM_INFO aufzurufen.
Abbildung 1.4: Beispiel eines Berechtigungsobjekts für S_RFC
Anwendungsspezifische Berechtigungen sind zudem notwendig, um den im Funktionsbaustein hinterlegten Prüfungen zu genügen.
Mehrere Destinationen, unterschiedliche Benutzer, Benutzertyp »Kommunikation«
Sie sollten auf jeden Fall einen Benutzer vom Typ Kommunikation nutzen, der im Ziel beschränkte Berechtigungen hat. Es ist auch gute Praxis, mehrere Client-anwendungsspezifische Destinationen mit wiederum anwendungsspezifischen Benutzern und Berechtigungen zu verwenden. Falls ein Benutzer aus irgendeinem Grund gesperrt ist, dann können zumindest noch die anderen Destinationen eingesetzt werden.
Dies ist insbesondere wichtig, wenn sich unterschiedliche Client-Anwendungen mit demselben Zielsystem verbinden. Würden sie alle denselben (Ziel-)Benutzer verwenden, und eine der Client-Anwendungen sperrt den Benutzer (z.B. durch ein falsches Passwort und zu viele Falschanmeldungen), dann wären auch alle anderen Client-Anwendungen davon betroffen.
Wir haben in Abschnitt 1.2 schon besprochen, dass Sie in einer RFC-Destination eine Logon-Gruppe nutzen sollten, die im Ziel definiert ist (Transaktion SMLG). Es ist üblich, spezielle Logon-Gruppen für die RFC-Kommunikation anzulegen und andere Gruppen für Benutzer-Anmeldungen vorzusehen. Dadurch wird die durch RFC-Aufrufe bedingte Systemlast nicht die Performance der Benutzeraktivitäten beeinträchtigen.
Ziel-Ressourcen
Wir haben für unser erstes Beispiel den Funktionsbaustein RFC_SYSTEM_INFO genutzt. Dieser Baustein gibt optionale Informationen über die aktuellen und maximalen Ressourcen des Zielsystems zurück, die wir noch nicht beachtet haben. Sie enthalten sogar eine empfohlene Verzögerung, die vor dem nächsten Aufruf beachtet werden sollte. Dies legt nahe, dass sich eine Client-Anwendung um die Ressourcen-Verwaltung des Zielsystems kümmern kann. Gleichwohl, wie bereits erwähnt, sollte das Zielsystem von sich aus eine passende Lastverteilung sicherstellen und sich nicht auf eine entsprechende »Rücksichtnahme« auf der Client-Seite verlassen.
Darüber hinaus ist der Profilparameter auth/rfc_authority_check entscheidend für die Authentifizierung und Autorisierung im Zielsystem. Die Hilfe-Dokumentation listet mögliche Werte für diesen Parameter.
Hilfe-Dokumentation für Profilparameter
Zur Ansicht der Hilfe-Dokumentation für Profilparameter starten Sie den Report RSPFPAR und geben den relevanten Parameter an (z.B. auth/rfc_authority_check). Führen Sie den Report aus F8, wählen Sie die entsprechende Zeile mittels F2 aus und anschließend die Hilfe-Dokumentation über F1.
Die Dokumentation zeigt einen weiteren Aspekt, warum unser erstes RFC-Beispiel geschummelt war: Einige Werte von rfc_authority_check führen dazu, dass die Ausführung des Funktionsbausteins RFC_SYSTEM_INFO keine Benutzeranmeldung benötigt. Wenn Sie die zu diesem Baustein gehörige Funktionsgruppe SRFC prüfen, werden Sie RFC_PING als einen weiteren nützlichen Baustein für Testzwecke finden.
Unified Connectivity (UCON)
Das derzeitige Konzept für das Sperren von Remote-Zugriffen auf Funktionsbausteine verlangt, dass jeder Baustein separat gesperrt wird. Das Konzept der Unified Connectivity vereinfacht die Kontrolle und erlaubt den Zugriff nur auf bestimmte, registrierte Bausteine. Das Konzept wurde mit SAP_BASIS 7.40 eingeführt und wird zukünftig erweitert werden.
1.4 Bausteine auf Remotefähigkeit prüfen
Da wir nun unsere selbstgestrickte RFC-Destination haben, können wir fortfahren und ein paar Überlegungen anstellen. Unser einfaches RFC-Beispielprogramm ruft einen Funktionsbaustein auf, ohne dass wir wissen, ob der gewählte Baustein überhaupt remote (mittels RFC) ausgeführt werden kann.
Führen Sie in Ihrem Report Z_RFC_IN_THREE_MINUTES einen Doppelklick auf den Namen des Funktionsbausteins RFC_SYSTEM_INFO aus, um ihn im Function Builder zu öffnen. Diese Vorwärtsnavigation innerhalb des Quellsystems funktioniert, da der Baustein auch dort vorliegt.
Schauen Sie sich das Register Eigenschaften des Funktionsbausteins an: Im Bereich Ablaufart ist der Radiobutton Remote fähiger Baustein ausgewählt, wie in Abbildung 1.5 gezeigt. Dies ist eine Voraussetzung dafür, dass der Baustein aus einem anderen System aufgerufen werden kann. Wir nennen diese Funktionsbausteine remote-enabled function modules (RFM).
Abbildung 1.5: Ablaufart »Remote fähiger Baustein«
ABAP-Klassen sind nicht remotefähig
ABAP-Klassen bieten dieses Attribut nicht, da sie nicht von außerhalb des Systems mittels RFC aufgerufen werden können. Später werden wir diskutieren, ob andere Protokolle als RFC diesen Aufruf erlauben.
Wir haben uns die Eigenschaften des Funktionsbausteins im Quellsystem angeschaut – natürlich ist es wichtig, dass der Funktionsbaustein im Zielsystem remotefähig ist.
Es ist für den RFC übrigens nicht zwingend notwendig, dass der Funktionsbaustein auch im Quellsystem vorhanden ist. Trotzdem ist es natürlich hilfreich, und zwar nicht nur für die Vorwärts-Navigation. Wenn der Baustein im Quellsystem existiert, können Sie mit der Muster-Funktion des Editors eine Vorlage für den CALL FUNCTION-Aufruf erzeugen und dann die Destination manuell hinzufügen. Dies setzt allerdings voraus, dass die Schnittstellen des lokalen und des Ziel- Bausteins identisch sind.
Zentrales Verzeichnis für RFMs
Leider gibt es in einer Systemlandschaft kein zentrales Interface-Verzeichnis für RFMs, das von RFC-Client-Anwendungen für die Syntax des RFC-Aufrufs genutzt werden kann. Die Quelle für das Interface eines Funktionsbausteins ist also immer das Zielsystem.
Bevor Sie einen RFM von einem Quellsystem aus aufrufen, sollten Sie ihn immer zuerst lokal im Zielsystem testen, um sich mit dem Interface vertraut zu machen. Beachten Sie, dass der Testaufruf keine Simulation ist, die ABAP-Laufzeitumgebung wird das ABAP-Coding also ohne Vorbehalt ausführen. Der Test von Funktionsbausteinen ist beschrieben in Schnelleinstieg in ABAP (Espresso Tutorials, 2013).
Starten Sie einen Test für den Funktionsbaustein aus dem Function Builder – beispielsweise über die F8-Funktionstaste. Das Einstiegsbild der Testumgebung zeigt alle Parameter, die der RFM, basierend auf den Parametern in den IMPORT- und TABELLEN-Bereichen des Interface, importieren kann.
Sie werden sehen, dass unser spezieller Funktionsbaustein RFC_SYSTEM_INFO keine Eingabe erfordert, da er keine Parameter in den IMPORT- oder TABELLEN-Bereichen hat. Gleichwohl wird das Textfeld RFC-Zielsystem angeboten, wie in Abbildung 1.6 ersichtlich. Sie können dieses Feld nutzen, um den Namen einer RFC-Destination einzugeben.
Abbildung 1.6: Einstiegsbild der Testumgebung mit Feld »RFC-Zielsystem«
Der Function Builder bietet dieses Feld nur für remotefähige Bausteine an, und es wird vorausgesetzt, dass im Ziel ein identischer Funktionsbaustein existiert. Wenn Sie eine gültige Destination ins Feld eintragen, machen Sie aus dem lokalen Test einen RFC.
Somit bietet die Testumgebung des Function Builders eine einfache RFC-Testmöglichkeit. Gleichwohl ist die Funktionalität beschränkt, denn sie ist nur einsetzbar, wenn der Funktionsbaustein auf beiden Seiten (Client und Server) existiert und die Interfaces auf beiden Seiten identisch sind.
Sie können den Test ausführen und erhalten die Ergebnisse, die Sie bereits von unserem Report kennen (siehe Abbildung 1.7), indem Sie die Struktur RFCSI_EXPORT durch Auswahl des Icons in der Spalte Wert öffnen.
Abbildung 1.7: Ergebnisbild vom Test von RFC_SYSTEM_INFO
Lassen Sie uns noch auf einen anderen Aspekt im Ergebnisbild schauen. Der Parameter Laufzeit zeigt uns die Zeitspanne des Aufrufs vom Request über die Anmeldung bis zur Response an. Merken Sie sich den aktuellen Wert, navigieren Sie mittels F3 zurück auf das Einstiegsbild und starten Sie einen weiteren Test – der Wert für die Laufzeit ist jetzt viel geringer. Der Grund dafür ist, dass die Verbindung zum Zielsystem offen gehalten wird, solange die RFC-Client-Anwendung existiert. In unserem Fall ist die Testumgebung die Client-Anwendung. Wenn Sie die Testumgebung des Function Builders verlassen und für den nächsten Test neu starten, wird die Laufzeit wieder länger sein.
Namensgebung: RFC oder RFM
Manche Kollegen nutzen den Ausdruck »den RFC ausführen«, womit sie die Ausführung des Funktionsbausteins meinen. Wir versuchen, präziser zu sein, und nutzen den Begriff RFM für den Funktionsbaustein und den Begriff RFC für den Aufruf: den Remote-Aufruf des RFM mit dem Protokoll RFC.
Der RFM RFC_SYSTEM_INFO, den wir bisher genutzt haben, ist zu simpel; er nutzt weder IMPORT- und TABELLEN-Parameter noch Ausnahmen. Jetzt sollen gleichwohl Ausnahmen diskutiert werden.
1.5 RFC-Ausnahmen behandeln
Der RFM selbst kann im Bereich des Interface Ausnahmen haben – diese werden unter dem Reiter Ausnahmen gelistet (siehe Abbildung 1.8). Das Coding des Bausteins sieht Fehlersituationen voraus und benachrichtigt den Aufrufer über deren Auftreten mittels einer Ausnahme. Beispiele sind das Fehlen von obligatorischen Parametern im RFC-Aufruf oder ungültige Werte im Aufruf. Ausnahmen, die im Funktionsbaustein definiert sind, können natürlich nicht Situationen außerhalb des Bausteins berücksichtigen, wie etwa Verbindungsprobleme.
Eine Client-Anwendung muss die definierten Ausnahmen im Interface-Teil des RFC-Aufrufs berücksichtigen, und zwar im Bereich Ausnahmen.
Wir nutzen als einfaches Beispiel den RFM DEMO_RFM_CLASSIC_EXCEPTION. Er hat keine Implementierungslogik außer der Anweisung zum Auslösen der Ausnahme CLASSIC_EXCEPTION (mittels RAISING-Statement).
Abbildung 1.8: Ausnahmen-Bereich eines Funktionsbausteins
Ausnahmen im RFM auslösen
Um eine Ausnahme innerhalb eines RFM auszulösen, wird die Anweisung RAISE <EXCEPTION_NAME> genutzt.
Unser Beispiel-RFM DEMO_RFM_CLASSIC_EXCEPTION ist ausgeklügelter – er nutzt das Muster MESSAGE E<msg_number>(<msg_class>) RAISING <EXCEPTION_NAME>. Dies gibt dem RFC-Client die Möglichkeit, einen Nachrichtentext im Feld SY-MSGV1 auszuwerten.
Jede RFC-Client-Anwendung, die diesen RFM ruft, muss die Ausnahme behandeln. Die Ausnahme wird vom Client-System einer Nummer zugeordnet – sobald sie auftritt, wird diese Nummer ins Feld SY-SUBRC geschrieben.
Die RFC-Laufzeit bietet zusätzlich zwei generische RFC-Ausnahmen an, die behandelt werden sollten:
SYSTEM_FAILURE
wird ausgelöst, wenn ein Fehler im Zielsystem auftritt (z.B. der RFM existiert nicht).
COMMUNICATION_FAILURE
wird im Fall von Kommunikationsproblemen ausgelöst (z.B. die RFC-Destination existiert nicht).
Dies führt uns zum Beispielreport Z_RFM_EXCPTN in Listing 1.3.
Listing 1.3: Report zum Abhandeln von Ausnahmen
Die RFC-spezifischen Ausnahmen bieten die Option für weiteren Text, der über den Zusatz MESSAGE in eine Variable übernommen werden kann. Dieser Zusatz ist nicht für die im RFM definierten Ausnahmen verfügbar.
Unterschiedliche Ausnahmen provozieren
Starten Sie den Report mit einer gültigen RFC-Destination, um die Ausnahme CLASSIC_EXCEPTION im RFM auszulösen und im Report abzufangen. Starten Sie den Report erneut und geben Sie den Namen einer ungültigen RFC-Destination an, um die Ausnahme COMMUNICATION_FAILURE auszulösen. Als Drittes ändern Sie den Report und rufen einen nicht existierenden RFM (z.B. DEMO_RFM_CLASSIC_EXCEPTION_2), um zu überprüfen, ob die Ausnahme SYSTEM_FAILURE abgefangen wird.
Generell ist es möglich, dass Funktionsbausteine auch klassenbasierte statt klassische Ausnahmen nutzen. Dies sehen Sie auf dem Register Ausnahmen in den Eigenschaften des Funktionsbausteins, wie in Abbildung 1.9 gezeigt. Die Checkbox Ausnahmeklassen ist im Funktionsbaustein DEMO_RFM_CLASS_BASED_EXCEPTION gesetzt.
Abbildung 1.9: Klassenbasierte Ausnahmen, nicht für RFC möglich
Für die lokale Ausführung des Funktionsbausteins muss die aufrufende Anwendung zum Abhandeln solcher klassenbasierter Ausnahmen einen TRY/CATCH-Block nutzen. Für einen RFC allerdings ist dieser Block nicht notwendig, da die Ausnahmen über die SYSTEM_FAILURE-Ausnahme abgefangen werden.
Klassenbasierte Ausnahmen für RFC
Es gab eine Übergangsphase, in der in einigen Releases auch der RFC für klassenbasierte Ausnahmen einen TRY/CATCH-Block erforderte. Diese Releases basieren auf SAP_BASIS 7.20 und 7.30. Gleichwohl wurden diese Komponenten niemals in einem ABAP-System genutzt, welches Bestandteil der SAP Business Suite war (z.B. SAP ECC). Seit SAP_BASIS 7.40 werden die klassenbasierten Ausnahmen für den RFC über die Ausnahme SYSTEM_FAILURE abgehandelt.
