On the Repository>Robots tab you can find a column named REST. Clicking this column will bring up a window that allows you to test your robot as a service.
The left-hand side of the service window allows
you to construct a request. You then click the
Service button in the upper right corner to execute the
robot. The result is then displayed in the right-hand side of the
The format buttons allow you to configure the formats of the request and responses while testing, but when you call the service from code, the format is controlled by the Accept and Content-Type HTTP headers. The Content-Type header specifies the request format, and the Accept header specifies the desired response format.
Robots that require input must be invoked using POST. Robots without input may be invoked using either GET or POST.
REST services are easily invoked from a robot by using the Call REST Web Service action.
If the project or robot name contains any non-ASCII characters, you have to 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 code, the developer is responsible for encoding the URL.
Note: Robots run as services will stop the first time the robot generates an API exception. This is different from scheduled robots which will continue to run regardless of any API exception generated by the robot. You should think of REST services as something short-lived, like a Google search or translating a sentence.
Each robot that is run as a service uses a request thread. When the Management Console is running embedded in a RoboServer, there is a maximum of 40 request threads. These 40 threads are used for all types of HTTP requests, such as users accessing the Management Console, uploads from Design Studio, and the Repository API. If you need to run a higher number of concurrent REST services, you will need to install a standalone version of the Management Console on Tomcat so that you can control the number of request threads.