Remote Function Call (RFC) in SAP ABAP Tutorial

Was ist RFC? SAP?

RFC steht für FernfunktionsaufrufEs handelt sich um den Mechanismus, der es Geschäftsanwendungen ermöglicht, mit anderen Systemen in vordefinierten Formaten zu kommunizieren und Informationen auszutauschen. RFC ist die gebräuchlichste Methode, um … SAP Das System kommuniziert mit einem anderen, und es ist auch die Brücke, die verbindet. SAP Systeme zu Nicht-SAP um weitere Anwendungsbeispiele zu finden.

RFC bietet zwei Schnittstellen:

1. Eine Anrufschnittstelle für ABAP-Programme.
2. Eine Anrufschnittstelle für Nicht-SAP Programme.

Jedes ABAP-Programm kann eine Remote-Funktion über die AUFRUFFUNKTION…ZIEL Aussage. Das DESTINATION Parameter gibt an, SAP System, dass die aufgerufene Funktion auf einem anderen System als dem Aufrufer ausgeführt wird.

Syntax

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Logische Ziele werden über Transaktionen definiert. SM59 und in der Tabelle gespeichert RFCDES.

Funktionen der RFC-Schnittstelle

Die RFC-Laufzeitumgebung ist bei jedem Aufruf für drei Dinge zuständig:

• Umwandlung aller Parameterdaten in die vom Remote-System erwartete Darstellung.
• Aufrufen der Kommunikationsroutinen, die für die Kommunikation mit dem Remote-System erforderlich sind.
• Umgang mit Kommunikationsfehlern und deren Anzeige für den Anrufer über das EXCEPTIONS Parameter von CALL FUNCTION.

RFC ist die SAP Ein RFC (Request for Functions) regelt die Kommunikation zwischen Systemen und vereinfacht die zugehörige Programmierung. Es beschreibt den Aufruf eines Funktionsbausteins, der sich auf einem anderen Rechner als das aufrufende Programm befindet. Technisch gesehen können RFCs verwendet werden, um einen Funktionsbaustein auf dem System aufzurufen. gleich Sie werden zwar auch auf anderen Rechnern verwendet, kommen aber am häufigsten zum Einsatz, wenn das aufrufende und das aufgerufene Programm auf unterschiedlichen Rechnern laufen. Das RFC-Schnittstellensystem dient zum Aufbau von RFC-Verbindungen zwischen verschiedenen Rechnern. SAP SystemeSowie zwischen SAP und extern (nicht-SAP) Systeme.

Wichtige Details zu RFC

• SAP verwendet das CPIC CPIC (Common Programming Interface for Communication) ist ein Protokoll zur Datenübertragung zwischen Systemen. SAPRFC ist eine Kommunikationsschnittstelle, die auf CPI-C aufbaut, jedoch mehr Funktionen und eine benutzerfreundlichere Oberfläche für Anwendungsprogrammierer bietet.
• Die RFC-Bibliotheksfunktionen unterstützen die Programmiersprache C und Visual Basic auf Windows Plattformen.
• RFC-Verbindungen funktionieren systemweit. Eine in Mandant 000 definierte RFC-Verbindung kann auch von Mandant 100 aus ohne Unterschied verwendet werden.
• RFC ist das Protokoll zum Aufruf spezialisierter Unterprogramme (Funktionsbausteine) über das Netzwerk. Funktionsbausteine ​​sind vergleichbar mit C-Funktionen oder Pascal-Prozeduren: Sie stellen eine definierte Schnittstelle bereit, über die Daten, Tabellen und Rückgabewerte ausgetauscht werden. Funktionsbausteine ​​werden innerhalb des Netzwerks verwaltet. SAP System in einer eigens dafür eingerichteten Bibliothek, die Funktionsgenerator.
• Der Funktionsgenerator (Transaktion SE37) bietet Anwendungsprogrammierern eine Umgebung zum Schreiben, Dokumentieren und testing Funktionsbausteine, die sowohl lokal als auch remote aufgerufen werden können. Das System generiert automatisch den zusätzlichen Code (den RFC-Stub) für Fernanrufe erforderlich.
• RFC-Verbindungen werden über Transaktionen verwaltet. SM59. SAP versendet auch ein RFC-SDK (Software Development Kit), das umfangreiche C-Bibliotheken verwendet, damit externe Programme eine Verbindung herstellen können. SAP System.
• Der einzige Unterschied zwischen einem Remote-Aufruf an einen anderen Server und einem lokalen Aufruf besteht darin, dass DESTINATION Parameter, der den Zielserver angibt, auf dem das Programm ausgeführt werden soll.

