Ereignisparallelität und Sperren im Jitterbit App Builder

Parallelität und Sperren

Standardmäßig werden Ereignisse gleichzeitig ausgeführt. Wenn zwei Benutzer gleichzeitig auf dieselbe Schaltfläche klicken, können sich die Ereignisausführungen überschneiden. In manchen Situationen kann es notwendig sein, Ereignisse zu synchronisieren. Synchronisierte Ereignisse werden seriell ausgeführt, sodass sichergestellt ist, dass immer nur ein synchronisiertes Ereignis ausgeführt wird. Nicht synchronisierte Ereignisse können auch bei synchronisierten Ereignissen 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.

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 im Ereigniskonfigurationsbildschirm verfügbar, indem Sie auf Edge Case klicken.

Sperrnamen

Ereignissperren sind benannte Sperren. Der Name bestimmt den Umfang der Sperre. Gesperrte Ereignisse mit demselben Namen werden synchronisiert. Dadurch können Entwickler mehrere Ereignisse synchronisieren. 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 bei dem Ereignis um ein Ereignis auf Tabellenebene oder ein Ereignis auf Zeilenebene handelt. Zu den Ereignissen auf Tabellenebene zählen die intrinsischen Ereignisse „Filter“ und „New“. Zu den Ereignissen auf Zeilenebene zählen die intrinsischen Ereignisse „Insert“, „Update“ und „Delete“ 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 angegebene Tabelle jeweils nur ein Filterereignis ausgeführt werden kann.

Bei Ereignissen auf Zeilenebene ist der Standardnamensbereich die Sperre für eine 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önnten gleichzeitig für verschiedene Zeilen in derselben Tabelle ausgeführt werden.

Da Sperrnamen global sind, müssen Entwickler darauf achten, dass die Sperrnamen richtig benannt werden. Sie können beim Benennen von Sperren das folgende Muster als Grundlage verwenden:

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

Zum Beispiel:

Fulfillment:Orders:Ship

Sperrnamen unterstützen String-Interpolation. String-Interpolation ersetzt Werte aus der aktuellen Zeile durch den Sperrnamen. Normalerweise werden die Primärschlüsselwerte der Zeile durch den Namen ersetzt, um zeilenbezogene Sperren zu erstellen.

Die Syntax für die String-Interpolation lautet:

{{ Spaltenname }}

Beispiel: Der folgende Schlossname lautet:

Fulfillment:Orders:Ship:{{ Bestell-Nr. }}

Der Laufzeit könnte etwa wie folgt aussehen:

Fulfillment:Orders:Ship:1234

Ablauf der Sperre

Normalerweise werden Sperren aufrechterhalten, bis das Ereignis erfolgreich oder nicht abgeschlossen ist. Wenn das Ereignis nicht rechtzeitig abgeschlossen wird, wirkt sich dies auf die Verfügbarkeit des Systems aus. Um dies zu verhindern, verfallen Ereignissperren. Wenn das Ereignis nicht innerhalb der Ablauffrist abgeschlossen wird, wird die Sperre aufgehoben. Beachten Sie jedoch, dass das Ereignis möglicherweise weiterhin ausgeführt wird.

Die Standardablaufdauer beträgt 10 Sekunden. Entwickler können die Ablaufdauer nach Bedarf ändern. Bei höheren Ablaufwerten 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 die Sperre ihrerseits erhalten oder bis die Sperrwartezeit abgelaufen ist.

Die Standardwartezeit für die Sperre beträgt 10 Sekunden. Entwickler können die Wartezeit nach Bedarf ändern. Wenn die Ablaufzeit relativ niedrig ist, sollten Sie einen Wert verwenden, der der Ablaufzeit entspricht. Wenn die Ablaufzeit hoch ist, sollten Sie einen niedrigen Wert für die Sperrwartezeit verwenden. Mit anderen Worten: Wenn die Sperre voraussichtlich nur einige Sekunden hält, sind Benutzer normalerweise bereit, zu warten, bis die Sperre verfügbar ist. Wenn die Sperre hingegen voraussichtlich eine Minute oder länger hält, ist es normalerweise vorzuziehen, die Wartezeit frühzeitig zu beenden und den Benutzer zu benachrichtigen.

Wenn die Sperrwartezeit abgelaufen ist, wird dem Benutzer eine Warnmeldung angezeigt: „Das Ereignis wurde abgebrochen“:

Sperrvererbung

Ereignisse unterstützen Vererbung. Die für eine physische Tabelle definierten Validierungen und Aktionen werden von Datenobjektereignissen mit demselben Namen geerbt. Ereignisse erben 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 einmal registrieren und sie sowohl auf Einfügungen als auch auf Aktualisierungen anwenden. Ebenso werden durch das Sperren des Save-Ereignisses die Insert- und Update-Ereignisse gesperrt.

App Builder synthetisiert zur Laufzeit ein Änderungsereignis unter Verwendung von Validierungen aus den Einfüge- oder Aktualisierungsereignissen. Das Änderungsereignis wird ausgeführt, wenn ein Benutzer einen Feldwert ändert. Wenn das Einfüge- oder Aktualisierungsereignis gesperrt ist, wird auch das Änderungsereignis gesperrt.