Dispatcher and Performer Question

Hello Everyone,

I do have an excel file which is readily available, and I want to use queue item as my transaction item. I read on some discussion that dispatcher and performer must not be on the same ReFramework and correct me if I’m wrong with my understanding about that. I just have a question if is it okay to put my Dispatcher on the Initialization state then put my Performer on the Process state so that I don’t have to do 2 different ReFramework? and what are the pros and cons on what I want to do. Thanks!

Hi @Gus_Fring
Yes you can make dispatcher and processor in same ReFrame work.
But point is that their is no flexibility to run dispatcher and processor independently. When you will whole program it will add data in queues and suppose data is to much.
It will take to much time to add then it will take to much time to process it.

Inshort processor can’t run parallel to dispatcher. If the processor is runing parallel it will dicrease you processing time.

Second scenario suppose dispatcher added data successfully but processor stopped working. So maintenance cost will be double.
So build separately

Thanks

Correct me if I’m wrong on how I understand it. The reason why we separate the dispatcher from performer is to not always add queue item to the orchestrator every time we run our robots? And in that case, if my performer is already separated to my dispatcher, and my performer has a failed transaction, I will just run the performer and not the dispatcher. Is that correct?

Considering I combine my dispatcher and performer then I put an activity where it will delete first the transactions that has a remark of failed or successful then after that it will be mark as deleted on the queue right? What if I have already hundreds or thousand of transaction item that has a remark of deleted, will it still affect the processing time? Or it will not since the robot will just read the transaction that has a “New” remark?

Hi @Gus_Fring

Yes we can build the Dispature and Performer on a single RE- Framework but we can’t make it scalable. Mean when you are going to make the process parallel you are facing the problem , if you want to run the process on different machine then every time the queue will be created and suppose there is some queue items got failed and if you want to run it again then again the queue will be created.

So that we should make the dispatcher and performer differently.

Hope you understand the points .

Thanks.

Hello @Tapan_Behera1

Yes thank you for clarification. Question on failed transaction on Queues, does the performer will retry to process those failed transactions or it will just process those transactions that has a “New” remark?

Yes @Gus_Fring the performer only pick the Queue items whose status is New and the process will be retry in case of failed if you give the no of retry value while creating the queue.

On the retry mechanism of ReFramework, will it process those transaction that has a BusinessException/SystemException or not?

@Gus_Fring only for system exception.

Thank you @Tapan_Behera1. Where can I find a documentation for Dispatcher and Performer or do you have any powerpoint presentation for this? Because I really need to know all the details about it since I will be presenting it to my team because we are planning to use queue item on every project that we will be handling. Any idea also on what is the advantage of using queue item?

Yes @Gus_Fring you can easily find it in “UiPath Academy” and also in youtube, thare are lots of videos on this.

Thank you @Tapan_Behera1 for your help

1 Like

Yes In case of failed transection performer will try again to processed it. Its depend up to you how many times you want to retry it.
There is no need to delete transaction in queue after retry it will not considered it. It will check only new

If the performer will retry the failed transaction, will the performer process it immediately or the failed transaction will be put as the last transaction to be process?

Hi @Gus_Fring
Performer retries immediately.