Since the beginning of SAP Intelligent RPA, it has been difficult to execute some jobs with unattended agents since some very specific actions require the application to be upfront (and consequently the Windows session needs to be unlocked), otherwise these actions cannot be performed and the job fails. A previous article already presented interesting workarounds to avoid using these specific actions but some cases could not get rid of them. That’s why I would like to present you in this article how to deal properly with the need to unlock temporarily the agent session.
As I'm speaking of the beginning of SAP Intelligent RPA, I will focus on Desktop Studio projects in this blog post. I will talk about this subject with Cloud Studio later.
NB: in this blog post, I will use the term session to speak about the Windows session.
Let's get some additional info about this specific issue.
In Desktop Studio, you can execute some actions that require the session to be unlocked. Among them, you will find (this list is not exhaustive):
When you execute these actions in attended mode, you see nothing wrong as your Windows session is already unlocked (What's the point to lock the session in attended mode?!)
For obvious security reasons, you cannot (you MUST NOT) leave sessions opened on a VDI or virtual machine or more generally a remote machine. But in that case one might ask : "Ok genius, how can I execute a clickMouse action on a remote machine?"
The answer to all your problems (or quite...)
What mechanism to use?
First, a bit of explanation about how we will deal with that.
Since we cannot execute these actions if the session is locked, we have 2 options :
do not execute these actions
unlock the session and then execute the action
Even if the 1st option is not the one people want to hear, that can make sense to check our workarounds to avoid this “low-level” actions to be used, especially in order to get your automation more robust (who does like to click on x,y?). This is the topic of the previous article I was mentioning earlier.
So let's dive into the 2nd option right now!
To unlock the Windows session, we added a new activity in Desktop Studio, and of course a new method in the SDK.
Now what does this activity/method do ? It will simply unlock the session for a given amount of time (current value is 10 seconds), so you/your agent can perform these specific actions we speak about from the beginning of this blog post.
I recommend to use this activity/method before each action that requires the session to stay unlocked.
Warning: you must also consider the fact that unlocking a session is not immediate. Sometimes it can take few seconds.
What are the pre-requisites?
"Ok so if the agent needs to unlock my session, it means that it knows my credentials". Yes, that's right. For the agent to be able to unlock the session, your credentials need to be stored so the agent can use them.
To store them, you need to use the CxStoreCred.exe tool. Take a look at this Note for more information about how to use it.
Beware: if you need to change your credentials (security policy, for example) you need to manually store these new credentials in the CxStoreCred.exe tool.
What now ?
Now you can deploy your packages and start create jobs on remote machines that will be executed by unattended bots.
To make sure that everything is correctly set up on your remote machine, please have a look here.
Last, check out the Store as it contains a sample with this use case!