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

Feedback Orchestrator
,
42

Im really curious of how many people were actually scheduling their processes to run on the studio robot, none of my customers ever needed that, and CE users still have free licenses to not need to do that as well…

2 Likes
43

For the past 3 years I don’t think I have ever added schedule to Studio Robot - I have always treated as decoupled from actual robots so can see no issue with removing that functionality.

2 Likes
44

Thanks’s for letting me know this as this is against the license i didn’t knew this.

1 Like
45

The only problem I see is that if development is done on a remote machine against an test-orchestrator and you wish to leave the development phase process running a large number of test-cases for example during the night. → Corner case I admit and not the biggest problem over 95% of the times.

Mostly we use studio to pre-run processes on the production machine in rollout sessions to confirm that everything is working fine in production environment.
So to recap; if this removal doesn’t prevent manual job starting from the orchestrator side I think it would be manageable.

1 Like
46

For now it is removed. We’ll need to figure it out if this is important and, if this is the case, how to re-introduce it. But what if you are running from tray? What’s the big difference?

1 Like
47

I used this only to learn. I do not see real-time use of scheduling from the studio robot. Should be OK

1 Like
48

That’s a good point though, if it removes the ability for developers to learn unattended strategies. :grinning:

What if an unattended feature was included in a Studio run, where it logs you off or something like that. I know if you use the console, it kicks you off, however, the high-def resolution doesn’t work.

2 Likes
49

Not a big issue but this way the developer gets the assurance that his code is now production capable as he has been able to successfully run the process from the test-orchestrator the same way it will be run in the production.
If you’re only running it from the tray, you’re left with a feeling of “I don’t know”. Even more so if your a beginner level developer who doesn’t know all the ropes yet.

Personally I dislike the idea to send my code to production team without testing that it’s functioning “the same way it’s done in production”.

One way would be to allocate a third test-robot machine for this kind of situations, but that’s a lot of hassle for the application installations and vpn-connection drills and so forth…

If I would have a say on “how to prevent the misuse of test-orchestrator” I would set a maximum number of runs from test orchestrator per Main.xaml / process (or something similar) to make it annoying & slow to use against the license agreement.

Final note, this change doesn’t prevent the developer from publishing the project package to test-orchestrator right?

1 Like
50

That’s Non Production bots are for. To implement the max runs would be complicated. Does it worth the effort or we have other features we should focus on?

Right

1 Like
51

I guess no matter how you look at this, someone will always be annoyed by it and just have to live with it :slight_smile:

To me the nuisance is small and I surely can live with it (that’s why the templates are made for).

I’m guessing the test-orchestrator can still be used to retrieve the assets and use Queue’s normally in development? ← Meaning that as long as the process behavior is the same whether running from the tray or on the production orchestrator this is a ‘manageable’ problem.

2 Likes
52

Thanks. That’s why we’re getting feedback. To measure the annoyance versus the benefits :slight_smile:

1 Like
53

@badita But here for few process we might need some specific machine requirements or few application to be installed, If we disable this option then we should make sure all robots have all application installed and with same configuration. Is this holds true?

1 Like
54

Then create a folder with few machines (one) and few processes. Terminals Folder. Would this work? But why mix 10 different machines within an environment.

2 Likes
55

Yes! Thank you:)

1 Like
56

@badita But aren’t machines shared across the tenant level, not just a single folder?

1 Like
57

The per server license change allowed us to maximize our licensing utilization. We are aware of the maintenance overhead our model will incur, but other models will incur similar overhead - such as annual security reviews to determine that all the permissions granted to a shared account are correct and valid. It’s easier to review an get manager confirmation of permissions for a unique, limited account dedicated to a certain process than an account that has permissions spanning many different applications, shared folders, mailboxes, departments, etc

1 Like
58

Thanks. That’s why we’re getting feedback. To measure the annoyance versus the benefits

That’s why you should never remove nor change features that people rely on when you add new features.

3 Likes
59

It might be necessary to run a process on a specific machine in situations where software used in the workflow is only available on some machines

Ex- Acrobat DC has a nifty “convert to PDF” browser toolbar button, it’s very useful for when a web page is 1000+ pages (using a traditional “print to PDF” approach could fail/ timeout) but an organization might have a limited number of available licenses for Acrobat DC.

3 Likes
60

@badita
Does this address the issue I noticed the other day with Orchestrator Triggers on an Unattended bot… where if the Enterprise Licensed Unattended bot is busy, then the trigger will send the job to a Studio Development Bot that is in the same Environment as the licensed Unattended Bot?

i.e…

  • Studio Development Bot and Unattended Bot in Environment “Testing”
  • Orchestrator Queue Trigger is triggered, but Unattended bot is busy
  • Orchestrator Queue Trigger sends the job to available Studio Development Bot
61

This is what folders are for (which will replace environments). You put similar machines within the same folder. One machine can be part of multiple folders.

Let’s suppose your deployment grows in size and you need two robots in order to process PDFs. In the old model you will create a new robot, set the password etc. When scheduling you should create two schedules (for bot1 and bot2) since you’re using scheduling on specific bots. In the new paradigm all you have to do is to add the second machine to the PDF folder.

3 Likes