RFC-Varianten 

Im folgenden Abschnitt warden die einzelnen Ausführungsvarianten des RFC beschrieben. Sie können - abhängig von den erforderlichen Service-Eigenschaften – folgende RFC-Varianten verwenden:

Synchroner RFC

1. CALL FUNCTION func DESTINATION dest
                     parameter_list.

Der synchrone RFC (sRFC) führt einen Funktionsaufruf direkt aus und wartet auf die Rückantwort des gerufenen Funktionsbausteins. Die Daten werden vor dem Aufruf nicht auf die Datenbank geschrieben. Bei Verwendung des synchronen RFC ist deshalb die Verfügbarkeit des gerufenen Systems erforderlich. Der Aufruf wird nur einmal ausgeführt. Ist das gerufene System nicht verfügbar oder treten anderen Probleme auf, ist der Aufruf gescheitert (Service-Eigenschaft: At Most Once).

Asynchroner RFC

2. CALL FUNCTION func STARTING NEW TASK task
                [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
                parameter_list
                [{PERFORMING subr}|{CALLING meth} ON END OF TASK].

Obwohl der Name es nahelegt, wird mit dem asynchronen RFC (aRFC) nicht im engeren Sinne ein asynchroner Funktionsaufruf ausgeführt. Zwar kehrt die Funktionskontrolle direkt nach dem Aufruf an das rufende Programm zurück, aber auch hier werden die Daten nicht auf eine Datenbank geschrieben, so dass der Aufruf nur an ein direkt verfügbares System erfolgen kann.

Ist das gerufene System nicht verfügbar, gilt der Aufruf als gescheitert. Der aRFC verfügt also wie der sRFC lediglich über die Service-Eigenschaft At Most Once.

 

Background RFC

3. CALL FUNCTION func IN BACKGROUND UNIT
                     parameter_list.

Im Gegensatz zum aRFC ist der Background RFC (bgRFC) eine „echte“ asynchrone Kommunikationsmethode, die den gerufenen Funktionsbaustein im RFC-Server genau einmal ausführt (Service-Eigenschaft:Exactly Once). Das entfernte System muss in dem Moment, in dem das RFC-Client-Programm einen bgRFC ausführt, nicht verfügbar sein. Die bgRFC-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 bgRFC wird immer dann verwendet, wenn eine Funktion als Unit ausgeführt werden soll. Innerhalb einer Unit werden alle Aufrufe

1.       in der Reihenfolge ausgeführt, in der sie aufgerufen werden

2.       im selben Programmkontext im Zielsystem ausgeführt

3.       in einer einzigen Transaktion ausgeführt: sie werden entweder komplett auf die Datenbank geschrieben (COMMIT) oder komplett zurückgesetzt (ROLLBACK).

Der Einsatz des bgRFC ist also immer dann sinnvoll, wenn die transaktionale Reihenfolge von Aufrufen innerhalb einer Unit gewährleistet werden soll. Der bgRFC kann sowohl transaktional (Typ T) als auch queued (Typ Q) ausgeführt werden. Bei Verwendung des Typ Q werden auch die Units mehrerer Aufrufe in genau der Reihenfolge gesendet und verarbeitet, in der sie auf der Datenbank gespeichert wurden.

 

Transaktionaler RFC

4. CALL FUNCTION func IN BACKGROUND TASK
                     [DESTINATION dest]
                     parameter_list
                     [AS SEPARATE UNIT].

 

Der transaktionale RFC ist das Vorgängerverfahren des bgRFC für transaktionale RFC-Aufrufe. Er besitzt die gleichen Service-Eigenschaften wie der bgRFC. Der tRFC ist aktuell noch genau so verwendbar wie der bgRFC. Ein parallele Nutzung der beiden Verfahren ist jedoch nicht möglich.

 

Queued RFC

 

Der queued RFC (qRFC) ist das Vorgängerverfahren des bgRFC Typ Q. Mit dem qRFC ist ebenfalls eine festgelegte Verarbeitungsreihenfolge realisierbar. Technisch basiert der qRFC auf dem tRFC, nur wird vor dem eigentlichen tRFC-Aufruf der Funktionsbaustein TRFC_SET_QUEUE_NAME ausgeführt, der eine Serialisierung über Queues ermöglicht.

Da der bgRFC gegenüber dem tRFC und dem qRFC deutliche Performance-Vorteile besitzt, wird die Verwendung des bgRFC empfohlen.