RFC 
Die Kommunikation zwischen Anwendungen verschiedener Systeme im SAP-Umfeld kann sowohl die Verbindung zwischen SAP-Systemen also auch zwischen SAP- und Nicht-SAP-Systemen umfassen. Der Remote Function Call (RFC) ist die SAP-Standardschnittstelle zur Realisierung dieser Kommunikation. Der RFC ruft eine Funktion auf, die in einem entfernten System ausgeführt werden soll.
Mittlerweile gibt es eine ganze Reihe unterschiedlicher RFC-Varianten, die jeweils unterschiedliche Eigenschaften besitzen und folglich für verschiedene Einsatzzwecke geeignet sind:
Synchroner RFC
Die erste Version des RFC ist der synchrone RFC (sRFC). Dieser RFC-Typ führt den Aufruf einer Funktion auf der Grundlage der synchronen Kommunikation durch, d.h. die beteiligten Systeme müssen zum Zeitpunkt des Aufrufs beide ansprechbar sein.
Asynchroner RFC (aRFC)
Der aRFC ist trotz seines Namens keine echter asynchroner Komunikationstyp, da er die Bedingungen hierfür nur bedingt erfüllt. So muss z.B. wie beim sRFC das gerufene System während des Aufrufs verfügbar sein.
Der aRFC hat folgende Hauptmerkmale:
Die Funktionskontrolle kehrt direkt nach dem Aufruf an das rufende Programm zurück.
Die Parameter von asynchronen RFCs werden nicht in die Datenbank geschrieben, sondern direkt an den Server übergeben.
Während eines asynchronen RFCs kann der Benutzer einen Dialog mit dem entfernten System führen.
Wenn der Aufrufer einen aRFC startet, muss der gerufene Server verfügbar sein, um die Anforderung entgegenzunehmen.
Das rufende Programm kann Ergebnisse des asynchronen RFCs empfangen.
Die Verwendung des aRFC ist immer dann sinnvoll, wenn eine Echtzeit-Kommunikation mit einem entfernten System aufgebaut wird, bei der die Verarbeitung im rufenden Programm aber nicht unterbrochen werden soll, bis die Ergebnisse des gerufenen Funktionsbausteins vorliegen (der Begriff asynchron wird hier in diesem Sinn verwendet).
Transaktionaler RFC (tRFC)
Der transaktionale RFC (tRFC, ursprünglich auch asynchroner RFC genannt) ist im Gegensatz zum aRFC eine echte asynchrone Kommunikationsmethode, die den gerufenen Funktionsbaustein im RFC-Server genau einmal ausführt. Das entfernte System muß in dem Moment, in dem das RFC-Client-Programm einen tRFC ausführt, nicht verfügbar sein. Die tRFC-Komponente speichert die gerufene RFC-Funktion zusammen mit den zugehörigen Daten in der SAP-Datenbank unter einer eindeutigen Transaktionskennung (TID).
Wird ein Aufruf gesendet während das Empfangssystem nicht verfügbar ist, bleibt der Aufruf in der lokalen Warteschlange stehen. Das rufende Dialogprogramm kann weiterlaufen ohne darauf zu warten, ob der Funktionsbaustein mit oder ohne Erfolg durchgeführt wurde. Wird das Empfangssystem nicht innerhalb eines bestimmten Zeitraums aktiviert, so wird der Aufruf als Hintergrund-Job eingeplant.
Der tRFC wird immer dann verwendet, wenn eine Funktion als Logical Unit of Work (LUW) ausgeführt werden soll. Innerhalb einer LUW werden dann alle Aufrufe
in der Reihenfolge ausgeführt, in der sie aufgerufen werden
im selben Programmkontext im Zielsystem ausgeführt
in einer einzigen Transaktion ausgeführt: sie werden entweder komplett auf die Datenbank geschrieben (COMMIT) oder komplett zurückgesetzt (ROLLBACK).
Der Einsatz des tRFC ist also immer dann sinnvoll, wenn Sie gewährleisten wollen, dass die transaktionale Reihenfolge von Aufrufen gewährleistet ist.
Nachteile des tRFC
Mit dem tRFC werden alle LUW's unabhängig voneinander behandelt. Dies kann aufgrund der Vielzahl von aktivierten tRFC-Prozessen zu einer deutlichen Verschlechterung der Performance sowohl im Sendesystem als auch im Zielsystem führen.
Ferner kann die in der Anwendung definierte Reihenfolge der LUW's nicht eingehalten werden. Es besteht also keine Gewähr, daß die vom Anwendungsprogramm vorgegebene Reihenfolge der Transaktionen auch eingehalten wird. Es gibt lediglich die Garantie, daß alle LUW's früher oder später übertragen werden.
Queued RFC (qRFC)
Um eine von der Anwendung vorgegebene Reihenfolge mehrerer LUW's zu garantieren, kann eine Serialisierung des tRFC über Queues (Eingangs- oder Ausgangsqueue) vorgenommen werden. Dieser RFC-Typ wird als queued RFC (qRFC) bezeichnet.
qRFC stellt also eine Erweiterung des tRFC dar. Dabei wird eine LUW (Transaktion) erst dann übertragen, wenn sie keine Vorgänger (bezogen auf die in verschiedenen Anwendungsprogrammen definierte Reihenfolge) in den beteiligten Queues hat.
Der Einsatz des qRFC ist immer dann sinnvoll, wenn Sie eine Verarbeitung verschiedener Transaktionen in einer vorgegebenen Reihenfolge sicherstellen wollen.
Background RFC (bgRFC)
Der bgRFC ist die Nachfolgetechnologie für tRFC und qRFC, bei der hinsichtlich Performance und Funktionalität deutliche Verbesserungen erzielt wurden.
Hinweis
Die Verwendung des bgRFC statt tRFC und qRFC wird deshalb dringend empfohlen.
Local Data Queue (LDQ)
Der LDQ ist ein Spezialfall der RFC-Kommunikation. Hier werden keine Daten vom System aktiv versendet, sondern lokal gespeichert, bis Sie von einer externen Anwendung (z.B. ein mobilen Endgerät) nach dem Pull-Prinzip abgerufen werden.
Hinweis
Alle asynchronen RFC-Verfahren (tRFC, qRFC, bgRFC, LDQ) werden unter dem Begriff Background Communication zusammengefasst. Da diese Verfahren gegenüber dem 'normalen' RFC über besondere Eigenschaften verfügen, finden Sie die Informationen zu diesen RFC-Typen in einem eigenen Unterabschnitt.
Achtung