I have a specific doubt regarding an RPA design approach.
I am Currently working on a process that reads items from an Orchestrator Queue, accesses a website and extract data. The process itself isn’t a big deal, but I’m considering two scenarios:
First option:
A Dispatcher that reads a static excel file (15 lines, same data every time), stored in the Input folder on the robot dependencies, pushes it up to the Orchestrator Queue and then, a Performer would execute those 15 items.
Second option:
A single REFramework where, during the Initialization state, the workflow reads the same file and populate the data to an Orchestrator Queue to be processed on the same execution.
In terms of performance and infrastructure perspective, which scenario would be more efficient?
Contextualizing, our RPA environment is composed by 5 servers and over 270 bots (unfortunatelly, running out of windows of execution ), I am trying to chose the most efficient design to deal with smaller use cases like this one.
Would using a Dispatcher x Performer design, to deal with this kind of projects, be considered excessive?
as it is a single time addition and straight read and add…just use bulk add queue item and add the data this will complete dispatcher in two activities hardly
also to ensure multi bot architecture have a input flag argument and set it to true only when you need dispatcher..so you can add one time trigger with true and all queue triggers with false so that dispatcher runs on time trigger and once items are added queue trigger would start remaining if needed
You can use the Simple RE Framework with a data table as transactional data and each row as a transaction item. However, some additional code will need to be developed to keep track of processed items.
For Dispatcher X Performer, it is not necessary to create two projects. Just create an additional XAML file for the dispatcher and enable the entry point; your main will act as the performer entry point. This approach allows one project to have two entry points and avoids the extra logic to handle completed items.
The consideration on having your dispatcher nested somewhere in a performer Init (let call it a hybrid) versus a separate dispatcher / performer usually comes down to this:
scalability. Having the dispatcher nested in the performer limits you to run more distributed runs, having multiple performers work in parallel to process higher loads quickly.
Overhead. Starting and stopping a separate dispatcher takes longer. Not that much depending on your architecture, but it is there.
Simplicity. Sometimes having a simple robot as a single entity is just easier to contain.
Standardization. If you have multiple bots in your landscape, and they are all built as a duo, sticking to the standard has benefits, especially in larger teams.
Triggering / scheduling. On a crowded platform you need to make sure to align your triggers so dispatcher and performer can and will follow each other. Rarely an issue, but again something to consider.
Complexity of the dispatcher logic. REF has a strong error handler / retry mechanism. Having a dispatcher sub workflow stuffed somewhere in the Init might require additional error handling logic, especially if a lot of GUI steps are involved.
Cake. Never underestimate this.
Looking at your process description you are most likely safe with a hybrid solution. You might want to have those 15 items stored remotely (storage bucket or some other data field) that even if they rarely change, they might some day. Being able to do a non-release change in behaviour makes you flexible. If you ever expect the workload to increase you might still want to consider separating the dispatcher. See above.
When using Bulk Add Queue Item activity, it doesn’t require a For Each loop to add the items separately? It works just like a dictionary if I got it right.
The problem here is that using a data table to deal with items (of course, in my opinion), isn’t the best due to lack of the “keeping track feature” that is present on the Orchestrator Queues…
just read the data to datatble and pass to bulk add queue item and it would add all items and no loops are needed..column names are used as specific content keys. If you need reference add the column for that as well
Searching on the properties of the acitivity, I didn’t see the “Reference” field, as on the casual Add Queue Item activity… Is there a way to use reference in these use cases?
), I am trying to chose the most efficient design to deal with smaller use cases like this one.