Nice approach, that trigger me a completely different question in my mind. Would you mind sharing how the license was applied to the high density robots? My understanding is that when we install the robot on the server there is only one UiRobot.exe at the Program Files level right?
Fair enough, this is a limitation of Windows and not UiPath.
I’m assuming that it is because the UiRobot.exe is still one executable files being triggered multiple times by different credentials.
So the feature of having Runtime defined in orchestrator helps solve the issue of not failing if another process is running, is my understanding correct?
As of right now each additional provisioned robot consumes a license even though they cannot run in parallel. We will explore how concurrent license model with single runtime may work, to adjust our licenses.
Correct - I have not tested the implementation yet, but my assumption is that orchestrator will check how many available runtimes there are on the VM and even if a ‘Robot’ is available to run a process, but a ‘runtime’ is not, it will add the job to the Queue until a runtime becomes available to launch the robot to execute the process.
Thank you Jose that helps me understand the scenario better.
We have one unattended bot running multiple processes and the bot runs with one credential having access to run all the processes. That’s the reason I was looking for configuring credentials per package.
@Mr_JDavey developed a process on this version but when trying to work with it in 2018.1.2 (Enterprise) the Invoke Workflow File Activities all display as XAML Errors. Tried adding all packages including v7 compatibility pack but no joy.
Yes that is indeed the case, this new functionality of the Invoke Workflow activity is not backwards compatible with versions older than 18.2 (although older workflows which contain the Invoke Workflow activity will work just fine on 18.2 and up). As pointed out by @Mr_JDavey removing the Timeout=“” property manually from the .xaml will make the workflow work on older versions as well.
We call this forward compatibility and we don’t guarantee it. It’s impossible for old environments to know or ignore new properties.
Backward compatibility is when a new version supports old workflows and this is valid for 18.2 release.
There is no preliminary documentation until the stable release. The Python activities are only relased in Beta for now.
But I will give you some inputs:
The Python Scope container activity connects to the Python environment installed on the machine and enables you to use the rest of the activities within itself.
The PythonObject variable is specially designed to handle and manipulate scripts. By use of the Load Python Script activity, you can easily convert any file containing Python script to a PythonObject.
Get Python Object - Converts a Python.Object variable returned by other Python activities into a .NET datatype of your choice. Can only be used inside the Python Scope activity.
Invoke Python Method - Helps you run a specified method from a Python script directly in a workflow. The script that contains the method needs to be loaded into the environment first by using the Load Python Script activity. Can only be used inside the Python Scope activity.
Run Python Script - Enables you to execute Python code. You can input the code directly in the activity or provide a file path for it. Can only be used inside the Python Scope activity.
I hope this will make things more clear until the official documentation is out.
@ovi Thanks, this did definitely help - nonetheless I am wondering when the full official documentation will be relased? The last statement by @badita was that 2018.2 will be released on May 20, but I don’t seem to find any new information about any announced feature.