Studio scheduling will be disabled - thoughts? (pending jobs)

Feedback Orchestrator
,
1

In 20.4 we’ll introduce a feature called Unattended Decoupling or, otherwise said, “breaking the robot”.

What does it mean? Suppose you have 10 machines x 10 runtimes each and 20 users. You won’t need to define anymore 200 fixed robots (userXmachine pairs) and input the password 100 times for the same user (for each 1000 machines). Instead you’ll define one machine template with 10 runtimes, 20 users and attach them to a folder. That’s all.The convention is that within a folder (which replaces the environment) any user can run/execute on any machine and the allocation is done dynamically by the Orchestrator.

This comes at a cost. The algorithm for user/machine allocation is not simple and runs on top of unattended runtimes. It will be very complicated to implement it for attended licenses therefore we’ll have to retire the scheduling and start job from Orchestrator for Studio.

Is this a big deal? For community users there is anyway one free unattended robot included and we have scheduling/reminders in tray now. Studio is made to be used in attended mode and in dev environments. For enterprise life will be simpler and machine templates/VDIs/autoscaling will run smooth.

3

Do you mean retiring the scheduling and start job activities which are in Studio?

3 Likes
4

I mean you won’t be able to create schedules or start jobs in orchestrator on top of Studio “robots”. Only Unattended and Non-Productions will support scheduling from Orchestrator. The activities stay where they are.

8 Likes
5

Hi Badita

This is very technical. Although clear to me I can see where some who are less savvy with this type of subject matter may be lost in the message. Is there a way you can explain this in more lay terms?

Chris

4 Likes
6

To be honest i think this is not a big deal, i thought we couldnt already schedule studio robots already :upside_down_face:

3 Likes
7

I’ll try to make it clearer with the technicalities. But the simple thing is: No more schedule and start job from Orchestrator on top of Studio. You will no longer use the Studio as Unattended robot.

2 Likes
8

I doesn’t really matter Never have I ever scheduled a process on a robot of type “Studio”. :robot:

Regards,
Nithin

3 Likes
9

Hey @badita

I also think it’s fine to retire unattended mode from Studio robot. It doesn’t cause any big harm as community users can use the unattended robot when they need to run with unattended features.

This sounds like a good approach!!

3 Likes
10

I think I am the only person who does not agree with such a proposal. In fact, I want the possibility to run Studio licences (with scheduling) via Orchestrator.

Could you implement this feature as an optional option? I am not really interested on this new feature - this will not apply to my case.

6 Likes
11

Hi @badita,

The convention is that within a folder (which replaces the environment) any user can run/execute on any machine and the allocation is done dynamically by the [Orchestrator](Orchestrator - Introduction).

Does this mean that we’ll no longer be able to assign a schedule to a specific Robot?
We use this feature to split the schedules between different robots.

2 Likes
12

Maybe, @badita, we should send a survey to our clients to ask their opinion on the matter, the same way we have asked the community? Maybe some clients will be impacted by this incoming change. What you think?

2 Likes
13

As I said I think the greatest solution would be (if possible) to allow the users to select the option they prefer as this can cause a crutial impact.

5 Likes
14

Yes. This is an important topic. But why would you want to do this? You have a machine available now. Why wait for a specific machine to become available. Dynamic allocation (it is proven and tested :)) increases the robot utilization.

And of course you have folders to split your deployments.

2 Likes
15

Hi @EngAnalyst. Why do you need this? What is the use case exactly?

3 Likes
16

Hello. When testing it allows me to better test real situations that will take place.

4 Likes
17

Will we still be able to run processes from Studio that works with items on a work queue in Orchestrator?

It’s not that big of a deal if one can’t schedule jobs on a Studio robot, it’s an entirely different story if one can’t work on queue items while developing…

2 Likes
18

To split high-frequency processes from others which need a guaranteed start time.
But I guess it could work with dynamic allocation also.
We already have the same setup for all machines, so it doesn’t matter on which one the process runs.

3 Likes
19

So in our dev environment we often will use one or two of the studio robots for UAT with the end user. This would mean I would have to purchase more non-prod unattended bots correct? While not a huge cost I think this could impact some of the companies with smaller bot deployments.

5 Likes
20

Yes. And you can access queues from an attended robot too.

2 Likes