Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

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:

  1. Severity of an error to trigger termination the script can be configured via abort.result.status
  2. 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.

  • No labels