Running process in Front Office Robot (FOR)

Hi,
As of now there is no such options to run the script using hot keys .
These are the ways to run the process .
1.From UiPath Studio
2.From UiPath Robot Agent
3.From command line
4.Through a REST command
5.Orchestrator

https://www.google.co.in/amp/s/www.uipath.com/kb-articles/start-process-from-command-line%3Fhs_amp=true

1 Like

OK that’s good to know. I thought I saw them triggering the process via hotkey in one of their demo videos.

Finally then… is the “front office server” they talk about on their website the same thing as “Orchestrator”? I’d like to be able to push new versions of a package down (from the server) to multiple FOR… but not sure what that process looks like. I’ve successfully used Orchestrator to schedule BOR already.

First thing first orchestrator mainly for BOR.
For FOR you have above 4 choice to run the process and more over it doesn’t make any much sense running FOR from the orchestrator because it’s requires human intervention.:wink:

Running no, but managing package versions does and works the same as for BOR.

Not sure what “front office server” is - where did you read this?

To push new version of a package down (from the server) to multiple FOR using “Orchestrator”:
a) Publish new package (via Studio or using Upload Package option in “Orchestrator”)
b) Go to Process, click manage version and click on ‘Use’ against latest version

Sorry, I beg to differ.

Orchestrator as much as for FOR as much for BOR. Specifically for FOR, we can use Orchestrator for

  • manage package version
  • check Logs
  • use Assets

All true.:+1:
I was just mentioning about when there is a human intervention required for FOR then there is no much sense even if you schedule from orchestartor because process won’t be proceed until user intervene.

Buying Orchestrator for BOR makes a sensible investment. :slight_smile:
At the EOD its left to the user how he elaborate functionality of each component of UiPath.

peace .:v:

Can you please expand on this or point me to any docs which explain the process? I was musing about this in a separate thread… trying to find out from anyone how all the FOR associated with a given process can simultaneously/automatically get a new package.

Thanks! I think I’m starting to catch on.

You left off the steps about how the FOR machines see/get the updated package version… but reading between the lines:

Any given FOR should be registered to Orchestrator… and when this is completed… that FOR user will then see the ORCHESTRATOR-hosted processes (as opposed to the local packages) in their local system task tray.

So in that way… we never actually push new packages down to FOR… the updated package is PULLED when the agent manually triggers the process on their FOR?

FOR Packages

1 Like

Right. At the second trigger the package will already be there.

  1. Robot retrieves available process/version list from the server and displays them in the tray
  2. User triggers P1.Vx
  3. Do I have P1.Vx downloaded?
    Yes: Run
    No: Download and Run

Implementing an actual push would be more complicated but the result is the same (except a small delay at the first run)

1 Like

Thanks!

I actually don’t care about doing a push… I was just trying to wrap my head around how it all works so I could use it. This nuance (from the perspective of attended robots) doesn’t seem to be explained in any video or document I’ve come across.

Agree :slight_smile:

UiPath - Front Office vs Back Office Robot.pdf (89.0 KB)

2 Likes

Thanks again!

Here’s one additional nuance I’m curious about now that I understand it:

We are told that Orchestrator will aggregate the Log output of multiple attended (FOR) robots. From what I can see in Orchestrator… each log item has datetime, process, and user. The process & user fields are therefore critical to for an RPA support person to use when trying to assist a human who is having a problem with their attended robot’s performance.

So… that leads me to believe that each human’s computer where an attended robot will run shall be registered into Orchestrator with that human’s own Windows account/credentials.

That’s the only way we would be able to differentiate log items from different humans running attended robots of the same process.

My concerns:

  1. If we must register the human’s computer into Orchestrator using that human’s credentials (so we can differentiate log items)… doesn’t that mean that the human would have to be the person registering their machine to Orchestrator (i.e. so they don’t have to tell an administrator their password)? What if we never had plans to allow our humans to play any role administering/configuring Orchestrator?

  2. What if humans’ passwords are forced change every 30-90 days due to IT policies? Presumably those humans would need to return to Orchestrator every time their password changes so the attended robot can continue to receive package updates, use Orchestrator Assets, and log items, etc.

Am I misunderstanding how the machines running attended robots will connect to Orchestrator?

For FOR you don’t need to store the credentials. just register the robot and leave the password blank. Credentials are only used to auto-login a Windows session in the BOR case.

1 Like

Excellent! Another hurdle removed. Thanks!

Thanks. Looks like ‘Orchestrator’. Can someone from UiPath confirm if ‘Front Office Server’ and ‘Orchestrator’ are same?

If you read between the lines in his replies to my questions… Badita already indirectly confirmed it. I was asking Orchestrator/FOR questions, and he was replying how I can satisfy my FOR needs, using Orchestrator.

See also his replies in the other FOR thread.

1 Like

Perfect thread :slight_smile: thanks…

@badita my original post in this thread was actually meant as idea rather than ‘How-To’. Can we change thread category to ‘Idea’? if not, may be I can re-post my idea in separate thread.

1 Like