DataStore  - AS3 ADEP Data Services

Ist true festgelegt, werden Vorgänge, die den vom DataService verwalteten Status modifizieren, sofort übernommen. Ist false festgelegt, müssen Sie explizit die commit()-Methode aufrufen, um die Änderungen an den Server zu senden.

Der Standardwert ist true.

Ist true festgelegt, werden Änderungen an einer Sammlung sofort übernommen, wenn für die autoCommit-Eigenschaft ebenfalls true festgelegt wurde. Ist false festgelegt, werden in einer Sammlung durchgeführte Vorgänge zum Hinzufügen bzw. Entfernen nicht sofort übernommen.

Der Standardwert ist true.

Ist sowohl hier true als auch für die autoCommit-Eigenschaft true festgelegt, führt jede Eigenschaftswertänderung automatisch zu einem commit dieser Änderung. Ist false festgelegt, verursacht das Ändern der VO-Eigenschaft keinen automatischen Commit-Aufruf. Um eine Aktualisierung zu übernehmen, können Sie stattdessen explizit die commit()-Methode verwenden oder Sie können die DataManager.updateItem()-Methode aufrufen, um Änderungen nur für das Element auszuführen.

Der Standardwert ist true.

Zeigt an, ob dieser Dienst versuchen sollte, eine Verbindung zu Vorgängen herzustellen, für die eine Verbindung erforderlich ist. Vorgänge wie fill(), getItem() und count() versuchen, eine Verbindung herzustellen, wenn die Verbindung des Diensts getrennt ist und autoConnect auf true gesetzt wird. Verwenden Sie diese Eigenschaft, um das Verhalten von nicht ständig verbundenen Anwendungen zu steuern.

Wartezeit in Millisekunden zwischen Versuchen, die Verbindung zum Server herzustellen, wenn für die autoConnect-Eigenschaft true eingestellt ist.

Der Standardwert ist 5000.

Steuert wie Änderungen von anderen Clients mit der aktuellen Datenansicht dieses Clients zusammengeführt werden. Ist diese Eigenschaft „false“, werden Meldungen so lange in eine Warteschlange gestellt, bis die Anwendung die merge()-Methode ausdrücklich aufruft. Ist diese Eigenschaft true, werden Änderungen in der Reihenfolge ihres Eintreffens angewendet. Wenn bei einem Objekt des Clients ausstehende, nicht übernommene Änderungen eines Objekts vorliegen, die mit den bei der Zusammenführung übernommenen Änderungen im Konflikt stehen, wird ein Konflikt erzeugt und der Liste nicht aufgelöster Konflikte dieses Clients hinzugefügt. Sie können auf Change-Ereignisse für diese Eigenschaft warten, um benachrichtigt zu werden, wenn eine Zusammenführung angewendet werden muss.

Der lokale Cache mit Daten und Änderungen kann auf der Festplatte gespeichert werden. Ist für autoSaveCache der Wert true festgelegt, werden Daten bei jeder Änderung oder Rückgabe einer Remote-Anforderung auf der Festplatte gespeichert. Bei Problemen mit dem Speichern aufgrund von fehlendem Speicherplatz oder von verweigerten Schreibberechtigungen, wird ein FaultEvent ausgelöst oder ein Fault ausgegeben. Wird dieser Wert als false (Standardwert) festgelegt, werden keine Daten oder Änderungen auf der Festplatte gespeichert. Um das lokale Speichern der aktuellen Daten und Änderungen zu erzwingen, verwenden Sie die saveCache-Methode.

Verwandte API-Elemente

Stellt einen Zugriff auf den Cache-Bezeichner für diesen Dienst bereit. Ein Cache-Bezeichner muss vor dem Durchführen von Vorgängen festgelegt werden, für die eine Interaktion mit lokal auf der Festplatte gespeicherten Daten erforderlich ist. Ist kein Cache-Bezeichner festgelegt, werden alle Cache-Vorgänge und -Eigenschaften als inkonsistent gewertet und bei allen Vorgängen, die Daten von der lokalen Festplatte benötigen, wird ein DataServiceError ausgegeben. Diese Eigenschaft stellt einen eindeutigen „session“-Bezeichner für lokal gespeicherte Daten bereit. Ein Entwickler muss für diese Eigenschaft einen eindeutigen Wert für die Anwendung festlegen. Der Wert null oder ein leerer String gilt als nicht festgelegt.