Vorteile von RFC

RFC reduziert den Programmieraufwand, da Module und Methoden auf der Gegenseite nicht erneut implementiert werden müssen. Die RFC-Schicht übernimmt folgende Aufgaben:

• Die Daten werden in ein Format umgewandelt, das das entfernte (Ziel-)System versteht.
• Aufruf der Routinen, die für die Einrichtung der Kommunikation mit dem entfernten System erforderlich sind.
• Umgang mit Kommunikationsfehlern.
• Bereitstellung zuverlässiger Transaktionssemantik bei Verwendung von Transaktions- oder Warteschlangenvarianten.

Arten von RFC

SAP Unterstützt vier RFC-Varianten. Jede bietet einen anderen Kompromiss zwischen Latenz, Zuverlässigkeit und Reihenfolgegarantien.

1. Syncchronous RFC (sRFC)

SyncDer chronologische RFC erfordert, dass sowohl Client als auch Server zum Zeitpunkt des Aufrufs verfügbar sind. Er ist der gebräuchlichste Typ und wird immer dann verwendet, wenn der Aufrufer das Ergebnis unmittelbar nach der Ausführung benötigt.

sRFC ist ein Kommunikationsmittel zwischen Systemen, bei dem Bestätigungen erwartet werden. Die Ressourcen des Quellsystems warten auf das Zielsystem und stellen sicher, dass die Nachricht mit einer Bestätigung (ACK) eintrifft. Die ausgetauschten Daten sind konsistent und zuverlässig.

Der Nachteil besteht darin, dass, wenn das Zielsystem nicht verfügbar ist, die Ressourcen des Quellsystems warten, bis es wieder verfügbar ist, was dazu führen kann, dass Quellsystemprozesse auf dem Zielsystem in den Schlaf-/RFC-/CPIC-Modus versetzt werden und Ressourcen blockiert werden.

Benutzt für:

• Echtzeitkommunikation zwischen Systemen.
• Kommunikation zwischen den SAP Web Application Server und der SAP GUI.

2. Asynchrones RFC (aRFC)

Asynchrone RFC ist die Kommunikation zwischen Systemen, bei der keine Bestätigung erforderlich ist – vergleichbar mit Drop.ping Eine Postkarte per Post. Beide Systeme müssen zum Ausführungszeitpunkt nicht verfügbar sein, und das Ergebnis wird nicht sofort an das aufrufende System zurückgesendet.

Die Ressource des Quellsystems wartet nicht auf das Zielsystem; sie liefert die Daten und fährt fort. Dadurch ist aRFC zwar schnell, aber allein nicht zuverlässig – Daten können verloren gehen, wenn das Zielsystem nicht verfügbar ist.

Benutzt für:

• Fire-and-Forget-Kommunikation zwischen Systemen.
• Parallele Verarbeitung über verschiedene Systeme hinweg.

3. Transaktionsbasierter RFC (tRFC)

Transactional RFC ist eine spezielle Form von asynchronem RFC. Es gewährleistet eine transaktionsähnliche Behandlung von Verarbeitungsschritten, die ansonsten autonom ablaufen würden.

