Ereignisparallelität und Sperrung im Jitterbit App Builder

Parallelität und Sperren

Standardmäßig werden Ereignisse gleichzeitig ausgeführt. Klicken zwei Benutzer gleichzeitig auf dieselbe Schaltfläche, kann es zu einer Überschneidung der Ereignisausführungen kommen. In manchen Situationen kann eine Synchronisierung der Ereignisse erforderlich sein. Synchronisierte Ereignisse werden seriell ausgeführt, sodass immer nur ein synchronisiertes Ereignis gleichzeitig ausgeführt wird. Nicht synchronisierte Ereignisse können trotz synchronisierter Ereignisse gleichzeitig ausgeführt werden.

Ereignisse werden mit Sperren synchronisiert. Eine Sperre umfasst die Validierung und Aktionen des Ereignisses. Sperren synchronisieren keine anderen Regeln, wie z. B. Standard- oder Sichtbarkeitsregeln.

Notiz

In einer Umfeld mit mehreren Servern stellen verteilte Sperren sicher, dass Ereignisse im gesamten Cluster synchronisiert werden. Bei Verwendung von Redis als gemeinsam genutzter Statusanbieter wird der Redlock-Algorithmus verwendet.

Um die Ereignissperre zu aktivieren, aktivieren Sie beim Erstellen oder Ändern des Ereignisses die Option Sperre verwenden. Dadurch werden zusätzliche Sperroptionen aktiviert. Die Option „Sperre verwenden“ ist in der Ereigniskonfiguration verfügbar, indem Sie auf Edge Case klicken.

Vorsicht

Seien Sie vorsichtig bei der Entscheidung, ob ein Ereignis gesperrt werden soll. Die Synchronisierung von Ereignissen beeinträchtigt die Leistung.

Sperrnamen

Ereignissperren sind benannte Sperren. Der Name bestimmt den Umfang der Sperre. Gesperrte Ereignisse mit gleichem Namen werden synchronisiert. Dies ermöglicht Entwicklern die Synchronisierung mehrerer Ereignisse. Beispielsweise können Entwickler die Ereignisse „Einfügen“, „Aktualisieren“ und „Löschen“ für eine bestimmte Tabelle synchronisieren. Ereignisse aus verschiedenen Tabellen können sogar miteinander synchronisiert werden, wenn sie denselben Namen haben.

Wenn der Entwickler keinen Sperrnamen angibt, wird zur Laufzeit ein Standardname generiert. Der generierte Name hängt davon ab, ob es sich um ein Ereignis auf Tabellen- oder Zeilenebene handelt. Zu den Ereignissen auf Tabellenebene gehören die systeminternen Ereignisse „Filter“ und „Neu“. Zu den Ereignissen auf Zeilenebene gehören die systeminternen Ereignisse „Einfügen“, „Aktualisieren“ und „Löschen“ sowie benutzerdefinierte Ereignisse.

Bei Ereignissen auf Tabellenebene ist der Standardnamensbereich die Sperre für die Tabelle. Durch das Sperren des Filterereignisses der Tabelle wird beispielsweise sichergestellt, dass für die jeweilige Tabelle jeweils nur ein Filterereignis ausgeführt werden kann.

Bei Ereignissen auf Zeilenebene ist der Standardnamensbereich die Sperre einer Zeile. Das Sperren des Update-Ereignisses der Tabelle stellt beispielsweise sicher, dass für eine bestimmte Zeile jeweils nur ein Update-Ereignis ausgeführt werden kann. Zwei Update-Ereignisse können gleichzeitig für verschiedene Zeilen in derselben Tabelle ausgeführt werden.

Da Sperrnamen global sind, müssen Entwickler auf die korrekte Benennung von Sperrnamen achten. Verwenden Sie bei der Benennung von Sperren das folgende Muster als Grundlage:

data-source-name:table-name:event-name

Zum Beispiel:

Fulfillment:Orders:Ship

Vorsicht

Wenn zwei Ereignisse denselben Sperrnamen haben, gibt App Builder eine Warnung aus, um versehentliche Kollisionen zu vermeiden.