Ermöglicht den Zugriff auf den vom DataStore verwendeten ChannelSet. Sie können das ChannelSet kann manuell erstellen und zuweisen oder es wird dynamisch erstellt, wobei die konfigurierten Channels für die destinations für diesen DataStore verwendet werden. Das ChannelSet sollte für alle DataService-Objekte identisch sein, die den gleichen DataStore verwenden.

Steuert, wann ein übernommener Batch an den Server gesendet werden soll, falls ein zweiter Batch übernommen wird, während der Client noch auf die Antwort für einen zuvor übernommenen Batch wartet. Wird der Batch sofort an den Server gesendet, können Probleme entstehen, falls Änderungen in diesem Batch von auf dem Server erstellten Änderungen bei der Übernahme des vorherigen Batchs abhängen. Beispiel: Sie aktualisieren möglicherweise ein Element, das vom Server im ersten Batch erstellt wurde. Wurde die vom Server zugewiesene ID noch nicht vom Client empfangen, wird in der Aktualisierung nicht die richtige ID für dieses Element verwendet. Wartet der zweite Batch immer auf die Fertigstellung des ersten Batchs, können Folgen zeitabhängiger Änderungen (z. B. die wiederholte Aktualisierung einer Cursorposition) mehr Zeit in Anspruch nehmen.

Der Standardmodus ist CQ_AUTO. Dieser Modus sucht nach einfachen Abhängigkeiten zwischen ausstehenden Batches und dem nächsten zu übernehmenden Batch. Wenn keine vorhanden sind, wird der Batch sofort gesendet. Wenn ein Aktualisierungs- oder Löschvorgang vorhanden ist, der von einem ausstehenden Erstellungsvorgang abhängt, wird der Aktualisierungs- bzw. Löschvorgang bis zum Abschluss des Erstellungsvorgangs zurückgestellt. Bei diesem Verfahren ist ein gewisser Aufwand erforderlich, da bei jeder Übernahme nach Abhängigkeiten gesucht wird, dennoch stellt dies normalerweise einen guten Kompromiss zwischen den beiden anderen Modi, CQ_NOWAIT und CQ_ONE_AT_A_TIME, dar.

CQ_NOWAIT wird den zweiten Batch sofort senden und nicht auf Abhängigkeiten prüfen. Möglicherweise verwenden Sie diesen Modus, wenn Sie IDs für neue Objekte auf dem Client zuweisen, wobei aus Gründen der Systemleistung Überlappungen von Batches erforderlich sein können.

CQ_ONE_AT_A_TIME wartet immer auf die Fertigstellung eines vorherigen Batchs, bevor ein neuer Batch übernommen wird. Dieser Modus vereinfacht die Fehlerverarbeitung, indem sichergestellt wird, dass der Server keinen Batch mit Änderungen empfängt, in dem Änderungen fehlen, die vom Server bei der Verarbeitung des vorherigen Batchs erstellt wurden. Außerdem wird sichergestellt, dass der Server bei Fehlern während der Verarbeitung eines Batchs so lange keinen zweiten Batch empfängt, bis die Fehler im ersten Batch auf dem Client behoben sind.

Der Standardwert ist CQ_AUTO.

Zeigt an, ob ausstehende Aktualisierungen vorhanden sind, die übernommen werden müssen.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Die Liste der Konflikte für alle verwalteten Elemente.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Zeigt an, ob der DataStore verbunden ist.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Der aktuelle Batch von Änderungen, wobei auf die Übernahme auf dem Server gewartet wird, wenn autoCommit=false verwendet wird. Sie können diese Eigenschaft verwenden, um die Änderungen zu iterieren, die angewendet werden, wenn Sie die commit()-Methode aufrufen. Ein Batch kann unabhängig von anderen Batches übernommen oder zurückgesetzt werden. Der vollständige Satz an nicht übernommenen Batches wird in der uncommittedBatches-Eigenschaft gespeichert. Der Wert der currentBatch-Eigenschaft ist immer der letzte Batch in der uncommittedBatches-Liste.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Das Ziel für diesen DataStore.

