qRFC mit Ausgangsqueue im Überblick (SAP-Bibliothek

qRFC mit Ausgangsqueue im Überblick

Im folgenden gehen wir von den Voraussetzungen aus, daß die Verarbeitungsreihenfolge der Transaktionen im Anwendungsprogramm definiert ist und ferner, daß an einer Transaktion mehrere Queues beteiligt sein können.

Eigenschaften

Die Besonderheiten des qRFC mit Ausgangsqueue lassen sich wie folgt zusammenfassen:

Der queued RFC mit Ausgangsqueue erzwingt eine Serialisierung vonseiten des Sendesystems. Das Zielsystem hat keine Kenntnis von der Serialisierung im Sendesystem. Somit ist eine Kommunikation mit jedem beliebigen R/3-Zielsystem ab Rel. 3.0 möglich.

qRFC mit Ausgangsqueue stellt eine Erweiterung von 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. Ferner wird nach der Ausführung einer qRFC-Transaktion versucht, alle wartenden qRFC-Transaktionen der Reihenfolge nach automatisch zu starten.

Für die Queue-Verwaltung werden ein Queue-Name und ein Queue-Zähler pro qRFC-Transaktion benötigt. Jeder zu serialierende tRFC-Aufruf wird einem von der Anwendung selbst zu bestimmenden Queue-Namen zugeordnet. Der Queue-Name wird mit dem Aufruf des Funktionsbausteins TRFC_SET_QUEUE_NAME übergeben. Dies erfolgt direkt vor jedem zu serialisierenden tRFC-Aufruf. Siehe auch Serialisierung programmieren.
Ein Queue-Name ist ein frei wählbarer Text bis zu einer max. Länge von 24 B, der das Zeichen * nicht enthalten darf.

Hinweis

Es empfiehlt sich, Queue-Namen so zu wählen, daß verschiedene Anwendungen nicht unabsichtlich den gleichen Namen verwenden (Beispiele: SFA_… oder APO_…).

Eine Queue-Konfigurierung wird nicht vorgenommen, da es sich um eine logische Queue handelt. Es sind keine separaten Tabellen für die einzelnen Queues vorgesehen. Zu einem R/3-System gibt also es nur eine Tabelle für die Ausgangsqueues. Alle Angaben zu Queues von allen beteilgten LUW's werden in der Queue-Tabelle TRFCQOUT abgelegt.
Falls die zu serialisierenden tRFC-Aufrufe innerhalb einer LUW auf mehrere Destinationen verteilt sind, werden sie nach Destinationen gebündelt und unabhängig voneinander behandelt. Eine Gruppierung in Sub-LUW's innnerhalb einer LUW, wie beim bisherigen tRFC, ist die Folge. Es gibt auch hier keine Garantie über die Reihenfolge der Ausführung dieser Sub-LUW's, sondern nur die Gewährleistung, daß alle früher oder später übertragen werden. Anders als beim bisherigen tRFC erhält aber jede solche Sub-LUW eine eigene Transaktions-ID zur besseren und einfacheren Queue-Behandlung.
Die Reihenfolge der zu serialisierenden tRFC-Aufrufe mit oder ohne die Option AS SEPARATE UNIT in einer LUW wird gewährleistet, auch dann wenn sie verschiedenen Queues zugeordnet sind.
Mit dem Absetzen des COMMIT WORK wird ein Zähler ermittelt, der als Kriterium für die Reihenfolge der LUW-Ausführung in einer Queue herangezogen wird. Bei 2 aus Anwendungssicht abhängigen LUW's kann ein COMMIT WORK der 2. LUW erst dann erfolgen kann, nachdem der COMMIT WORK der ersten LUW durchgeführt worden ist.
Ein "Mischbetrieb" wird unterstützt: Innerhalb einer LUW können sowohl normale als auch zu serialisierende tRFC-Aufrufe, mit oder ohne den Zusatz AS SEPARATE UNIT vorkommen. Die Reihenfolge der tRFC-Aufrufe wird selbstverständlich gewährleistet.

Die "normalen" tRFC-Aufrufe innerhalb einer LUW mit "Mischbetrieb" und die zu serialisierenden tRFC-Aufrufe gleicher Destination bilden bezüglich ihrer Zuordnung eine Sub-LUW. Falls innerhalb einer LUW für eine bestimmte Destination kein qRFC-Aufruf definiert wurde, bilden die "normalen" tRFC-Aufrufe selbst eine eigene Sub-LUW.

Anders als beim bisherigen tRFC, wo alle tRFC-Aufrufe unterschiedlicher Destinationen nur einer gemeinsamen Transaktions-ID, aber intern verschiedenenen Sub-LUW's zugeordnet werden, erhält jede Bündelung von tRFC-/qRFC-Aufrufen gleicher Destination zur besseren Queue-Bearbeitung eine eigene Transaktions-ID. Um jedoch eine Kompatibilität in der bisherigen tRFC-Behandlung zu erreichen, muß eine Anwendung, die "Mischbetrieb" in einer LUW einsetzt und der erste Aufruf ein tRFC-Aufruf ist, zuerst den Funktionsbaustein TRFC_QUEUE_INITIALIZE absetzen. Siehe auch "Mischbetrieb" einsetzen.

Die "normalen separaten" tRFC-Aufrufe (mit Zusatz AS SEPARATE UNIT) in einer LUW mit "Mischbetrieb" werden wie bisher behandelt (eigene Transaktions-ID).

Die zu serialisierenden "separaten" tRFC-Aufrufe werden zwar queue-abhängig, jedoch unabhängig von der eigentlichen LUW bearbeitet.

Ein Nebeneffekt und zugleich ein Vorteil des qRFC mit Ausgangsqueue gegenüber dem bisherigen tRFC ist, daß sowohl das Sende- als auch das Zielsystem durch die Serialisierung nicht sehr stark belastet werden (aufgrund geringerer Parallelisierung). Eine ungeschickte Auswahl der Queue-Namen (zuviele Namen) kann diesen Vorteil aber wieder zunichte machen. Es handelt sich hierbei aber um einen klassischen Konflikt:
Bessere Performance durch mehr Serialisierung gegenüber schnellerer Verarbeitung durch mehr Parallelisierung. Jede Anwendung muß daher genau abwägen, wie Queue-Namen sinnvoll zu definieren und den einzelnen Funktionsaufrufen zuzuordnen sind.

Welche Probleme sind zu erwarten ?

Folgende allgemeine Serialierungsprobleme sind zu beachten:

Wenn z.B. wegen der Netzwerk-/Kommunikationsprobleme die erste LUW in einer Queue nicht ausgeführt werden kann, bleibt nicht nur diese Queue hängen, sondern auch alle anderen LUW's, die in einer Abhängigkeit mit dieser Queue stehen. Der dadurch entstandene Stau könnte zum Datenbank-Problem führen.
Sobald jedoch das Problem behoben wurde, können alle Transaktionen und somit alle Queues nach und nach automatisch bearbeitet werden.