Das qRFC Kommunikationsmodell 

QRFC Eigenschaften und Anwendungsmöglichkeiten

Anwendungen aller Art sind auf Kommunikation mit anderen Anwendungen angewiesen. Diese Kommunikation kann intern innerhalb des SAP-Systems stattfinden, mit einem anderen SAP-System, oder mit einer Anwendung aus einem externen entfernten System. Eine Schnittstelle zur Bewältigung dieser Aufgabe ist der Remote Function Call (RFC).  Anwendungen in entfernten Systemen können somit durch einen Aufruf gestartet werden und zur Ausführung einer bestimmten Funktion veranlasst werden.

Während die erste Version des RFC, der synchrone RFC, (sRFC) noch verlangte, dass beide teilnehmenden Systeme aktiv sein mussten um eine synchrone Kommunikation herzustellen, verfügen die folgenden Generationen des RFC über einen erheblich erweiterten Funktionsumfang im Gegensatz zur ursprünglichen Funktionalität des RFC (z.B.: Serialisierung, Garantie der einmaligen Ausführung, das Empfangssystem muss nicht verfügbar sein). Dieser Funktionsumfang wurde nochmals erweitert durch den queuedRFC mit Eingangs/Ausgangsqueue.  

Kommunikation von Anwendungen innerhalb eines SAP-Systems und auch zu einem entfernten System kann grundsätzlich mit dem Remote Function Call (RFC) durchgeführt werden. Damit sind folgende Szenarien denkbar:

 

·   Kommunikation zwischen zwei unabhängigen SAP-Systemen

·   Kommunikation zwischen einem aufrufenden SAP-System und einem externen empfangendem System

·   Kommunikation zwischen einem aufrufenden externen System und einem SAP-System als empfangendem System.

 

Wie die Kommunikationsszenarien in der Praxis aussehen können, zeigt das folgende Kommunikationsmodell. Die eigentliche Versendung wird weiterhin vom tRFC (transaktionaler Remote Function Call) übernommen. Dem tRFC werden Eingangs- und Ausgangsqueues vorangestellt, so dass man vom qRFC (queued Remote Function Call) spricht. Das Sendesystem wird auch als Clientsystem bezeichnet, während das Zielsystem dem Serversystem entspricht.

 

In der Praxis ergeben sich die folgenden drei Szenarien der Datenübertragung:

 

Szenario 1: tRFC

Dieses Szenario eignet sich dann, wenn die zu versendenden Daten unabhängig voneinander sind. Eine aufrufende Anwendung (oder Client) in System 1 verwendet eine tRFC Verbindung zu einer Aufgerufenen Anwendung (oder Server) im System 2. In diesem Szenario werden Daten über tRFC übertragen, d.h., jeder ins Zielsystem geschickte Funktionsbaustein wird garantiert genau ein Mal ausgeführt. Die Reihenfolge, in der die Funktionsbauseine ausgeführt werden, sowie der Zeitpunkt der Ausführung, können nicht festgelegt werden! Bei einem Fehler während der Übertragung, wird ein Batch-Job eingeplant, der den Funktionsbaustein nach 15 Minuten noch einmal sendet.

 

Szenario 2: qRFC mit Ausgangsqueue

In diesem Szenario verwendet das Sendesystem eine Ausgangsqueue, um die zu versendenden Daten zu serialisieren, d.h., voneinander abhängige Funktionsbausteine (Bsp.: Verbuchung, dann Änderung) werden in die Ausgangsqueue des Sendesystems gestellt und garantiert nacheinander und nur ein Mal ins Zielsystem geschickt. Das aufgerufene System (Server) besitzt keine Kenntnis von der Ausgangsqueue im Sendesystem (Client), d.h., mit diesem Szenario kann jedes SAP-System auch mit einem Nicht-SAP-System kommunizieren (Hinweis: Das Programmcoding des Server-Systems muss dazu nicht geändert werden. Es muss aber tRFC-fähig sein!!).

 

Szenario 3: qRFC mit Eingangsqueue (& Ausgangsqueue)

In diesem Szenario gibt es zusätzlich zur Ausgangsqueue im Sendesystem (Client) noch eine Eingangsqueue im Zielsystem (Server). qRFC mit Eingangsqueue bedeutet immer, dass eine Ausgangsqueue im Sendesystem existiert. So wird die Reihenfolge garantiert und gleichzeitig werden die Ressourcen im Client- und Serversystem effizient gesteuert.  Die Eingangsqueue verarbeitet nur so viele Funktionsbausteine, wie es die momentanen Ressourcen des Zielsystems (Server) zulassen. Damit wird verhindert, dass ein Server von einem Client blockiert werden kann. Ein Szenario mit einer Eingangsqueue im Serversystem ist nicht möglich, da die Ausgangsqueue im Clientsystem benötigt wird um die Reihenfolge zu garantieren und um zu verhindern, dass einzelne Anwendungen alle Workprozesse im Clientsystem blockieren.

 

Eigenschaften der drei Kommunikationstypen 

Um zu entscheiden, welchen Kommunikationstyp Sie in ihrer Systemlandschaft und für ihre Anforderungen einsetzen sollten, hier noch einmal die Vorteile der drei Kommunikationstypen:

...

       1.      tRFC: nur für unabhängige Funktionsbausteine

       2.      qRFC mit Ausgangsqueue: abhängige Funktionsbausteine werden garantiert nacheinander und nur ein Mal geschickt (Serialisierung). Geeignet für Kommunikation mit Nicht-SAP-Servern.

       3.      QRFC mit Eingangsqueue: Zusätzlich zur Ausgangsqueue im Client-System regelt eine Eingangsqueue im Zielsystem (Server), dass nur so viele Funktionsbausteine verarbeitet werden, wie Ressourcen zur Verfügung stehen. Client und Server-System müssen SAP-Systeme sein. Pro Eingangsqueue wird ein Workprozess verwendet

 

 

Detailliertere Informationen erhalten Sie in der qRFC-Dokumentation:

Das qRFC Kommunikationsmodell

 

Queued Remote Function Call (qRFC)

 

 Zur Ansicht des gesamten qRFC-Verzeichnisbaums, klicken Sie im linken oberen Bildschirmbereich auf Synchronisieren. Nun können Sie problemlos in der gesamten qRFC-Dokumentation navigieren.

 

Asynchrone RFC-Aufrufe