Ein Flag zum Deaktivieren der Konflikterkennung während der Aktualisierung oder der erneuten Wiederherstellung der Verbindung. In LiveCycle Data Services Version 2.6.1 wurde keine Konflikterkennung bei der Aktualisierung durchgeführt. Indem Sie hier den Wert false festlegen, können Sie das Verhalten von 2.6.1 wiederherzustellen.

Der Standardwert ist true.

Einige Implementierungen lokaler Cachespeicher unterstützen die Verschlüsselung der gespeicherten Daten. Wird dieses Flag auf „true“ gesetzt, wird die Verschlüsselung für lokale Speicher, die diese Funktion unterstützen, aktiviert.

Dieses Flag legt fest, ob die Anwendung den lokalen Speicher abfragen soll, wenn sie nicht verbunden ist. Wenn der Offline-Adapter für die Unterstützung der Ausführung einer dynamischen Abfrage konfiguriert ist, wird bei der Auslösung von fill() standardmäßig der lokale Speicher nicht abgefragt, wenn die Anwendung nicht verbunden ist. Wenn fallBackToLocalFill auf „true“ festgelegt ist, wird der lokale Speicher auch abgefragt, wenn die Verbindung zur Anwendung unterbrochen ist.

Der Bezeichner für diesen DataStore. Diese optionale Eigenschaft wird mit der Cache-Konfiguration zur eindeutigen Identifikation dieses DataStore verwendet. Dieser Wert muss sitzungsunabhängig sein. Erstellen Sie daher diesen Bezeichner nicht zur Laufzeit mithilfe einer Methode wie UIDUtil.createUID(). Wenn dieser Wert nicht zugewiesen ist, wird er auf Basis der Serverkonfigurationswerte für die verknüpften Kanäle berechnet.

Zeigt an, ob Änderungen an verwalteten Sammlungen ignoriert werden sollen, anstatt sie dem Server bei Commit-Aufruf mitzuteilen.

Zeigt an, wenn dieser DataStore initialisiert und bereit zur Verwendung ist. Diese Eigenschaft ist nur erforderlich, wenn mit einer in Laufzeit konfigurierten Anwendung oder mit einer Anwendung, die einen Zugriff auf lokal zwischengespeicherte Daten auf der Festplatte benötigt, gearbeitet wird.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Zeigt an, ob ausstehende Änderungen vorhanden sind, die zusammengeführt werden müssen.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Die Standardmeldungspriorität für die von diesem DataStore gesendeten Meldungen. Die gültigen Werte sind 0 bis 9 (wobei 0 am niedrigsten ist) und -1 bedeutet, dass der DataStore keine Priorität festgelegt hat. Beachten Sie, dass im Falle einer bereits definierten Priorität der Meldung diese einen Vorrang vor dieser Priorität hat.

Zeigt an, ob gesendete Serveränderungen zurzeit in die Client-Ansicht für verwaltete Objekte zusammengeführt werden. Dies geschieht jederzeit, wenn für autoMerge „true“ festgelegt ist. Ist autoMerge „false“, wird dies nur festgelegt, wenn Sie explizit die merge-Methode aufrufen. Dieses Flag zeigt den Unterschied zwischen Änderungen, die von einem asynchronen Server gesendet wurden, und Änderungen, die der Benutzer in den set-Methoden vorgenommen hat.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Stellt einen Zugriff auf die Anforderungszeitüberschreitung in Sekunden für einen Vorgang bereit Ein Wert, der kleiner oder gleich null ist, verhindert die Zeitüberschreitung der Anforderung.

Wenn der Client einen Fehler bei der Verarbeitung einer Meldung erhält, bewirkt der Wert true, dass die Übernahme von Batches, die zwar übernommen, aber noch nicht an den Server gesendet wurden, widerrufen wird. Wenn Sie commitQueueMode auf ONE_AT_A_TIME setzen und diese Eigenschaft als true festlegen, können Sie jeweils nur einen Batch mit Fehlern verarbeiten. Andernfalls ist es möglich, Fehler aus einer Fehlerserie zu empfangen, wodurch die Auflösung erschwert wird.

Der Standardwert ist false.

