I know about Appian queues, etc related to multibot configuration.
However when I compare how UIPath queues work (in a reFramework configuration we first load data in the queue - using what we call a "dispatcher" - and each record is locked during processing using what we call a "performer") and I compare this with Appian queues I have a feeling that there is something that I miss.
Can somebody provide more details about it?
Thank you.
Discussion posts and replies are publicly visible
I should've been more clear about the question: is Appian RPA a real multibot technology?
Appian RPA can successfully and smoothly handle hundreds of simultaneous RPA Agents online with thousands of simultaneous executions. There is no direct 1-1 comparison between how UiPath manage queues because UiPath cannot be compared (only) with Appian RPA; you have to leverage all Appian platform capabilities. The best option is using the Process Model as the dispatcher.
UiPath Orchestrator provides a native Dispatcher–Performer–Reporter pattern. In Appian, there is no direct equivalent orchestrator, but the same pattern can be implemented using Appian objects.
Dispatcher
Input data is read from files, APIs, or external systems
Data is loaded into a database table using:
Appian integrations / APIs, or
Appian RPA robotic tasks
Each row represents a unit of work, similar to a UiPath queue item
Performer
A process model is used to orchestrate execution of bots
Based on the number of records loaded by the dispatcher:
The Execute Robotic Task smart service is triggered using MNI or looping
Each execution processes one work item and updates its status
Parallelism is controlled by the number of agents in the robot pool
This enables a multi-bot architecture, similar to UiPath performers picking queue items
Reporter
After all performer executions are completed:
Data is queried from the database table
Reporting can be implemented based on the requirement
Orchestration
Dispatcher, Performer, and Reporter can all be coordinated from a single process model
The process model effectively plays the role of the orchestrator
Sanmathi Subburaj - after a year or so with the product: by default the product is not able to process concurrent transactions, one "runner" is not able to lock one transaction in order to stop another "runner" to access it. Again, I'm talking about "by default". Show me proof that I'm not correct and I will change my opinion.
miguelangel.carnero - after a year or so with the product: by default the product is not able to process concurrent transactions, one "runner" is not able to lock one transaction in order to stop another "runner" to access it. Again, I'm talking about "by default". Show me proof that I'm not correct and I will change my opinion.