Fallback Procedures

2.5 Fallback Procedures

T-Plan Robot Enterprise version 2.3 introduced so-called fallback procedures. These are procedures of reserved names which are automatically called when a particular condition (event) is met. Fallback procedures are otherwise standard ones which means that all general procedure rules described above apply to it. In short, (1) the name is not case sensitive, (2) the procedure may be in another file which is linked to the script through Include or Run and (3) the procedure must be defined before the code which may call it.

  • A procedure called DisconnectFallback will be called when connection to the VNC server crashes either in the init phase (inside the Connect command) or any time later on, for example when the server is terminated (killed) or a network error is experienced. A call of the Disconnect command will not start the procedure because it is an expected connection termination. If a Connect is called in the fallback procedure body, it will not call the procedure again on failure to prevent infinite connection looping. If the connection crash is detected in the normal operation phase during script execution, the procedure gets called right after the currently executing command finishes. Be aware that the procedure may not be used in such a case for a safe recovery (meaning reconnection and resuming of the script) because the scope of data transferred to the server correctly is not known. This is a problem when the crash happens for example in the middle of text typing where it is not possible to determine how many characters were typed successfully before the connection failure.
  • A procedure called ComparisonFailureFallback gets executed every time a CompareTo or Waitfor match/mismatch fails and no explicit fail action is specified through the onfail or ontimeout parameter. The first procedure argument which may be retrieved inside the procedure body as "{1}" will always contain the numeric exit code of the calling comparison command. This is typically "1" when the object is not found or "2" when one or more of the template images are not found or can not be read.

The following example shows how to use fall back procedures. Both will simply exit the script with a specific exit code. The comparison one, in addition, creates a screenshot to allow later debugging. The example may be easily extended to perform any other suitable action, for example sending of an E-mail through the SendMail command or pausing the script through Pause.

procedure DisconnectFallback {
  Exit 3 
}

procedure ComparisonFailureFallback {
  Screenshot comparison_failure.png 
  Exit {1} 
}

// Script body
Connect localhost:1 password=welcome
Compareto button.png method=search
// ...

Version 7.2.4 introduced support of the BrowserFailureFallback procedure. When it is defined in the script it gets called after each failed Browser open/find/close command. It exposes three extra arguments:

{1} is the command numeric exit code,
{2} indicates the operation. It can be used to filter out the irrelevant calls.

    • If the failed command is "Browser open/close" it is set to "open" or "close".

    • If the failed command is "Browser find" without the "elaction" parameter specified then the argument is set to "find".

    • Otherwise the argument specifies the failed element action, one of "click", "submit", "clear", "type" or "select".

{3} contains the error message, typically the same one that is logged to the execution log.

Here's an example (requires the Chromium plugin):

procedure BrowserFailureFallback {
  Log "Failed action: {2} (exit code: {1})"
  Log "Reported error: {3}"
}


Browser "open" url="https://www.t-plan.com" browser=chromium


// This command will fail for wrong button text and call the "BrowserFailureFallback" procedure
Browser "find" class="elementor-button-text" text="Why T-Plans" timeout=5s