Mit diesem Zeitintervall kann die Häufigkeit der Cachespeicherung verringert werden. Wenn die autoSaveCache-Eigenschaft auf true gesetzt ist, speichert LiveCycle Data Services jede Änderung im Cache. Bei einem größeren Cache kann dies sehr aufwändig sein. Deshalb sollten Sie die Häufigkeit der Cachespeicherung verringern. Mit einer Einstellung von 1000 Millisekunden wird der Cache nur einmal pro Sekunde gespeichert.

Der Standardwert ist 0.

Ein Flag, bei dem der Wert false das Verhalten von LiveCycle Data Services 2.6 wiederherstellt: Dabei wird ein Fehler protokolliert, aber nicht ausgegeben, wenn die UID-Eigenschaft geändert wird.

Der Standardwert ist true.

Die Liste der derzeit nicht übernommenen MessageBatches. Um die Integrität der Daten zu gewährleisten, sollte im Allgemeinen die Reihenfolge der Vorgänge nicht verändert werden. Diese Liste ist daher schreibgeschützt. Um einen neuen Batch zu erstellen, rufen Sie die createBatch()-Methode auf. Dadurch wird am Ende der uncommittedBatches-Liste ein neuer Batch hinzugefügt und currentBatch wird als das letzte Element in dieser Liste festgelegt.

Diese Eigenschaften sind bindbar, sodass Sie am commitRequired-Flag in einem bestimmten Batch sehen können, ob Änderungen vorhanden sind. Durch Binden an die items-Eigenschaft erhalten Sie eine Liste von MessageCacheItems, die als Bestandteile dieses Batchs übernommen werden müssen.

Diese Eigenschaft kann als Quelle für die Datenbindung verwendet werden. Beim Ändern dieser Eigenschaft wird das propertyChange -Ereignis ausgelöst.

Normalerweise wird ein DataStore automatisch erstellt, Sie können jedoch auch einen eigenen DataStore erstellen und ihn der DataStore-Eigenschaft eines DataService zuweisen. Dazu müssen Sie sicherstellen, dass alle Datendienste, die den gleichen Datenspeicher gemeinsam nutzen, den gleichen Kanalsatz verwenden und den gleichen Wert für die use-transactions-Konfigurationseinstellung aufweisen. Verwenden Sie diesen Konstruktor, um einen DataStore zu erstellen, in dem der Zielparameter das Ziel eines DataService enthält, das den Datenspeicher verwendet. Dies wird zum Suchen des Kanalsatzes verwendet. Außerdem sollten Sie den Wert für das use-transactions-Flag für diesen Datenspeicher angeben.

Übernimmt ausstehende Änderungen für Sammlungen und Elemente, die von diesem DataStore verwaltet werden. Wenn die autoCommit-Eigenschaft als true festgelegt ist, werden Transaktionen nicht verwendet und Sie müssen diese Methode nicht aufrufen. Um Transaktionen zu verwenden, legen Sie die autoCommit-Eigenschaft als false fest und rufen diese Methode direkt auf, um einen Batch mit Änderungen zu übernehmen. Normalerweise rufen Sie nur „commit()“ ohne Argumente auf, damit alle ausstehenden Änderungen übernommen werden. Sie können zusätzliche Argumente zur Verfügung stellen, um eine Untergruppe der ausstehenden Änderungen zu übernehmen.

Sie müssen alle ausstehenden Konflikte auflösen, bevor Sie Änderungen an den Elementen im DataStore übernehmen können.

Wenn der Assembler so konfiguriert wurde, dass für use-transactions „true“ festgelegt wird, werden alle Änderungen automatisch übernommen. Wenn ein Vorgang fehlschlägt, wird keiner der Vorgänge im Batch angewendet. Wenn use-transactions als „false“ festgelegt ist, werden die Vorgänge einzeln übernommen, bis die Verarbeitung bei einem auftretenden Fehler stoppt. Alle vor dem Fehler aufgetretenen Änderungen werden angewendet, alle nach dem Fehler aufgetretenen Änderungen werden nicht angewendet. Wenn ein Fehler bei der Verarbeitung eines Batchs auftritt, werden die Änderungen in die nicht übernommene Warteschlange zurückgelegt. Sie müssen revertChanges aufrufen, wenn Sie die Änderungen entfernen möchten, die den Fehler verursacht haben.

