In dispatcher there is 4 different logic/process to read and add data into 4 different respective queues. Single performer solution with 4 different logics/process for the data from the respective queues.
Each process(here 4 queues and it is separate) has different priorities and we have 4 BOT licenses which should process data from 1st priority queue first with some items per BOT, please let me know how we can do solutioning of this usecase in terms of Queue priortization in Get Transaction data state.
Process Priority ItemsperBOT
A 1 10
B 2 5
C 3 20
D 4 30
You can handle this by adding a priority-based queue check inside your Get Transaction Data.
Since you have 4 queues (A, B, C, D) with different priorities and each BOT should pick a limited number of items, you can make the Performer follow this order every time it tries to fetch work:
Check Queue A first → if it has items, take up to 10 items per BOT
If A is empty, check Queue B → take up to 5 items per BOT
If B is empty, check Queue C → take up to 20 items per BOT
If C is empty, check Queue D → take up to 30 items per BOT
This way, all 4 BOTs will naturally consume the highest‑priority queue first without needing separate performers.
@Christopher_R Thanks for sharing the approach — the priority-based queue check (A → B → C → D) makes sense . One challenge I see with this setup is around the items per BOT limit. Since Get Transaction Item keeps fetching items until the queue is empty, each bot may continue processing from the same queue beyond the intended limit (for example, more than 10 items from Queue A
@MANISHA_V_ARORA To handle this, one possible solution is to maintain per-bot counters inside the Performer. For example:
Define variables like A_Count, B_Count, C_Count, D_Count
In Get Transaction Data, check both priority and count:
If A_Count < 10 → fetch from Queue A
Else if B_Count < 5 → fetch from Queue B
Else if C_Count < 20 → fetch from Queue C
Else if D_Count < 30 → fetch from Queue D
Then, after each successful transaction in the Process state, increment the respective counter.
This way, each bot respects both the queue priority and the items-per-bot limit, which seems to be the key requirement in this use case.
First thing even the process is same for performer one performer can Id eally work with only one queue …so you have to either add queue name as input parameter or create 4 process with same package in orchestrator and give each a different queue…single process in orchestrator cannot work as queue trigger from 4 queeu cannot be added to same process
now coming to the priority…the priority in queue are internal to each queue not across queue ..so even if priority is set for queue items in different queue they would be considered internal to that queue only…as you have single dispatcher if you want to start the q1 first then add the q1 items to the queue first this way the queue trigger for q1 woudl start first and process them…and now if you link all machines to q1 then till q1 completes no other process starts…as they would be waiting for machine to be free…so either link only limited machines or agree with processing all q1 and then ove to q2 etc..
if you dont want the above then in dispatcher itself while adding queue items add only limited items to queue for each q1 to q4 and then let the dispatcher run again after few hours or minutes to add few more items..the logic for this to be present in dispatcher ..so that limited items from each queue are processed and then second sent of items would start