If we had an Orchestrator, could we launch or plan processes within an attended robot?
A unattended robot, always need the orchestrator to launch processes inside it? Could we launch manually a process in a robot with the unattended license?
What are the main diferences in attended robots between “concurrent user” and “node locked”? If you could explain me by example.
If your attended robot is connected to Orchestrator, you can download the packages and start the Job from the robot tray. Keep in mind that you can not start a job from Orchestrator for an attended robot.
An unattended robot needs to be connected to Orchestrator to start a process. You can however use the unattended robot just like an attended one (start the process from robot tray)
3 There are several differences between concurrent and named user:
Scenario 1. 2 robots, same username, 2 different machine → only one machine can get licensed(NU), both machines can get licensed in the same time (concurrent)
Scenario 2. with NU license, everytime you add a new robot (different username for each) a license in consumed, with concurrent license you can add a infinite number of robots (different/same username) and the license is consumed only when the robot is licensed (tray is opened). Imagine you have 1 concurrent license for two employees working in shifts. First employee use the license for his robot in the first shift, when he leaves the office, he closes the tray, license is released, then comes the second employee and can use the license for his robot in the second shift.
Can you clarify something regarding concurrent runtimes?
We are on 2018.2.3, so maybe this changed in 18.4, however, we have concurrent licenses where we have a certain number of concurrent runtimes and we can add more robots than we have licenses. The problem is when we have more robots than we have runtimes, for some reason the license is being consumed even after the robot is finished running, like it doesn’t release the license to be used by another robot. So, let’s say we have 2 licenses, we create 2 robots, everything is working fine… then, we add a 3rd robot and try to run from that robot, but it goes to Pending State (even though only 1 of the 2 robots are busy)… then, later on if I try to run that 3rd robot it works as intended, but when it finishes and I try to run another robot it goes to Pending State instead, as if the license that was consumed did not release.
By the way, these robots are being used as Unattended or NonProduction. Also, the user profiles are all different and are being logged off after the job is finished. Additionally, if a user profile which consumed a license in a previous run is run again, it works fine since it still thinks the license is being consumed by that robot for whatever reason.
Let me know if you have any thoughts or if there are some known bugs like this where the runtime licenses are not being released properly.
As you can see in the attached image I have 3 machines, 2 Windows Servers with 15 robots each (ROQAWRDS20,27) and one Windows 10 machine, 1 robot (ANOPREA). Once a robot becomes available in Orchestrator it will consume 1 runtime and License status will be displayed with green. Once the maximum number of runtimes is exceeded all other new robots will be available, but the License Status will be displayed with orange, meaning that the machine is not active. In order to make an inactive machine, active, you’ll have to free a runtime (you can only do this by disconnecting an active robot or killing robot service). As you can see in my ss, starting with 18.4 we’ve added a toggle with which you can deactivate a machine in order to free runtimes for other machine(s).
The concurrency for Unattended robots is possible in case of Windows Servers with multiple robots (different usersname, same machine). In my example I have 15 robots on two Windows Servers for which I allocated 15 respectively 10 runtimes. For ROQAWRDS27 this means that only 10 robots can get licensed at a time. Saying that I start a Job on all 15 robots from ROQAWRDS27, 10 robots will get licensed and will run the job, 5 will remain in pending until the first 10 finish and then they can get licensed and run the job.
In case of ROQAWRDS20, you can see that even though I allocated 15 runtimes to that machine, at the time of my ss only 1 robot was licensed (you can see that in the “Used” column).
So, for now, this is intended behavior, not a bug.
Please let me know if you have more questions,
Andrei
Thanks, that makes sense and how I have understood it.
I think there are some bugs still when you have more robots than runtimes, when even though you have available runtime licenses the robot will still go to Pending State, and it appears intermittent. Then, also there’s a bug where the “Used” state of the robot stays as Used even though it is not running any jobs, or better yet even deleted completely. Like, for example, see this for NonProduction licenses:
No Jobs are running on any of the robots but it says 2 are Used. Then, the kicker is that it will let me run 2 robots. even though there are none available supposedly. And, like I said, how it goes to Pending State is still confusing, as shown in screenshot where I run 1 of the 3 robots from above screenshot and it went to Pending state, but the other 2 ran fine.
We are upgrading to 18.4 soon, so I will check how this works again and escalate a Support ticket if it continues to act strange.
If the robot that is pending is on the machine that has two robots, then is normal to remain in Pending
My guess for the fact that 2 are used even though no jobs are running is that you have either tray or Studio opened. Please keep in mind that the license is not released if the tray is opened. That also explains why you are able to run jobs on those robots (opened tray will not affect the start job). It also explains why the third robot remains in pending, it will not be able to get licensed since is kept by the first user.
Maybe you can find more details here Licensing that can help you understand what happens in your environment, but my guess is that what you described is due to robot tray or Studio being opened.
I don’t get how a deleted robot can remain licensed, I’ve never seen that behavior, so if you reproduce it, please open a ticket.
When the user profile is signed off, the tray is closed correct? I checked on the machine with 2 robots, and the robot of the two that ran and did not Pend, it is not currently Signed on in that machine so I don’t see how it could see it as still being licensed.
Also, here are those same robots where the other 2 finished like 10mins ago, but the first robot is still pending. And, like I said, of the 2 robots that ran good, it is not currently signed in to the machine, but the robot is still in Pending State.
This sounds strange. I have never encountered this issue. You can also try to restart the robot service and ensure that no user is signed in on that machine.
If this doesn’t work please open a ticket with all the necessary details and we’ll look into it.
Hi. From the tests I did, when you sing off from a Windows Server instance, the robot will stay connected and use a licence. This is because a Windows Server will not close the running processes for the users that logged out, including the Robot service, but only close the Interface.
So if you want to free up that licence, you need to stop the running processes and then sign out.