Automation in background

Help Activities
,
24

Hi @vikash.poddar,

I did a quick read of the topic and it is not quite clear to me on where the clarification is needed. So I’ll make a couple high level points that might be reiterating some knowledge that @kirankumar.mahanthi1 and others have already shared.

  1. Background vs Foreground - The concept of background and foreground is intended to whether you are using Activities that interact with the UI (e.g Activities from the UiAutomation pack), this is determined by your Project Settings and the activities used within the project.

    Please note that Background processes are ONLY supported with Attended Type Robots (Developer/Studio, Attended) and when run on an Unattended Robot it will be treated as a Foreground Process.

  2. Unattended vs Attended Robot - This is how Orchestrator will kick off a Job and what type of Robot is waiting to process a particular job, in setting a Robot as Unattended you would provide some form of credentials so that it can remotely start/attach a session. Further to this, a Robot can be installed in User Mode which requires an already active Windows Session with the Agent running, or in Service Mode where the UiRobot Agent is registered as a Service and listening for jobs without requiriing an active user.

    UiPath provides 1 Unattended Runtime for Community Users, if you need to register the Robot as a Service this can now be done through the Community Installer, but you might need to go into the Advanced Options depending on your installation method. I posted some screenshots of the UiPathStudioCommunity.msi installer here

  3. Input Methods - Default, SendWindowMessages, Simulate determine how the input of your typing, clicking, etc. is going to interact with the UI. Each has their pros and cons based on their Speed, Feature Support, and Compatibility. When talking about Background Execution in the case of Input Methods, this is different from Background vs Foreground processes and is referring to the ability to send signals to the UI with the component not at the front of the display (e.g. Minimized, Hidden, etc.) It is generally recommended to use Simulate where possible as this is the fastest method and it doesn’t interfere with other activities on the host (e.g. user actively using the session)
    More details can be found here.

There is no one-way fits all approach, how you solution your project will comes down to what licenses you have available and for the most part experience of the available features and preference.

For example in our organization we prefer simulate where possible regardless to if we are deploying a process on an Attended or Unattended Robot as in both cases we may wish to monitor the job and if we were to use the Default Input Method there is a risk is increased that the observer could interfere with the running process unintentionally through Clicking/Typing, simply dragging the cursor, or minimizing and/or locking the RDP Session; Simulate helps to protect against that.

Alternatively if we were targeting Attended use cases, we have the option of Picture-in-Picture, this helps to segregate an end user from the Robot by starting an isolated session on the attended host.

  • Background Mode is limited to Attended Robots
  • Re: Attended Robot you have the option of Simulate if you must use a UI Interaction so not to interfere with the user, or Picture-In-Picture.
  • Re: Unattended Robot, the concept of “Background” Process doesn’t exist here, it will be run as a foreground process. In order to truly make the steps you are performing a ‘background’ process you would have to look at alternate means of automating your tasks such as Headless Browsers, Invoke Code, etc. Something that does not depend on UI Interactions. How complicated this might be will depend on the Service/Web Application you are fetching the files from.

References

https://docs.uipath.com/robot/docs/windows-sessions

3 Likes