Übersicht
Wenn Sie ein Abspielen starten, sendet Testimony eine Reihe von Hintergrundprozessen an das zentrale System. Es ist wichtig, dass auf dem Zentralsystem genügend Hintergrund-Workprozesse zur Verfügung stehen, um den Anforderungen von Testimony gerecht zu werden, und dass genügend Hintergrund-Workprozesse für den normalen Betrieb verfügbar bleiben. (Dies gilt insbesondere, wenn Ihr zentrales System auch ein produktives Solution-Manager-System ist) Die normale Anforderung ist ein Hintergrundjob für jeden Bot plus ein zusätzlicher Hintergrundjob zur Verwaltung des Abspielens. Wie dies im Einzelnen funktioniert und von Testimony verwaltet wird, wird im Folgenden beschrieben.
Detaillierte Informationen
Wenn ein Abspielen zum ersten Mal ausgeführt wird, startet ein Orchestrator-Job. Der Orchestrator verwaltet den gesamten Abspielprozess und hat unter anderem die Aufgabe, das Abspielen in Blöcke aufzuteilen. Sobald die Abspielblöcke erstellt sind, startet der Orchestrator eine Reihe von Worker-Jobs. Die Anzahl der Worker-Jobs, die gestartet werden, wird durch den allgemeinen Testimony-Parameter PLAYBACK_MAX_BLOCKS bestimmt. Die Anzahl der Worker-Jobs (und damit der Wert des Parameters PLAYBACK_MAX_BLOCKS) sollte auf die Anzahl der von Ihnen verwendeten Bots eingestellt werden.
Sobald diese Jobs gestartet wurden, weist der Orchestrator den Worker-Jobs Blöcke zur Verarbeitung zu. Jeder Worker-Job arbeitet sich dann durch die Skripte in seinem Block und weist sie den Bots zum Abspielen zu. Sowohl der Orchestrator-Job als auch die Worker-Jobs bleiben für die gesamte Dauer des Abspielens aktiv.
Das bedeutet, dass die Gesamtzahl der von Testimony für ein Abspielen auf dem zentralen System benötigten Aufträge PLAYBACK_MAX_BLOCKS + 1 beträgt.
Die Aufträge sind in SM37 wie unten dargestellt zu sehen.
Der Orchestrator-Job heißt /BTI/AUT_EXEC_QUEUE_PLAY, und die Worker-Jobs erhalten einen dynamisch generierten Namen.
Hinterlasse einen Kommentar.