Sperrnamen unterstützen die Zeichenfolgeninterpolation. Bei der Zeichenfolgeninterpolation werden Werte aus der aktuellen Zeile in den Sperrnamen eingesetzt. Normalerweise werden die Primärschlüsselwerte der Zeile in den Namen eingesetzt, um zeilenweite Sperren zu erstellen.

Die Syntax für die Zeichenfolgeninterpolation lautet:

{{ Spaltenname }}

Beispiel: Der folgende Schlossname lautet:

Fulfillment:Orders:Ship:{{ Bestell-ID }}

Der Name der Laufzeit könnte etwa so aussehen:

Fulfillment:Orders:Ship:1234

Ablauf der Sperre

Sperren werden üblicherweise so lange aufrechterhalten, bis das Ereignis erfolgreich abgeschlossen ist. Wird das Ereignis nicht rechtzeitig abgeschlossen, beeinträchtigt dies die Systemverfügbarkeit. Um dies zu verhindern, verfallen Ereignissperren. Wird das Ereignis nicht innerhalb der Ablauffrist abgeschlossen, wird die Sperre aufgehoben. Beachten Sie jedoch, dass das Ereignis möglicherweise weiterhin ausgeführt wird.

Die Standardlaufzeit beträgt 10 Sekunden. Entwickler können die Laufzeit bei Bedarf ändern. Bei höheren Laufzeiten ist Vorsicht geboten.

Sperren warten

Sperren sind exklusiv: Nur ein Ereignis kann eine bestimmte Sperre gleichzeitig erhalten und halten. Andere Ereignisse, die versuchen, die Sperre zu erhalten, werden in die Warteschlange gestellt. Sie bleiben in der Warteschlange, bis sie ihrerseits die Sperre erhalten oder die Sperrwartezeit abgelaufen ist.

Die Standardwartezeit für die Sperre beträgt 10 Sekunden. Entwickler können die Wartezeit nach Bedarf anpassen. Bei einem relativ kurzen Ablaufzeitraum sollte ein Wert verwendet werden, der dem Ablaufzeitraum entspricht. Bei einem hohen Ablaufzeitraum sollte ein niedriger Wert für die Sperrwartezeit gewählt werden. Anders ausgedrückt: Wenn die Sperre voraussichtlich nur wenige Sekunden dauert, sind Benutzer in der Regel bereit, zu warten, bis die Sperre verfügbar ist. Wenn die Sperre hingegen voraussichtlich eine Minute oder länger dauert, ist es in der Regel ratsam, die Wartezeit frühzeitig zu beenden und den Benutzer zu benachrichtigen.

Wenn die Sperrwartezeit abgelaufen ist, wird dem Benutzer die Meldung „Das Ereignis wurde abgebrochen“ angezeigt.

Sperrvererbung

Ereignisse unterstützen Vererbung. Die für eine physische Tabelle definierten Validierungen und Aktionen werden von gleichnamigen Datenobjektereignissen übernommen. Ereignisse übernehmen auch die Sperrkonfiguration. Wenn das Update-Ereignis der physischen Tabelle gesperrt ist, ist auch das Update-Ereignis des Datenobjekts gesperrt.

Die Sperrvererbung gilt auch für das Save-Ereignis. Das Save-Ereignis ist kein First-Class-Ereignis. Stattdessen werden seine Validierungen und Aktionen zur Laufzeit in die Insert- und Update-Ereignisse integriert. Dadurch können Entwickler eine Regel einmalig registrieren und sie sowohl auf Inserts als auch auf Updates anwenden. Ebenso werden durch das Sperren des Save-Ereignisses die Insert- und Update-Ereignisse gesperrt.

App Builder synthetisiert zur Laufzeit ein Änderungsereignis mithilfe von Validierungen aus den Ereignissen „Einfügen“ oder „Aktualisieren“. Das Änderungsereignis wird ausgeführt, wenn ein Benutzer einen Feldwert ändert. Wenn das Ereignis „Einfügen“ oder „Aktualisieren“ gesperrt ist, ist auch das Änderungsereignis gesperrt.