A session is the result of browsing on a website, and consists of the page, the page URL and the cookies and authentications obtained in the course. However, obtaining a session where the wanted information is easily reached can require a number of navigation steps such as logging in.
If a robot is run frequently enough, and the response time needs to be very small, getting to a suitable session in the robot can require more time than is available. However, if the session could be obtained once, and then shared between robots and robot runs then great time savings could be achieved. This is exactly what session reuse provides by the means of a session pool.
There are two step actions used for session reuse:
The Save Session action, which saves a session in the session pool or a variable.
The Restore Session action, which restores a session from the session pool or a variable.
In order to restore a session from the session pool, it is necessary to identify it. A session is identified by a site name, a username and a password.
Let's look at an example. Assume that we have a robot that logs in to a web site, collects some data and returns this. However, the data that we seek to collect is distributed over many linked pages, e.g. with a next page link. We want the first invocation of the robot to log in to the site and return the data of the first page, and each subsequent invocation should then return a new chunk of the data (the next page). So what we want is to share the session of a logged-in user between robot invocation, but we also want to remember how much of the data we have returned. The robot could look something like this:
When the robot is called, it will first try to restore a session from an input variable, and if one exists that session will be used and the next step will click on a next page link to get a fresh page of data. If no session is passed to the robot, the step will fail, and the second alternative will be executed, which does the logging in and also navigates to the relevant page on the site where the data may be found.
If the robot execution gets through one of the two alternative branches it reaches the Save Session step. This will save the session so that it may be used the next time the robot is called. But for this to be possible, we need to return the session to the caller of the robot. This is handled by the Return Session step which is a normal Return Value step that returns the value of a variable containing the session, i.e. the variable is of a type which has an attribute of attribute type Session in which our Save Session step stored the session. Finally if the robot reached the end of the data, that is, there is not a next page link on the page, then the Click Next set will produce an error. This will be ignored by the robot, because we will set Error Handling to Skip Following Steps, but if we have a check mark in API exception then the caller would get an exception, e.g. if the robot is called from Java, it can use this to know that the end of data has been reached.
After the session has been saved, the remaining steps of the robot will extract the data from the page, e.g. by looping over a table and returning a value for each row.
The session pool optimization could also be used in the case where you have several robots that log in to the same site and perform different tasks. If the log in process is time consuming, and the robots are called many times to do simple tasks, it may be a good idea to save the session after log in and then reuse it. The figure below shows a blueprint of a session reusing robot. It can be seen that any such robot that does not have a valid session will perform a log in and return the saved session for other robot to reuse. A robot should normally never rely on a session being available, but always provide a fallback for obtaining a session.
In Design Studio, it is important to understand a bit about the inner workings of the session pool if you want to utilize it. This is because the execution of a robot in Design Studio is not controlled by the natural flow of a robot run, but by the user interaction. First a session should be stored by executing the step containing the Save Session action. Selecting the step following the Save Session step does this. After this the Restore Session action will be able to pick up the stored session. Saved sessions will remain in the session pool even if you refresh the cache by clicking the icon, or after loading different robots. There is currently no way to remove a session from the session pool besides restarting Design Studio.