I am trying to configure my queue trigger to only run using a machine template (3 machines connected) shared by multiple machines however I’m not able to specify the exact machine. Only when I run a job manually in Orchestrator I’m able to see available connected machines to select.
This poses a problem because my current solution is to effectively create a separate machine template just for that single machine. However now it’s no longer connected with the rest of the previous template that included all 3 machines. There are some processes that can run fine on either of the 3 machines so I can just share the same machine template. However there’s one process where it must run on this VM. What is the rationale for not letting me configure queue triggers to run on one template under one specific connected machine?
I’ve checked my user-machine mappings but this is only to make sure certain robot users can only access certain machine templates (not certain machines which is one more level below)
It seems that you have trouble getting an answer to your question in the first 24 hours.
Let us give you a few hints and helpful links.
First, make sure you browsed through our Forum FAQ Beginner’s Guide. It will teach you what should be included in your topic.
You can check out some of our resources directly, see below:
Always search first. It is the best way to quickly find your answer. Check out the icon for that.
Clicking the options button will let you set more specific topic search filters, i.e. only the ones with a solution.
Topic that contains most common solutions with example project files can be found here.
Read our official documentation where you can find a lot of information and instructions about each of our products:
Meet us and our users on our Community Slack and ask your question there.
Hopefully this will let you easily find the solution/information you need. Once you have it, we would be happy if you could share your findings here and mark it as a solution. This will help other users find it in the future.
Thank you for helping us build our UiPath Community!
I am needing to do that as well. I guess its not possible using the Queu Trigegr for the moment. Maybe is better if you change this Post to the Feedback category, so we can vote on it and the uipath team can place on the roadmap.
Would having a separate, second template an option for you? I think you could add that second template with specific user mapping and achieve it this way.
I will tag @Ovidiu_Constantin for more information here I’ll also add it to our internal ideas tracker for our team to consider it when thinking about future improvements.
I thought the idea of having multiple machines connected to one template is to allow dynamic allocation in cases when one vm is occupied with one process, another vm can be used for the same process to complete outstanding queue items.
I can separate my two vms into separate 2 machine templates but then I’m not really understanding what is the ideal purpose of having multiple machines use the same machine template and its use case.
I think it works the other way around. You can have multiple templates per folder and allow most process access to these templates (and use user mapping to set some further restrictions in place).
But then, have one process that has to use one specific template that has 1 specific machine in it.
I believe this allows you to run most automations on most VMs (while taking advantage of dynamic allocation), while still having that one process use one specific VM.
Feel free to elaborate if I am still not fully grasping the scenario
I understand you can have multiple machine templates per folder, however you can only apply 1 template to the machine. I’m able to apply the same 1 template to many other machines. This makes sense in my mind as why the name is called a machine template (“applies to multiple machines for dynamic allocation”)
I agree with user mappings on machine templates in the newest Orchestrator version, lets you limit what kind of robot users can access that machine template. But still in the case where I want to run this process through triggers on just one single machine is limited.
I want to make this VM still available for dynamic allocation with other processes under the same machine template. I can’t apply two machine templates on one machine I believe. Say I have just this 1 machine template that lets me run this process on this specific VM, I’m fine with the existing machine template that is only applied to this VM. But if I add more machines to the same template, I get dynamic allocation but lose the option in my trigger to specify which VM to run on. If I create two Machine Templates (#1 only applied to this VM, and another #2 applied to other multiple VMs) I’m unable to run a process that can use VM#1 for dynamic allocation. I would have to apply machine template 2 and the other multiple machines can pick up that process for dynamic allocation)
My ideal situation is that I register 1 single Machine Template for all the VMs I own in that modern folder. There would be processes that can be ran on any of the VMs assigned to the same Machine Template for dynamic allocation, however for some cases I want to specify a certain process can only be run on one VM on the machine template. I can do this manually when starting a job, but for some reason I cannot with a queue trigger…
Hopefully my desire makes sense, the terminology of machine templates alludes to what I believe should work.
This scenario is not possible on cloud Version 22.1.28-release.14.
+1 for this functionality. I would like to force a timed trigger to only run on a single VM that’s assigned to a template.
The OTHER functionality that would work for me is if I could limit a timed trigger to be “running” only once. Currently there’s no way for me to limit a job to 1 running when my VMs are in a template.
I’ll also add it to our internal ideas tracker for our team to consider it when thinking about future improvements.
Palaniyappan
Anil_G
mpraveen1902
Yoichi
prerna.gupta
nien_shan_thai
Kartheek_Battu
CHAN_Hiu_Fung_Victor_Stud
KishoreC
nikhil.girish