Dispatcher in REFramework

Hi,
Can I include Dispatcher in the init state of REFramework in the first run block?
Are there any disadvantages of doing this?
Dispatcher code does not have to be outside REFRamework correct?

Thank you,

Thank you,

Hi @A_Learner

You can include the Dispatcher process in First run block of Init State block. If you are addign items to the queue, you can add the process it that block.

Hope it helps!!

Hi @A_Learner

Of course you can have both in the same project, however, this is not a good practice since it compromises the code being heavy, not very scalable, and difficult to maintain in certain projects since it makes it confusing, not to mention that in process testing issues it can be more time-consuming and complicated to reach results.

Regards

@fernando_zuluaga
Thank you for listing all the disadvantages. Please suggest good alternatives?
Is Dispatcher as a separate program outside REFramework good? Any other good ways of implementation with REFramework?

Thanks a lot,

Yeah, that is the common use of dispatcher-perfomer, having two separated process

Hi @A_Learner

We can develop the dispatcher and performer in different codes.

As you said we can develop the dispatcher code in first run in init state.

But based on your process condition select the one which suits.

If you are triggering the performer process as queue based triggers in that case you have to split the dispatcher and performer codes. When the dispatcher adds the data to the queue in that time only the performer triggers.

In case you want to use time based triggers you can simply develop a single code by developing the dispatcher code in first run in init state.

Note : when using the dispatcher in first run then we have to handle the exceptions properly and maintain the logs with more clarity by showing the difference between dispatcher and performer. If got any exception and execution failed, then you have to know where the exception occurs by using logs only.

Hope it helps!!

1 Like

@A_Learner

If the dispatcher work is to only read data from excel and dump into queue or relatively simple like this…then we can go with a common dispatcher and performer…to avoid complexity…for yhis in init start → if first run → you can add the code with one single xaml invocation to read and add the data using bulk add queue items to queue

We go with a separate dispatcher when there is quite a process involved or some logic involved in dispatcher to maintain the code separately for both which makes it easy to maintain…for example…if dispatcher needs to login to a system, get each separate data and then add the data to wueue after doing some manipulations and filtering then separate dispatcher is preferred

So decide on either based on the complexity and amount of work needed

Cheers

1 Like

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.