tRFC führt das aufgerufene Funktionsmodul auf dem RFC-Server genau einmal aus, selbst wenn die Daten aufgrund von Netzwerkproblemen mehrfach gesendet werden. Das entfernte System muss zum Zeitpunkt des Aufrufs durch den RFC-Client nicht verfügbar sein. Die tRFC-Komponente speichert die aufgerufene Funktion und ihre Daten im SAP Datenbank unter einer eindeutigen Transaktions-ID (TID)Falls das Zielsystem nicht verfügbar ist, werden die Daten in RFC-Tabellen geschrieben (sichtbar in der Transaktion). SM58und später vom Planungsbericht übernommen RSARFCSE, das alle 60 Sekunden ausgeführt wird.

Benutzt für:

• Erweiterung von asynchronem RFC mit maximal einmaliger Zustellung.
• Zuverlässige Kommunikation zwischen Systemen, bei denen die exakt einmalige Ausführung entscheidend ist.

4. Queued RFC (qRFC)

Queued RFC erweitert tRFC, indem es die Verarbeitung einzelner Schritte in der von der aufrufenden Anwendung vorgegebenen Reihenfolge garantiert. Um sicherzustellen, dass mehrere LUWs (logische Arbeitseinheiten/Transaktionen) in der gewünschten Reihenfolge verarbeitet werden, kann tRFC mithilfe von Eingangs- und Ausgangswarteschlangen serialisiert werden – daher der Name „Queued RFC“.

Benutzt für:

• Erweiterung von Transactional RFC mit strikter Ordnung.
• Szenarien, in denen eine festgelegte Verarbeitungsreihenfolge zwingend erforderlich ist.
• Fälle, in denen mehrere Transaktionen in einer vordefinierten Reihenfolge verarbeitet werden müssen.

RFC-Typenvergleich

Typ	Anrufer wartet?	Zuverlässig?	Bestellt?	besten Für
sRFC	Ja	Ja	Nicht verfügbar (Einzelanruf)	Echtzeit-Abfragen
aRFC	Nein	Nein	Nein	Feuern und vergessen, parallele Arbeit
tRFC	Nein	Ja (genau einmal).	Nein	Zuverlässige asynchrone Aktualisierungen
qRFC	Nein	Ja (genau einmal).	Ja	Streng geordnete Aktualisierungen

Arten von RFC-Verbindungen

SM59 unterstützt verschiedene Verbindungstypen. Die drei am häufigsten anzutreffenden sind nachfolgend zusammengefasst.

Typ 3 — ABAP-zu-ABAP

Einträge vom Typ 3 geben die Verbindung zwischen ABAP-SystemeDer Hostname oder die IP-Adresse ist obligatorisch; Anmeldeinformationen können optional angegeben werden. Typ 3 ist sowohl für RFCs zwischen ABAP-Systemen als auch für externe Aufrufe in ABAP-Systeme anwendbar.

Typ I — Gleichdatenbank-Peer

Einträge vom Typ I kennzeichnen ABAP-Systeme, die dieselbe Datenbank wie das aktuelle System verwenden. Diese Einträge sind vordefiniert und können nicht geändert werden. Ein typischer Eintragsname sieht wie folgt aus: ws0015_K18_24:

• ws0015 — Hostname
• K18 — Systemname (Datenbankname)
• 24 — TCP-Dienstname

Typ T – Externes Programm

Ziele vom Typ T stellen Verbindungen zu externen Programmen her, die die RFC-API zum Empfangen von RFCs verwenden. Der Aktivierungstyp kann entweder Start or Anmeldung Im Falle der Option „Start“ müssen der Hostname und der Pfad des zu startenden Programms angegeben werden.

So erreichen Code ein RFC

Der vollständige Aufbau eines RFC umfasst fünf Schritte. Die ersten drei sind mechanische Klicks in SE37 und SM59; die letzten beiden betreffen die Einrichtung der Verbindung.tracRichtig.

Schritt 1: Auf der Registerkarte „Funktionsbausteinattribute“ der Transaktion SE37, den Verarbeitungstyp festlegen auf Fernsteuerfähiges Modul um das Funktionsmodul als RFC-fähig zu kennzeichnen.

Schritt 2: Schreiben Sie den Code für das Funktionsmodul im Quellcode-Editor.