Standardmäßig übernimmt die Commit-Methode alle ausstehenden Änderungen für alle Elemente, die für den DataStore erstellt, modifiziert und gelöscht wurden. Wenn Sie eine Untergruppe dieser Änderungen übernehmen möchten, können Sie eine Kombination von verwalteten ArrayCollection-Instanzen und/oder verwalteten Elementen festlegen, die die Untergruppe von Änderungen definieren, die im Batch enthalten sein sollen. Für jede von Ihnen festgelegte Array-Sammlung werden alle Änderungen an der Mitgliedschaft oder Reihenfolge der Elemente in dieser Array-Sammlung oder an beliebigen Elementen in dieser Array-Sammlung übernommen. Außerdem können Sie eine Liste mit einzelnen verwalteten Elementen festlegen, sodass nur Änderungen für diese Elemente übernommen werden. Wenn Sie Objekte im itemsOrCollections-Parameter festlegen, die keine verwalteten Sammlungen oder Elemente sind, wird ein DataServiceError ausgegeben.

Wenn Sie den itemsOrCollections-Parameter verwenden und Ihre Elemente Verknüpfungseigenschaften haben, die auf andere Elemente verweisen, können Sie den cascadeCommit-Parameter verwenden, um festzulegen, ob an verknüpften Elementen durchgeführte Änderungen auch im Batch enthalten sein sollen. Beispiel: Wenn Sie ein Group-Element im Elementparameter festlegen und die Group-Instanz eine Mitgliedereigenschaft hat, die auf eine Liste mit Person-Instanzen verweist, während cascadeCommit als „true“ festgelegt ist, werden Änderungen an einer Person-Instanz auch in den Satz der übernommenen Änderungen aufgenommen. Wenn cascadeCommit als „false“ festgelegt ist, werden nur Änderungen für Group aufgenommen. Verwenden Sie cascadeCommit=true, um sicherzustellen, dass alle abhängigen Änderungen im Batch enthalten sind.

Parameter

Zeigt an, ob es ausstehende Aktualisierungen für ein bestimmtes Objekt gibt, die auf die Übernahme warten.

Parameter

Erzwingt einen Verbindungsversuch dieses Dienstes mit dem Remote-Ziel. Diese Methode kann in Verbindung mit der autoConnect-Eigenschaft und der disconnect()-Methode zur Steuerung des Verbindungsstatus verwendet werden.

Übernimmt die von diesem Vorgang festgelegten Änderungen, erstellt eine neuen MessageBatch und setzt diesen Batch auf die uncommittedBatches-Liste. Bei itemsOrCollection=null werden sämtliche Meldungen im currentBatch in den neuen Batch verschoben und ein neuer Batch wird als currentBatch erstellt. Mithilfe dieser Methode können Sie einen Änderungssatz unterteilen, um einen Arbeitsblock zu markieren, der dann komplett übernommen oder zurückgesetzt werden kann. Beispiel: Wenn Sie ein übergeordnetes Objekt und ein untergeordnetes Objekt erstellen, das mit dem übergeordneten verknüpft ist, können beide Änderungen durch Aufrufen von „createBatch()“ in eine Gruppe übernehmen. Wenn Sie dies zweimal durchführen, haben Sie zwei Batches, die je ein übergeordnetes und ein untergeordnetes Objekt erstellen. Danach können Sie jede Änderungsgruppe unabhängig übernehmen. Die Gruppen müssen allerdings in der Reihenfolge übernommen werden, in der die Batches erstellt wurden. Sie könnten auch den aktuellsten Batch wiederherstellen. In diesem Fall bleibt der erste Batch unverändert. Auf diese Weise können Sie ein einfaches System zum Rückgängigmachen von Vorgängen implementieren: Nach jedem Vorgang wird createBatch(null) aufgerufen.

Mithilfe der MessageBatch-Eigenschaft (oder des propertiesArguments für diese Methode) können Sie einen Batch mit einem Satz benutzerdefinierter Eigenschaften markieren. Diese Informationen werden mit dem Batch gespeichert und wiederhergestellt, wenn die Offline-Funktion verwendet wird. Mithilfe dieser Informationen kann der Batch auf dem Client identifiziert werden. Darin platzierte Werte müssen serialisierbar sein (d. h. Objekte oder Klassen mit [RemoteClass]).

