bgRFC: Architektur 

 

Abhängigkeiten

Im klassischen qRFC-Modell werden die Abhängigkeiten zwischen den einzelnen Units erst dann ermittelt, wenn die Daten über die RFC-Scheduler verarbeitet werden. Der Outbound-Scheduler startet für jede Destination einen Scheduler, der die Daten für diese Destination prozessiert. 

Diese Scheduler arbeiten auf den einzelnen Destinationen nur eine begrenzte Zeit, um eine gleichmäßige Abarbeitung für alle Destinationen zu gewährleisten. Deshalb muss der Scheduler vor jeder Abarbeitung einer Destination die Reihenfolge erneut ermitteln.

Beim bgRFC Design hingegen findet die Ermittlung der Abhängigkeiten bereits zum Zeitpunkt der Ablage der Daten stattfindet. Der RFC-Scheduler findet dadurch mit geringem Aufwand alle Units, die sofort ausführbar sind und die Abhängigkeiten werden nur ein einziges Mal ermittelt. Der zusätzliche Aufwand bei der Ablage der Daten wird durch effiziente Algorithmen und Optimierungen am Datenbank-Design weitgehend kompensiert.

Pro Mandant wird eine definierte Anzahl von Outbound-Schedulern gestartet, welche die anstehende Last parallel abarbeiten, wobei die Ermittlung der Last auf den Zielsystemen in kürzeren Zeitabständen stattfindet und somit genauer arbeitet als bisher.

 

Löschverfahren für Units und Queues

Werden Units oder Queues gelöscht, bleiben entgegen dem klassischen Verfahren die Abhängigkeiten erhalten, da die Units nur markiert und erst durch den Scheduler gelöscht werden.

Beispiel:

 

Nach dem Löschen der Unit4 kann die Unit6 erst nach der Unit3 ausgeführt werden, da die Unit4 erst gelöscht wird, nachdem der Scheduler die Unit3 verarbeitet hat. Löscht man hingegen die Queue2, so ergibt sich folgendes Bild:

 

 

Demzufolge wird die Unit6 nach der Unit2 ausgeführt. Alle markierten Units werden vom Scheduler gelöscht.

 

 

Das Löschen einer Queue oder Unit ist also immer mit einem Risiko behaftet. In unseren Beispielen könnte es passieren, dass die Unit6 auf einen Fehler läuft oder zu einem Datenschiefstand im Zielsystem führt, da die notwendigen Vorarbeiten in der Unit4 durch das Löschen entfallen sind.

 

Gateway

Eine weitere Optimierung betrifft die Gateways, die potentielle Engpässe darstellen. Das neue Konzept reguliert die maximale Anzahl von Outbound-Schedulern, die parallel auf einem Applikationsserver laufen dürfen sowie die maximale Anzahl von Verbindungen, die alle RFC-Scheduler zusammen verwenden können. Diese Beschränkung verhindert eine Überlastung des lokalen Gateways.

Auch die Gateways der Destinationen werden vor Überlastung geschützt, indem die Anzahl der parallelen Outbound-Scheduler pro Sender-System und deren maximale Anzahl von Verbindungen konfigurierbar sind.

 

Performance-Effekte

Die mit dem neuen bgRFC Design erreichten Verbesserungen machen sich primär unter Hochlast-Bedingungen mit vielen abhängigen Units pro Destination bemerkbar. Es wird erstmals eine linear logarhitmische Skalierbarkeit (abhängig von der Systemkapazität) bei der Verarbeitung von RFC-Daten erreicht.

Das transaktionale Verhalten der Queuing-Funktionalität erlaubt keine wesentlichen Einsparungen bei der Verarbeitung einer einzelnen Unit, aber der Einsatz von mehr oder schnellerer Hardware macht sich jetzt direkt mit mehr Durchsatz bemerkbar. Die beschränkenden Faktoren sind die Performance der Datenbank und die Verarbeitungsgeschwindigkeit der Units.

Ein neues API trägt zusätzlich zu einer optimierten Vorgehensweise bei. Redundante Funktionalität wurde entfernt und Beschränkungen des klassischen API teilweise aufgehoben. Dies führt zu einem bereinigten und damit effizienteren Konzept, welches sowohl den Support- als auch den Entwicklungsaufwand deutlich reduziert.