RemoteControl

T-Plan Robot Enterprise Remote Control

Contents:

1. Overview
2. Setup
3. Usage
4. Improvements

1. Overview

The Remote Control (RC) is a standalone tool supported since T-Plan Robot Enterprise v3.5. It allows to control test scripts executing in a local or remote Robot instance. Supported operations:

  1. List test script(s) and schedule(s) executing in the Robot instance,
  2. Start a test script or schedule (since RC v2 and Robot 4.0.1)
  3. Pause a test script or a schedule,
  4. Resume a test script or a schedule,
  5. Stop a test script or a schedule,
  6. Kill the server (since RC v2 and Robot 4.0.1)

The communication is performed over a TCP/IP connection where Robot runs the server and the tool acts as a client. As the protocol is text based one can connect to the server also for example through telnet.

2. Setup

T-Plan Robot Enterprise

The T-Plan Robot Enterprise instance must be version 3.5 or higher (RC v1.0) or 4.0.1 and higher (RC v2.0). To start the Remote Control Server start Robot with the --remotecontrol option. The port number may be optionally specified after the option, for example --remotecontrol 5556. If the port is omitted the server starts on the default port of 5899. Make sure that the target port is not occupied or blocked by the firewall.

Since Robot 4.0.1 the server may be started in the CLI mode through a combination of --remotecontrol and -n/-nodisplay. It avoids starting the GUI which minimizes the resource requirements and provides the best performance. This mode is recommended for deployment scenarios.

Remote Control Tool

Download the tool from:
http://www.t-plan.ltd.uk/releases/robot/plugins/remotecontrol_v2.zip

The tool requires Java SE 1.6 (JRE or JDK). The steps below presume that the Java executable is on the system path. This can be verified through the steps described in the Java Requirements chapter of the Robot's Release Notes. If Java is not on the system path replace the java call with a full path to the java.exe (Windows) or java (Unix/Linux) binary, for example "C:\Program Files\Java\jdk1.6.0_<version>\bin\java.exe". To install the tool simply unzip the downloaded ZIP archive to the hard drive.

3. Usage

To start the tool change to the tool directory and execute:

java -jar remotecontrol.jar [OPTIONS] [COMMAND]

or start one of the provided scripts (requires Java on the system path):

MS Windows:remotecontrol.bat [OPTIONS] [COMMAND]
Unix/Linux:./remotecontrol.sh [OPTIONS] [COMMAND]

OPTIONS:

-h, --host [hostname]

the host name to connect to (optional, defaults to localhost)

-p, --port [port]

the port number to connect to (optional, defaults to 5899)

--help

displays help on the usage and options

The COMMAND is optional. It may be a single command to be executed, for example "pause". When no command is specified the tool starts an interactive prompt similar to telnet. Supported commands:

bye

close the connection and exit the session

start [FILE] [OPTIONS]

start the specified test script or schedule and do not wait for it to finish. Supported since RC v2 and Robot 4.0.1

execute [FILE] [OPTIONS]

same as start but wait for the script/schedule to finish. Supported since RC v2 and Robot 4.0.1. If the session gets killed externally it won't stop the remote script/schedule execution. To stop it open a new session and call the stop command.

pause [NAME]

pause the specified or currently executed script or schedule

resume [NAME]

resume the specified or currently paused test script or schedule

stop [NAME]

stop the specified or currently executed script or schedule

list

list the currently executing test scripts and/or schedules

kill-server

shut down the server. Supported since RC v2 and Robot 4.0.1. If the server runs in the CLI mode (Robot was started withthe n/-nodisplay option) the command will kill the whole Robot process.

help

display help on commands

The term of "executing test script" refers to one script started through the Java API, through the r/-run CLI option, manually by clicking the Execute button in the GUI or through the start/execute RC commands. Subscripts started using the Run command do not apply, they are not being listed and they can not be controlled separately from the calling script. The FILE parameter specifies the full script or schedule path on the Robot machine. If the path contains spaces it must be enclosed in double quotes ("). The OPTIONS are optional and may consist of one or more script related CLI options such as v/var, -c/connect and -p/-password. The NAME parameter is optional and may be one of the following:

  1. The thread ID (name) assigned to the automated testing thread in the call of one of the createAutomatedRunnable() methods. The thread ID is displayed in the list command output. This attribute has the highest search priority and allows to differentiate among multiple executions of the same test script typical for multithreaded test script executions (load testing).
  2. The full script file path, for example C:\MyAutomation\tpr\Script1.tpr
  3. The script file name, for example Script1.tpr. If there are more executing test scripts of the same file name the command will be applied to the one that started as the first one.

If the NAME parameter is omitted and the target Robot instance executes just one text script the operation will be applied to it. If there are two or more executing test scripts and NAME is not specified the server reports an error and does nothing.

EXAMPLES:

Connect to the locally running T-Plan Robot Enterprise on the default port of 5899:

java -jar remotecontrol.jar

Connect to T-Plan Robot Enterprise running on address red.fox.com:5222, pause the currently executing script and close the session:

java -jar remotecontrol.jar -h red.fox.com -p 5222 pause

Connect using telnet to the locally running T-Plan Robot Enterprise on the default port of 5899:

telnet localhost 5899

Connect using telnet to T-Plan Robot Enterprise running on address red.fox.com:5222:

telnet red.fox.com 5222

4. Improvements

The following improvements may be delivered in the future versions. Contact our support to raise the priority.

  • Securing the TCP/IP connection through SSL
  • Allow limited access through IP/hostname filtering
  • Starting of the server from a test script