Das qRFC
Kommunikationsmodell 
Einsatzmöglichkeiten
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.
Einführungshinweise
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 einem festlegbaren Zeitabschnitt 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 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 wird über einen Inbound Scheduler abgearbeitet, welcher nur so viele Queues parallel verarbeitet, wie es die momentanen Ressourcen des Zielsystems (Server) zulassen. Damit wird verhindert, dass ein Server von einem Client blockiert werden kann.
Funktionsumfang
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 Funktionsbausteinsaufrufe ohne Garantie der Reihenfolge.
2. qRFC mit Ausgangsqueue: Funktionsbausteine innerhalb einer Queue werden garantiert nacheinander und nur ein Mal geschickt (Serialisierung). Auch geeignet für Kommunikation mit Nicht-SAP-Servern.
3. QRFC mit Eingangsqueue: Die in der Ausgangsqueue erzeugten Funktionsbausteine werden von der Ausgangsqueue in die Eingangsqueue übertragen, wobei die Reihenfolge innerhalb der Queues beibehalten wird. Die Verarbeitung der Eingangsqueues wird dann von einem Inbound-Scheduler vorgenommen, der die Verarbeitung entsprechend der eingestellten Ressourcen vornimmt. Client und Server-System müssen SAP-Systeme sein. Pro Eingangsqueue wird ein Workprozess verwendet.