Dispatcher : The Dispatcher is responsible for gathering data or tasks from external sources (e.g., files, databases, queues) and queuing them for processing.
Performer : The Performer(s) then execute the tasks based on the data provided by the Dispatcher. This model is commonly used in scenarios where you need to process large volumes of data or perform repetitive tasks.
It’s possible to use the REFramework in scenarios where both the Dispatcher and Performer logic are encapsulated within the framework itself.
You can Use the Dispatcher in the INIT STATE - In the First Run
It’s not mandatory to have dispatcher-performer in RE Framework, It’s completely based on the your requirement.
Scenario 1: Using dispatcher and performer as separate processes.
Implementing a process in the multi-bot architecture environment.
Want to run dispatcher multiple times in a day.
Scenario 1: Using dispatcher and performer under same RE framework
Simple process which runs dispatcher only once
Note: Have the dispatcher in the first run sequence in Initialization state so that when a system exceptions comes for retry it will not run the dispatcher again.
No, not really
REFramework is not limited to the Dispatcher-Performer model. While it’s commonly used for this model, the REFramework is flexible and can be adapted to various automation scenarios.
Not necessarily. In the Dispatcher-Performer model, both the Dispatcher and the Performer can be structured within the REFramework. For instance, you can implement the Dispatcher logic within the Init state of the REFramework.
It’s a matter of how you organize your automation project. You can use the REFramework to structure both the Dispatcher and the Performer components effectively.
The Dispatcher can be outside or inside the RE-Framework. If the Dispatcher is outside the RE-Framework, it is typically implemented as a separate process or service. If the Dispatcher is inside the RE-Framework, it is typically implemented as a workflow. Same with performer as well
inside every REFramework project created, there is a folder called documentation, and there is a pdf file with the best documentation on how to use and which are the best practices
REF is not always dispatcher performer…as teo separate processes…you can combine into one as well…where you can do the adding of items task in the initialize stage …also we can use REF for linear processing also
Dispatcher can be a standalone code with a small sequence or REF itself can be modified as a separate dispatcher both are possible and can be used…if the processing of data is high and if there are few steps performed before adding data to queue or for processing then using a separate dispatcher by converting REF as dispatcher is preferred…else if it is a small process then can either embed into perform init state or can use a separate sequence or a flow to run it as standalone as you need
The idea to separate both is to have the multi bot architecture…where the items are added for processing to queue and the performers can run on multiple bots at the same time to process one item per bot without any interference or issue
In UiPath’s REFramework, the Dispatcher-Performer model is a common use case, but it’s not the only way to implement it. The Dispatcher and Performer can both be part of the same REFramework project, or they can be separate projects, depending on your automation requirements.
Typically, the Dispatcher is responsible for gathering and queuing items to be processed, while the Performer retrieves items from the queue and processes them. However, you can structure your automation in different ways based on your specific needs.
For learning material on UiPath’s REFramework, I recommend the following resources:
UiPath Academy: UiPath offers free courses on their platform, including detailed training on the REFramework. You can find structured learning paths and tutorials there.
UiPath Documentation: The official UiPath documentation provides in-depth information about the REFramework, including explanations, best practices, and examples.