as seen in the following thread, I already succeeded to publish my packages offline.
But now I need one package to call another package and pass some parameters. However, when pointing the “orchestrator” folder path to the path where the packages reside, the package I want to invoke can not be found.
Am I doing this wrong or how am I supposed to do this?
Ok maybe I need to reword this, I have separate workflows where one is the main workflow that I have published now and another workflow that has to be called by this main workflow. I have also published this locally in my assistant.
Due to some restrictions with unattended robots, it seems that they can not call other .xaml files, so that’s why I am currently changing it to this way of calling the workflows.
Best way to do what you’re talking about is having automation 1 put an item into a queue, and have a queue trigger that kicks off automation 2 which works out of the queue.
Not sure if I get what you mean, but I think that’s not how I intend this to work.
I currently have a workflow that is the main control workflow and depending on certain variables, it is supposed to call another workflow that currently resides in a subfolder (because not possible otherwise). These sub-workflows are different, depending on the state of the main workflow and once they have done their work and terminate, the main control flow resumes and continues in a loop to check for more to process.
As mentioned before, this is currently implemented as regular workflows that are just .xaml files that are beeing called and that seems to not work on unattended robots.
That is why, I published the control center workflow and one of the sub-workflows locally, and tried to do the same thing as before when I just invoked an .xaml file (I do have to pass some parameters back and forth).
Unfortunately this is not working as expected.
Please keep in mind that I do this “offline”, so Assistant is disconnected from the Orchestrator since I do not use the orchestrator.
You’re using Invoke Workflow to call XAML files within the same project? This is all published as one process. You create arguments in your sub-XAMLs and then click the Import Arguments button on the Invoke Workflow activity.
No, the workflow in the subfolder is a separate project and has to remain a separate one. I only have it in a subfolder since having it in a folder on the same level (next to the control framework) didn’t work out because uipath is weired. (see here: How can my main robot invoke another robot outside the main robots folder?)
This is why I need to publish them separetely, because these workflows might change or be replaced or what ever and this should not affect the main control workflow.
Cheers
Edit: I am currently trying to call the sub-workflow “process” that is listed in the assistant with the “call process” activity in the control workflow. And whether I set the Path to the directory the processes reside in or not, I get the exact same error message that a Process with that name is not found in that folder. But the process is there and also named correctly, I have already triple-checked that.
You shouldn’t have one project inside a subfolder of another project. This may be leading to your confusion about how this all works. Projects/processes should be completely separate.
So, again, you have two different processes published in Orchestrator. Use a queue as the intermediary between the two. Automation 1 puts things into a queue (or queues) that trigger the execution of Automation 2, Automation 3, etc.
Well if UiPath would support exactly what I wanted, I wouldn’t be forced to have them in a subfolder afterall.
And I don’t really understand how a queue is supposed to solve my problem? I need exactly what the “invoke process” activity descibes, to call a process from a parent process, that then waits until the child process finished and then continues it’s work. And also in the provided video it is implied that this works, even though it is only shown with the orchestrator but basically this is what I need (just offline).
Because you put an item into the queue and have a queue trigger that starts the secondary process. This is specifically how the dispatcher/performer model works. You dispatch into a queue (or queues) and then queue triggers kick off the performers.
If you need the dispatcher to wait until the queue item is processed then continue…
You could have the secondary automation put an item back into a different queue to tell the original automation to continue, and provide it the parameters (output from the secondary process).
This may also be useful to you.
Having them in subfolders does nothing to accomplish what you’re trying to do. Again, projects should never be in subfolders of each other.
So I need to add my sub-workflow that I intend to keep as separate as possible as a dependency to the main workflow? That’s…kinda the opposit of keeping it separate, or am I wrong?
I understand that having them in a subfolder is not the correct way to go forward and I would prefer to avoid it all together if I could. My main objective (as stated in the linked post) was to have them in an entirely separate directory.
Since then, the requirements seem to have changed so that I have to publish it as a process to the assistant.
Please forgive, but I still don’t understand how a queue is supposed to make things easier for me.
What is the point of the “invoke process” action with the ability to pass parameters if I am supposed to put something in a queue?
And besides that, if I were to use the queue, doesn’t that mean that the sub-workflow would need to be active and wait to see if there is anything in the queue in the first place?
I need the sub-workflow to be invoked by the control-workflow and only have one workflow active at a time.
Not sure if I could really get across what I intend to do :-/
This is ALWAYS how you prepare a project to be executed. You ALWAYS publish either to Orchestrator or a local folder (that is watched by Assistant).
You can use Invoke Process if you want. But if your first automation is triggering another automation then waiting for it to complete, this is not a dispatcher/performer model.
Okay maybe I need to walk a step back to explain what I’m trying to accomplish. It seems that we might not be on the same page.
Coworkers of mine are preparing different processes/workflows that are supposed to process certain tasks. I am creating the process/workflow that is supposed to “manage” all of these other processes. So you could see it as a giant “switch case” that determines what process/workflow I need to start to process a certain thing.
We are trying to keep these workflows separate because the sub-workflows are developed by different people and I want to avoid having to update the control-workflow every time there is a new sub-workflow.
I don’t know if what I am trying is the right approach, since this my first time working with UiPath.