Worker[].Type*

Typ der auszuführenden Worker-Instanz:

Der Typ All kann genutzt werden, wenn 3 gleiche Instanzen definiert werden sollen, die sich nur im Typ unterscheiden. Das Programm erstellt für jeden Worker vom Pseudo-Typ All implizit 3 Instanzen, die jeweils den Typ Input, Process und Output haben. Alle anderen Eigenschaften der Instanzen sind identisch. Eine Ausnahme stellt die Eigenschaft .Name dar. Um diese Eigenschaft für die 3 Typen unterscheidbar zu machen, obwohl die Eigenschaft nur einmal definiert ist, kann die Variable %Type% in den Wert eingebunden werden. Die Variable wird zur Laufzeit durch die tatsächliche Typbezeichnung ersetzt.

Der Wert None dient zur (temporären) Deaktivierung eines Workers. Auf diese Weise muss nicht das gesamte Objekte inklusive dessen Eigenschaften aus der Konfiguration gelöscht werden, um den Worker zu deaktivieren.

Worker[].Tenant

Name des Mandanten, für den die Worker-Instanz ausgeführt wird

Standardwert: Default

Worker[].Name

optionaler Name der Worker-Instanz

Dieser Name wird für die Anzeige im Logging und im Statusmonitor genutzt. Die Variable %Type% ermöglicht das dynamische Einfügen des tatsächlichen Worker-Typs. Dies ist relevant bei der Verwendung des Worker-Typs All (siehe Worker[].Type*).

Worker[].Timer

individuelle Ausführungszeiten für die Worker-Instanz

Syntax: siehe Verschiedenes

Alternativ wird der Wert herangezogen, der unter Timer.Worker global definiert ist.

Innerhalb eines Durchlaufes ermittelt eine Worker-Instanz einmalig alle Stapel oder Dokumente, die zu diesem Zeitpunkt für die Worker-Instanz zur Verarbeitung anstehen. Die Worker-Instanz verarbeitet diese Stapel oder Dokumente nacheinander in der gefundenen Reihenfolge. Alle Objekte, die seit der Ermittlung neu hinzugekommen sind, werden erst im nächsten Durchlauf berücksichtigt.

Worker[].ConfigSource[]*

Verweis auf die Konfigurationsdatenquellen der Szenarien, die die Worker-Instanz verarbeitet

Syntax: URI-Syntax, siehe Datenformat und Datenquellen.

Welche Zuordnung von Szenarien zu Worker-Instanzen sinnvoll ist, hängt vom konkreten Anwendungsfall ab. Innerhalb einer Programminstanz von xSuite Interface können mehrere Worker-Instanzen des gleichen Typs und für den gleichen Mandanten parallel am selben Szenario arbeiten, um dadurch eine Erhöhung des Durchsatzes zu erzielen. Dies kann aber kontraproduktiv sein, wenn sich die parallel laufenden Instanzen aufgrund knapper Ressourcen gegenseitig blockieren, z. B. beim gleichzeitigen Zugriff auf die Verwaltungs­datenbank. Alternativ können mehrere Programminstanzen, auch auf unterschiedlichen Rechnern, parallel an denselben Szenarien arbeiten, solange diese dieselben Datenbank- und Storage-Ressourcen nutzen.

Eine generelle Einschränkung für die parallele Ausführbarkeit gilt beim Input-Worker. Für den Input-Worker sind keine mehrfachen Instanzen zulässig, die das gleiche Szenario für den gleichen Mandanten verarbeiten. Dadurch sollen mögliche Konflikte beim gleichzeitigen Zugriff auf dieselben Eingabedaten vermieden werden.

Als Gegenstück zur Parallelausführung kann eine Worker-Instanz auch Daten mehrerer Szenarien verarbeiten. Innerhalb eines Timer-Durchlaufs findet die Verarbeitung dann sequenziell in der Reihenfolge statt, in der die Szenarien dem Worker zugeordnet sind.