Anhalten eines Prozesses:

Ein Prozess kann entweder über die Befehle Soft Stop oder Kill angehalten werden.

Befehl „Soft Stop“

Der Befehl Soft Stop markiert den Prozess im Status Soll anhalten. Dieser Status kann vom noch ausgeführten Workflow mithilfe der Aktivität Should Stop abgefragt werden. Der Workflow sollte diesen Status explizit behandeln und beenden. Der Workflow wird nicht automatisch gestoppt, ohne den Status Soll anhalten zu behandeln. Ein Szenario, das Soft Stop nutzt, finden Sie unter REFramework.

Der Befehl Stop ist für unbeaufsichtigte Automatisierung konzipiert und nur im Orchestrator verfügbar. Im Orchestrator heißt der Befehl Soft Stop nur Stop.

Befehl „Kill“ (Beenden)

Der Befehl Kill sendet zuerst eine Anforderung zum Abbrechen an den Workflow. Die Workflow-Anforderung zum Abbrechen unterscheidet sich von Soll anhalten. Abbrechen ist ein Workflowsignal, das automatisch vom Workflow verarbeitet wird. Das Signal bewirkt, dass die Aktivitäten kaskadiert abgebrochen werden, während Finally-Blöcke des Workflows Bereinigungsschritte ausführen können. Wenn das Signal Abbrechen den Workflow nicht innerhalb von drei Sekunden anhält, wird der Auftrag beendet, indem alle laufenden Aktivitäten an einem beliebigen Punkt ihrer Ausführung zwangsweise gestoppt werden.

Der Befehl Kill wurde für Attended-Automatisierung entwickelt und ist im Orchestrator und in Desktop-Clients und APIs wie Assistant, Studio und RobotJS verfügbar. In Desktop-Clients heißt der Kill-Befehl Stop.

Das REFramework-Prozessszenario

REFramework nutzt den Befehl Soft Stop.

Wenn ein Prozess gestoppt wird, wird der Block, der die Fehlerlogik enthält, übersprungen und der letzte Block ausgeführt. Dadurch bleiben die Werte für BusinessError und SystemError gleich null und der Prozessstatus wird insgesamt als erfolgreich betrachtet. Das beschriebene Verhalten ist beabsichtigt.

Try-Catch-Szenario

Wenn ein Prozess während eines Try-Catch-Workflows gestoppt wird, kann der Transaktionsstatus als erfolgreich angezeigt werden, auch wenn er in Wirklichkeit nicht abgeschlossen wurde.

Abbrechen eines Prozesses

Wenn sich die Ausführung im Try- oder Catch-Block befindet, wenn der Befehl Abbrechen vom Roboter empfangen wird, springt er zum Finally-Block der nach Fehlern sucht. Wenn keine Fehler gefunden werden, denkt der Finally-Block, dass die Ausführung erfolgreich abgeschlossen wurde, da keine Fehlerereignisse vorhanden sind (sie sind leer).

Abbrechen eines Prozesses

Wenn sich die Ausführung im Try- oder Catch-Block befindet, wenn der Befehl Beenden vom Roboter empfangen wird, versucht er zunächst, den Prozess abzubrechen und springt zum Finally-Block. Wenn die Logik innerhalb des Finally-Blocks seit dem Empfang des Befehls Abbrechen in 3 Sekunden nicht beendet ist, wird die gesamte Ausführung beendet, und der gesamte Prozess ist in den Protokollen erfolgreich, da keine Fehler im Catch-Block aufgezeichnet wurden, weil er übersprungen wurde.

Vermeiden von falsch positiven Ergebnissen

• Das Festlegen des Prozessstatus auf Successful sollte nur innerhalb des Try-Blocks erfolgen, nachdem die Geschäftslogik abgeschlossen ist.
• Das Festlegen des Status auf Failed darf nur innerhalb des Catch-Blocks erfolgen, nachdem die Logik zur Fehlerbehandlung abgeschlossen ist.
• Im Finally-Block sollte nur Bereinigungslogik vorhanden sein, da sie unabhängig davon ausgeführt wird, ob die Ausführung erfolgreich war oder nicht.

Stellen Sie sicher, dass die Fehlerlogik ausgeführt wird

Wenn der Block, der die Fehlerlogik enthält, übersprungen wird, werden die Werte für BusinessError und SystemError null bleiben, und der Gesamtprozessstatus gilt als successful, da keine Fehler aufgezeichnet wurden.