Finally Step and Script Termination
Introduction
EEM scripts provide functionality to control execution logic depending on the result status of particular messages. In detail there are two ways to control the logic:
- Severity of an error to trigger termination the script can be configured via
abort.result.status
- Even if the severity above would lead to immediate script termination a step in the script can be configured to execute anyway. This approximates the behavior of a finally block in exception handling for Java and other programming languages.
Both features are described in the following.
abort.result.status
- Configure Script Termination
Errors in script execution are categorized into the following classes:
Level |
Name |
Description |
Example |
---|---|---|---|
2 |
RESPONSE_CHECK_FAILED |
response content different than expected |
|
3 |
RESULT_PROTOCOL_ERROR |
server reports a problem |
HTTP status code 4xx, 5xx |
4 |
FAILED |
execution failed |
failed to contact server |
5 |
INTERNAL_ERROR |
unexpected error |
internal exception, hung execution |
By default an error of level 4 leads to termination of the script execution. This behavior can be adapted by setting the script configuration parameter {{abort.result.status}}to a different value.
Example: abort.result.status=2
would terminate script execution as soon as a single response check fails.
Finally Step
In some cases it is required to terminate a script due to an error, but still a proper logout should be attempted. For this purpose a step can be marked as finally step. In that case a step is executed if one of the selected target result statuses is selected. Recommended use is to select all statuses:
The special step attribute finally can be reverted by using the context menu item Recover finally Step to Common Step.
Example
Consider the example below in the screenshot:
- the script is configured with
abort.result.status=2
, leading to termination as soon as a response check fails - message triggerSomeError executes ok (http status code 200)
- The response check for message triggerSomeError fails because a representative text is contained or not contained in the response. Script execution will be terminated because of
abort.result.status=2
. - Messages 4 and 5 are skipped because of script termination
- Message 2 in step FinallyStep is still executed because this step is marked as finally step. (Note: This finally attribute is not directly visible in the UI. The name of the step is NOT relevant. You can check explicitly in the source view.
Execution where step FinallyStep is NOT marked as finally:
Execution where step FinallyStep is marked as finally:
Real Usage Scenario
One use case is to terminate script execution for a script that tries to update some business objects but fails to acquire a lock on this object - e.g., because a concurrent script execution on a different robot already owns this lock. Reaction might be to cancel script execution but still log out the user.