In Design Studio robots are grouped into projects. If you look in
the file system you will see that these projects are represented by a
folder with the only constraint that it must contain a folder named
Library, see Libraries and Projects for details.
When you build the execute request for RoboServer, you identify the robot by a robot URL, like this:
Request request = new Request("Library:/Input.robot");
Library:/ is a symbolic reference to a robot library,
in which the RoboServer should look for the robot. The
RobotLibrary is then specified on the builder like this:
There are three different robot library implementations, which one to select depends on you deployment environment.
This configures RoboServer to look for the robot in the current project folder. This folder is defined in the Settings application.
If you have multiple RoboServers you will have to deploy your robots on all RoboServers.
This robot library is not cached, so the robot is reloaded from disk with every execution. This makes the library usable in a development environment where robots change often, but not suitable for a production environment.
This library is embedded in the execute request sent to RoboServer. To create this library you must create a zip file containing the robots and all its dependencies (types, snippets and resources). This can be done the Tools->Create Robot Library File menu in Design Studio.
The library is sent with every request, which adds some overhead for large libraries, but the libraries cached on RoboServer, which offers best possible performance.
One strength is that robots and code can be deployed as a single unit, which offers clean migration from QA environment to production environment. However, if the robots change often you will have to redeploy them often.
You can use the following code to configure the embedded robot library for your request.
This is the most flexible
This library uses the Management Console's built-in repository as a robot library. When you use this library, RoboServer will contact the Management Console which will send a robot library containing the robot and its dependencies.
Caching occurs on a per robot basis, inside both Management Console and RoboServer. Inside Management Console, the generated library is cached based on the robot and its dependencies. On RoboServer, the cache is based on a timeout, so it doesn't have to ask the Management Console for each request. In addition, the library loading between RoboServer and Management Console uses HTTP public/private caching, to further reduce bandwidth.
If NewsMagazine.robot has been uploaded to the Management Console we could use the repository robot library like this when executing the robot:
This will instruct RoboServer to load the robot from a local Management Console and cache it for one minute before checking with the Management Console to see if a new version of the robot (it's type and snippets) has been changed.
addition any resource loaded through the