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.
nicolaem159908 Thanks for your feedback. I would really like to understand your point to try to help explain how Appian RPA address this. If I may, I have some questions and comments:
Questions:Q1. What do you mean by "The Product"? Appian RPA, Appian platform, both?Q2. What do you mean by "default"? Asking because, if I am not misunderstanding your need, that can be easily addressed with Appian and Appian RPA OOTB capabilities.Q3. What do you mean by "a runner"? Asking to clarify to what you are comparing it with in the Appian platform. Same needs are normally addressed differently between vendors. That does not mean it cannot be addressed, just the way to do it is different.Q4. Could you provide a specific, detailed description of the use case you're trying to address with Appian and/or Appian RPA?
Comments:- "Concurrent transactions" is one of the most common use cases and it is extremely easy to address with Appian RPA by configuring the number of Agents you need and the proper Robot Pool to manage it. Then, Process Models can add additional orchestrator logic when necessary.- Comparing concepts between vendors often lead to confusion. We recommend trying to address the use case with Appian from an holistic perspective, using all its platform potential, without making 1:1 comparisons.