Schritt 3: Definieren Sie das Ziel des RFC-Servers im RFC-Clientsystem, das die Remote-Funktion aufruft – dies erfolgt in der Transaktion. SM59.

Schritt 4 — Parameter deklarieren: Alle Parameterfelder eines Remote-Funktionsbausteins müssen als Referenzfelder definiert werden – d. h. sie müssen mit Feldern aus dem ABAP Dictionary typisiert sein. Wertparameter sind für Remote-fähige Funktionsbausteine ​​nicht zulässig.

Schritt 5 – Ausnahmen: Das System wirft Kommunikationsfehler und SYSTEMFEHLER Intern werden Fehler auf Transportebene behandelt. Ausnahmen auf Anwendungsebene können innerhalb einer Remote-Funktion genauso ausgelöst werden wie in einer lokalen Funktion.

Debuggen von Remote-Funktionsaufrufen

• Debuggen nicht möglich Ein Remote-Funktionsaufruf in ein Nicht-ABAP-System auf die klassische Weise – die fremde Laufzeitumgebung ist undurchsichtig.
• Bei ABAP-zu-ABAP-RFC-Aufrufen kann jedoch der ABAP-Debugger verwendet werden, um die Ausführung der RFC-Funktion im entfernten System zu überwachen.
• Bei Remote-Aufrufen läuft der ABAP-Debugger (einschließlich seiner Benutzeroberfläche) auf dem lokalen System. Datenwerte und andere Laufzeitinformationen für die Remote-Funktion werden vom Remote-System zurückgesendet.

Wesentliche SAP RFC-Transaktionen

Die alltägliche RFC-Toolbox reduziert sich auf eine Handvoll T-Codes, die jeder ABAP-Entwickler und Basis-Administrator reflexartig kennen sollte.

T-Code	Zweck
SM59	RFC-Ziele pflegen – Host, Anmeldung, Typ, Sicherheit.
SE37	Funktionsgenerator – Erstellen oder Bearbeiten von fernsteuerbaren Funktionsbausteinen.
SM58	Fehlgeschlagene transaktionale RFCs überwachen und erneut verarbeiten.
SMQ1 / SMQ2	Überwachen Sie ausgehende (SMQ1) und eingehende (SMQ2) qRFC-Warteschlangen.
STRUST	Pflegen Sie die SSL-Zertifikate, die von HTTPS-geschützten RFC-Zielen verwendet werden.
ST22	Untersuchen Sie Kurzdumps, die durch fehlgeschlagene Remote-Aufrufe verursacht wurden.

Best Practices für SAP RFC

Eine gut konzipierte RFC-Schicht sorgt für schnelle, nachvollziehbare und leicht erweiterbare Integrationen. Die folgenden Vorgehensweisen sollten in jedes Projekt integriert werden.

• Wählen Sie die richtige Variante für die Herausforderung.tract. Verwenden Sie sRFC für synchrone Suchvorgänge, tRFC für asynchrone Aktualisierungen, die höchstens einmal erfolgen, und qRFC, wenn die Reihenfolge wichtig ist.
• Ein Ziel pro Zielsystem wiederverwenden Anstatt Hostnamen auf viele Ziele zu verteilen, wird die Anmeldeinformationsrotation genutzt. tracTabelle.
• Anmeldeinformationen niemals fest im Code speichern. in ABAP. Verwenden Sie nach Möglichkeit vertrauenswürdige Systemverbindungen oder sichere Anmeldetickets.
• SM58 und SMQ2 regelmäßig überwachen. Feststeckende tRFC-Einträge verzögern Geschäftsprozesse unbemerkt, bis sie erneut verarbeitet werden.
• Übergeben Sie nur Parameter vom Referenztyp. Wertparameter führen zu Problemen mit fernsteuerbaren Funktionsbausteinen.
• Verwenden Sie STRUST zur Verwaltung von TLS-Zertifikaten. Bei HTTPS-Zielen sind abgelaufene Zertifikate eine der Hauptursachen für mysteriöse COMMUNICATION_FAILURE-Fehlermeldungen.

Häufig gestellte Fragen