What is the best practice for using a sort of nested queues? Or do you say stay away, don’t start with those things.
To elaborate:
I have a list of names. 1 by 1 those names need to be opened in the software. When you open a name (person1), you get another list of all the appointments for that person. And so for every appointment of person1 there need to be done certain actions. After all the actions for all the appointments of person1 it should continue with person2 and do the same thing.
It’s like a sort of nested queues.
I think I have already something like that, and the firm that made the RPA then worked with a loop and flowchart in the “get transaction data” step. But I get from the users that the problem with that is, that when something fails they need to do all the previous steps again.
So if something fails at person 3, the RPA needs to be restarted, and starts again with person 1 …
What is best practice in those situations?
Get a RPA that gets all the appointments of all the persons of the first list and makes queue items of it? And then start another Reframework handling all those queue items?
I think your instinct is right, the queue item should be the smallest thing that can fail on its own, so the appointment and not the person. Then if something breaks on appointment 3 of person 1, only that item retries and the rest stays done
since you only find the appointments after opening the person, I would go with two queues. The first holds the persons and a small dispatcher walks it just to read the appointments and push them into the second queue. That dispatcher is a performer over the persons queue, so if it dies at person 3 it resumes from there instead of starting over
also worth putting personid_appointmentid in the item Reference, helps tracing and avoids duplicates if the dispatcher runs twice
let me know if you need more help I woul be happy to help think about this architecture
I would avoid making it a real nested queue if it can be avoided. In your case, I think your idea of creating queue items for the appointments is a good approach.
For example, you can have one queue item per appointment, containing the PersonID and AppointmentID.
So it would look something like:
Person 1 → Appointment 1
Person 1 → Appointment 2
Person 2 → Appointment 1
Person 3 → Appointment 1
Then the REFramework processes each appointment independently.
The main benefit is recovery. If processing fails on Person 3 / Appointment 2, you don’t need to start again from Person 1. You can retry that particular queue item.
I would probably split it into two processes:
Dispatcher – reads the persons and their appointments and creates the queue items.
Performer – REFramework gets each appointment from the queue and performs the required actions.
This also makes retry handling and monitoring much easier.
The only thing I would consider is whether appointments for the same person must be processed in a specific order. If they are independent, one queue item per appointment is definitely the approach I would prefer.
hey @sallegae Suppose I have 100 customers, and each customer has multiple appointments. Instead of creating nested queues like Customer Queue → Appointment Queue, I create one queue item for each appointment because the appointment is the smallest independently processable unit.
The Dispatcher reads the customer data and adds each appointment to a single Queue. Then the Performer processes each appointment using REFramework. If one appointment fails, I can retry only that particular queue item instead of processing the entire customer again.
I would also use a meaningful Queue Reference, such as CustomerID_AppointmentID, to track transactions and prevent duplicates.
