REST

You can execute robots as REST services, which enables you to invoke a robot from any programming language, or directly from a browser using JavaScript.

In the Repository > Robots section, from the context menu for a robot, click REST.

  • Select the method to use, GET or POST, and configure the format for the request and response. Robots that require input must be invoked using POST. Robots without input may be invoked using either GET or POST.
  • The format buttons help you configure the formats of the request and response while testing, but when you call the service from a code, the format is controlled by the Accept and Content-Type HTTP headers. The Accept header specifies the desired response format, and the Content-Type header specifies the request format.
  • Use the Request pane of the service window to construct a request. Click Test service to execute the robot. The result is then displayed in the Response pane of the window.

REST services are easily invoked from a robot by using the Call REST Web Service action.

Note If you need to use OAuth in the Call REST Web Service step in your robot, register an OAuth application and user on the OAuth page of the Management Console and use the OAuth application and user name when launching a robot using schedules in the Management Console or a REST request. All necessary information is retrieved from the registered OAuth application.

If the project or robot name contains any non-ASCII characters, make sure that the URL is encoded properly (UTF-8 URL encoding). This is automatically done in robots, but if the service is called from a code, the developer is responsible for encoding the URL.

Note Robots that run as services stop the first time the robot generates an API exception. This is different from scheduled robots, which continue to run regardless of any API exception generated by the robot.

Each robot that is run as a service uses a request thread. When a Management Console is running embedded in a RoboServer, a maximum of 100 request threads is available. These 100 threads are used for all types of HTTP requests, such as users accessing Management Console, uploads from Design Studio, and the Repository API. If you need to run a higher number of concurrent REST services, install a standalone version of Management Console on Tomcat so that you can control the number of request threads.