Wer mit einem SAP-System arbeitet und vor dem Problem stand, eine Funktion in einem anderen Adressraum aufzurufen, hat mit hoher Wahrscheinlichkeit bereits etwas vom „Remote Procedure Call (RPC)“ gehört. Falls nicht, dann vielleicht unter einem anderen Namen: Remote Function Call oder kurz „RFC“.
Was ist der Remote Function Call?
Wie eingangs bereits erwähnt, ist „RFC“ im herkömmlichen Sinne ein Synonym für den „RPC“, jedoch mit speziellem Bezug auf SAP. Der Remote Function Call beschreibt ein Verfahren, mit dem Funktionen über die Grenzen eines Systems hinaus aufgerufen werden können. Es ist also möglich, eine Prozessbearbeitung auf einem entfernten System durchzuführen.
Zusätzlich dazu ist „RFC“ auch die Bezeichnung einer Reihe an SAP-eigenen Protokollen und Schnittstellen zur Abwicklung solcher Funktionsaufrufe. Auf SAP-Systemen unterscheidet man zwischen verschiedenen Arten von RFC-Kommunikationsmöglichkeiten, auf die im späteren noch weiter eingegangen wird.
Funktionsweise
Grundsätzlich wird RFC verwendet, um im weitesten Sinne ein Client-Server-Modell möglich zu machen. Das bedeutet eine Prozessverteilung in einem aktiven, serverbasiertem Netzwerk. In Bezug auf SAP-Systeme ermöglicht diese Vorgehensweise also die Interprozesskommunikation zwischen zwei SAP-ERP-Systemen.
Welche verschiedenen Arten von RFC gibt es?
Bei SAP-Systemen unterscheidet man zwischen drei verschiedenen Arten von RFC-Verbindungen.
Der sRFC führt eine synchrone Kommunikation zwischen den Systemen durch. Das bedeutet, dass die kommunizierenden Prozesse während des Sende- und Empfangsvorgangs synchronisieren. Es wird also bei jedem Vorgang gewartet, bis dieser abgeschlossen ist. Erst dann beginnt der nächste Schritt.
Zu vergleichen ist dies mit der Warteschlange in einem Supermarkt. Der Mitarbeiter an der Kasse (Verarbeitungsprozess) wartet, bis ein Kunde (die zu verarbeitenden Daten) vorhanden ist, bearbeitet diese und wartet dann auf den nächsten „Kunden“.
Hier wird anstelle einer synchronen Kommunikation eine sogenannte asychrone Kommunikation verwendet. tRFC steht dabei für „transaktionaler RFC“. Im Gegensatz zur synchronen Kommunikation wird hierbei nicht auf eine Reaktion des jeweiligen Partnerprozesses gewartet. Somit wird keiner der Prozesse durch einen entsprechenden Wartevorgang blockiert.
Während also bei sRFC der „Verkäufer“ an der Kasse nicht für andere Aktionen zur Verfügung steht, weil er auf eine Reaktion des „Kunden“ wartet, gilt hier ein anderes Muster. Eine asynchrone Kommunikation ist beispielsweise bei einem E-Mail-Verkehr gegeben. Hierbei ist es nicht von Belangen wann, oder ob der Gegenüber antwortet. Nach Abschluss des Versandvorgangs steht der Prozess wieder vollkommen frei zur Verfügung.
Besonderheit:
Kommt es bei einem synchronen Funktionsaufruf (sRFC) zu einem Fehler während des Ablaufs, so wird dem entsprechenden Bearbeiter zwar mitgeteilt, dass ein Fehler aufgetreten ist, das System ist allerdings nicht in der Lage zu erkennen, an welcher Stelle der Fehler entstand. Das bedeutet, dass es im Falle eines Funktions-Neustarts zu einer doppelten Ausführung eines RFCs kommen kann, der bereits abgeschlossen ist.
Der tRFC verhält sich hier anders. Das System verwendet sogenannte Transaction IDs (TID), um sicher zu stellen, dass jede Transaktion nur einmal ausgeführt wird. Dies kann auch durch eine manuelle Eingabe nicht ohne weiteres umgangen werden. Wird ein Vorgang gestartet, so überprüft das System die entsprechende TID und erkennt so frühzeitig, ob dieser bereits abgeschlossen ist oder erneut gestartet werden muss.
Beim sogenannten qRFC (queued RFC) handelt es sich, wie auch beim tRFC, um einen asychronen Funktionsaufruf. qRFC bildet dabei eine Weiterentwicklung vom tRFC.
Besonderheit:
Wird ein transaktionaler RFC (tRFC) verwendet, kann keine Reihenfolge sichergestellt werden, in der die einzelnen Funktionsaufrufe durchgeführt werden. Es kann also passieren, dass das System einen eher unwichtigen Vorgang vor einen eventuell kritischen stellt.
Benötigt man also eine festgelegte Reihenfolge, in der die Funktionsaufrufe abgearbeitet werden sollen, kann man den qRFC verwenden. Wie der Name bereits suggeriert, hat man hier die Möglichkeit eine Warteschlange anzulegen und dem System so vorzugeben, in welcher Reihenfolge die Funktionen aufgerufen werden sollen. Eine Funktion kann somit erst aufgerufen werden, wenn deren Vorgänger bereits abgeschlossen wurden.
Remote Function Call in S/4HANA und „embedded EWM“
Speziell im Hinblick auf viele Anpassungsszenarien bezüglich S/4HANA ergeben sich ebenso viele Fragen über die weitere Verwendung von RFCs in der neuen Business Suite. Verwendet man ein dezentrales EWM-System, so wird qRFC verwendet, um die Kommunikation zwischen EWM und ERP zu gewährleisten. Nun stellt sich dich Frage, ob qRFC weiterhin notwendig ist, wenn das EWM und das ERP dieselben Stammdaten verwenden.
Embedded EWM und ECC befinden sich zwar logisch gesehen auf S4HANA, allerdings wird zur Kommunikation zwischen den beiden Systemen auch weiterhin qRFC verwendet. Dies hat zum einen den großen Vorteil, dass im Falle der Verwendung eines dezentralen EWM-Systems keine zusätzlichen Anpassungen vorgenommen werden müssen, um das ECC auf ein neues Warehouse Management umzustellen.
Des Weiteren ist qRFC nötig, um die aufgerufenen Funktionen auch weiterhin zu steuern und doppelte Ausführungen zu verhindern. Zusätzlich dazu ist es auch so, dass viele Informationen ausschließlich im EWM und nicht im ECC vorhanden sind und im Einzelfall von der jeweiligen Transaktion aufgerufen werden müssen.
Tiefergehende Informationen zu der Konfiguration von RFC im SAP-System finden Sie hier.
Sollten Sie weitere Fragen zum Thema haben oder Unterstützung bei verschiedensten SAP-Projekten in Ihrem Unternehmen benötigen können Sie sich gerne unser Lösungs-Portfolio ansehen und sich natürlich auch gerne mit uns in Verbindung setzen.
