Anhalten eines Prozesses:

A process can either be stopped through Soft Stop or Kill commands.

Befehl „Soft Stop“

Der Befehl Soft Stop markiert den Prozess in einem Status zum Anhalten.Dieser Status kann aus dem noch laufenden Workflow mit der Aktivität Should Stop abgefragt werden. Der Workflow sollte diesen Status explizit behandeln und fertigstellen.Der Workflow wird nicht automatisch angehalten, ohne den Status zum Anhalten zu behandeln.Unter REFramework finden Sie ein Szenario, das Soft Anhalten nutzt.

The Stop command is designed for unattended automations and is available only in Orchestrator. In Orchestrator, the Soft Stop command is named 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 anhalten.

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

Während eines Try-Catch-Workflows kann der Transaktionsstatus als erfolgreich angezeigt werden, wenn ein Prozess angehalten wird, obwohl er tatsächlich 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 Kill-Befehl vom Roboter empfangen wird, versucht er zunächst, den Prozess abzubrechen und zum Finally-Block zu springen.Wenn die Logik im Finally-Block nicht innerhalb von maximal 30 Sekunden nach Erhalt des Befehls Abbrechen abgeschlossen ist, wird die gesamte Ausführung beendet und der Gesamtprozess ist in den Protokollen erfolgreich, da im Catch-Block keine Fehler aufgezeichnet wurden, seit 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.