Hello,
I have been wondering the pros and cons of having one robot that is both performer and dispatcher (dispatcher activity within if first run , process is performer) or having separate REframework robots (1 as dispatcher, 1 as performer).
I started this year creating UiPath projects, in onboarding we learned about using REframework and about dispatcher-performer and the two structures 1 project (dispatcher+performer) and as 2 projects, the solution in our case was always using the 1 project structure.
Projects I have been involved in have ended up being very specific and when we have thought about reusing and selling to others that might have differents systems etc it seems to not be viable. You would need to copy project and change some things.
Is it common of splitting up projects like this for reusability?
Example:
Robot that needs to fetch ids from SystemA, go to a website and search for those ids and write result to a datatable and then go to SystemB and do stuff with datatable.
Could THE solution be:
Dispatcher (fetch ids from SystemA) + Performer (Search website by ids and create excel file) + Performer (read excel to datatable and insert data to SystemB)
And then for reusability for another system SystemC the solution could be changed:
Dispatcher (fetch ids from SystemA) + Performer (Search website by ids and create excel file) + Performer (read excel to datatable and insert data to SystemC)
I hope I am making sense, basically how we create reusable projects that are easily customizable and where you can swap certain parts, for example if a different system is used, you can create project for it and use it instead. Anybody willing to share their expertise?
There aren’t really any pros of doing it all in one project. The cons are you make it more complex. The pro of having them separate is you have one dispatcher job that populates the queue and can then have multiple performer jobs working out of that queue at the same time so the items get processed more quickly.
Also, in my experience REFramework is overcomplicated and unnecessary for most projects. It is also a bit old and hasn’t really been modernized. I find it very difficult to maintain REF projects due to their complexity.
Could THE solution be:
Dispatcher (fetch ids from SystemA) + Performer (Search website by ids and create excel file) + Performer (read excel to datatable and insert data to SystemB)
That’s not a dispatcher/performer model. It would be…dispatcher gets data from System A and adds to queue. Performer picks up item from queue, searches web site, enters data into System B, then gets next item from the queue.
The way I usually prefer to handle it, is to have one project that contains the Dispatcher and the Performer. This way it’s possible to use a shared configuration file / object for both, which helps a lot to avoid duplication. Also maybe there are workflows that both processes use, that you now don’t need to duplicate either (in cases where a library project is not warranted).
How this works, is that the Dispatcher and Performer are separate state machine workflow files, let’s call them Dispatcher.xaml and Performer.xaml. In addition to these, I usually include a Main.xaml that’s just a sequence invoking both the Dispatcher & Performer.
Once the project is published to Orchestrator, it’s possible to create many Processes from this package. If you want to run Dispatcher and Performer sequentially, you would create a process that has Main.xaml as the entry point. If you need to run them separately, you can create Processes with the Dispatcher / Performer as entry points.
