bgRFC (Background RFC) 

Einsatzmöglichkeiten

Diese Dokumentation präsentiert die Änderungen am Design des qRFC im Vergleich zum neu entwickelten bgRFC (Background RFC). Das primäre Ziel des bgRFC Projektes ist es,  das Laufzeitverhalten des qRFC zu verbessern und trotzdem Protokoll-kompatibel zum qRFC zu bleiben, damit eine Umstellung bei Kunden keine Todzeiten der betroffenen Systeme erforderlich macht. Das verbesserte Design sorgt dafür, dass Massendaten mit großen Reihenfolge-Abhängigkeiten, wie sie z.B. im SCM-Szenario entstehen, effektiver abgearbeitet werden können. Der bgRFC bietet die Ausführung von Aufrufen „Exactly Once“ (entspricht tRFC) und „Exactly Once in Order“ (entspricht qRFC).

 

Integration & Einschränkungen

Der neue bgRFC wird parallel neben den qRFC gestellt. Eine Vermischung des neuen mit dem klassischen Verfahren ist deshalb nicht möglich. Es ist aber möglich, die beiden Verfahren parallel zu verwenden. Da diese disjunkt sind und eine Fehlbedienung verhindert werden soll, wird für das Outbound-Verfahren an der Destination hinterlegt, welches Verfahren verwendet werden darf. Das bedeutet, dass alle Transaktionen, die eine Vernetzung ihrer qRFC-Aufrufe benötigen, entweder auf das neue bgRFC Verfahren umsteigen oder weiterhin das bestehende Verfahren verwenden müssen. Der synchrone und asynchrone RFC ist davon nicht betroffen.

 

Funktionsumfang & Architektur

Im klassischen qRFC-Modell werden die Abhängigkeiten zwischen den einzelnen Units erst zum Zeitpunkt ermittelt, zu dem die Daten über die RFC-Scheduler verarbeitet werden. Der Outbound-Scheduler startet für jede Destination einen Destinations-Scheduler, der die Daten für eine bestimmte Destination verarbeitet.  Die Destinations-Scheduler arbeiten auf den einzelnen Destinationen nur eine begrenzte Zeit, um eine Gleichverteilung der Abarbeitung unter allen Destinationen zu gewährleisten.

Dadurch muss vor jeder Abarbeitung einer Destination erneut die Reihenfolge durch den Destinations-Scheduler ermittelt werden.

Optimierungen

Das neue bgRFC Design greift dieses Problem auf, indem die Ermittlung der Abhängigkeiten 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 Anzahl von Outbound-Schedulern gestartet, welche sich die anstehende Arbeit kooperativ teilen. Die neuen RFC-Scheduler werden sensibler für die Last auf den Zielsystemen. Im bisherigen Modell baut die Lastverteilung auf dem Konzept der Logon-Gruppen auf. Dies bedeutet, dass die zur Laufzeit verfügbaren Informationen über die Last der Zielsysteme bis zu fünf Minuten alt sein können. Im verbesserten bgRFC Design werden diese Informationen in kürzeren Abständen aufgefrischt.

Eine weitere Optimierung betrifft die Gateways, welche potentielle Engpässe darstellen. Das neue Konzept reguliert die maximale Anzahl von Outbound-Schedulern, die parallel auf einem Applikationsserver laufen dürfen und die maximale Anzahl von Verbindungen, die alle RFC-Scheduler zusammen verwenden dürfen. Diese Beschränkung verhindert eine Überlastung des lokalen Gateways. Aber auch die Gateways der Destinationen werden vor Überlastung geschützt, indem die Anzahl der parallelen Outbound-Scheduler pro sendendes System und deren maximale Anzahl von Verbindungen konfigurierbar sind.

 

Ergebnis

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 lineare Skalierbarkeit bei der Verarbeitung von RFC-Daten erreicht. Das transaktionale Verhalten von qRFC 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.