Wenn Sie einen Wert für einen itemsOrCollection-Parameter angeben, wird ein neuer Batch erstellt, der nur die Änderungen für das Element oder die Elementesammlung aufweist. Wenn Sie für cascadeCommit „true“ festlegen, werden auch alle Änderungen für verknüpfte Elemente in den Meldungssatz aufgenommen, der dem neuen Batch zugeteilt wird.

Parameter

Zwingt alle Datendienste, die diesen Datenspeicher verwenden, zum Trennen der Verbindung.

Diese Methode füllt die festgelegte ListCollectionView mit allen zuvor in der Anwendung verwendeten Cache-Bezeichnern.

Parameter

Initialisiert den DataStore, wobei die Initialisierung von Metadaten aller hinzugefügten ConcreteDataService-Instanzen berücksichtigt wird. Beim erfolgreichen Abschluss oder beim Fehlschlagen wird der entsprechende Rückruf ausgelöst. Wenn der Datenspeicher schon initialisiert ist, wird der erfolgreiche Rückruf sofort ausgelöst. Die Rückrufe müssen parameterlose Funktionen sein.

Parameter

Melden Sie den Benutzer vom aktuellen Ziel ab. Durch Aufrufen dieser Methode werden alle verknüpften DataService-Instanzen abgemeldet.

Führt ausstehende Aktualisierungen in den verwalteten Objektsatz zusammen. Der Prozess der Änderungszusammenführung kann Konflikte erkennen.

Ruft alle auf dem Client verwalteten Daten erneut ab.

Gibt alle auf dem Client verwalteten Daten frei. Das Element wird freigesetzt und alle Daten werden in den Abfrage-Caches des Clients abgefragt. Das Abonnement für automatisch synchronisierte Daten vom Server wird aufgegeben.

Parameter

Stellt den vorherigen Zustand für alle ausstehenden (nicht übernommenen) Änderungen für alle DataServices wieder her, die von diesem DataStore verwaltet werden.

Stellt den vorherigen Zustand für alle ausstehenden (nicht übernommenen) Änderungen an Elementen in der angegebenen verwalteten Sammlung wieder her.

Parameter

Legt die Benutzerinformationen für dieses DataStore-Ziel fest.

Parameter

Legt die Benutzerdaten für Dritte des DataStore-Ziels fest.

Parameter

Wird ausgelöst, wenn ein Konflikt entweder zwischen ausstehenden Änderungen auf diesem Client und den von einem anderen Client gesendeten Änderungen erkannt wird oder wenn aufgrund der von diesem Client übermittelten Änderungen ein Konflikt am Remote-Ziel erkannt wird. Der DataStore löst Konfliktereignisse für alle Ziele aus, die den DataStore gemeinsam nutzen. Sie können auch in einem DataService auf Konfliktereignisse für einen festgelegten Typ warten. Verwenden Sie den DataStore für Objekte mit Verknüpfungen, da in diesem Fall die Konflikte möglicherweise in einer festgelegten Reihenfolge aufgelöst werden müssen, damit die Integrität dieser Verknüpfungen erhalten bleibt.

Die Eigenschaften des Ereignisobjekts haben die folgenden Werte:

Das FaultEvent.FAULT-Ereignis wird ausgelöst, wenn der Commit-Aufruf einen Fehler zurückgibt.

Die Eigenschaften des Ereignisobjekts haben die folgenden Werte:

Das ResultEvent.RESULT-Ereignis wird ausgelöst, wenn der Commit-Aufruf erfolgreich zurückgegeben wird.

Die Eigenschaften des Ereignisobjekts haben die folgenden Werte:

Legt fest, dass auf einfache Abhängigkeiten zwischen ausstehenden Batches und dem nächsten zu übernehmenden Batch geprüft werden soll.

Legt fest, dass der zweite Batch sofort und ohne Prüfung auf Abhängigkeiten gesendet werden soll.

Legt fest, dass auf die Fertigstellung eines vorherigen Batchs gewartet werden soll, bevor ein neuer Batch übernommen wird.