Clarity needed on Dispatcher / Performer pattern

Need some clarity on how to institute a dispatcher. It’s a fairly simple process. I simply am monitoring an email box, when an email arrives with attachments, I save the file paths to a queue.

  1. Right now it’s 1 queue item per attachment but I wonder if it should be 1 queue item per email with one property would be a array of string paths to the saved attachments.

  2. Where to put the dispatcher? I am using the REFramework for the performer. I decided to add a state between the “init“ state and the “get transaction” state the runs the dispatcher since the dispatcher and performer share config items it seems to make sense as I just pass my config dictionary in. This is a simple dispatcher and not high volume.

  3. Can you have multiple processes or entry point per project? If I decide to separate the dispatcher and performer, doesn’t that mean 2 separate projects?

TIA
John

Hi, in your case no need to put extra state between init and get transaction states
In the ‘init’ state there is a sequence with name ‘if config file is nothing’ , you can add your dispatcher workflow inside this sequence. This sequence runs only once (In first run of each job )
The problem if you put another state for dispatcher between init and get transaction data states , if any error occurs in the process transaction , the tool goes back to init again and load queue (dispatcher ) gets perform everytime , which is wrong

Another query answer is , if there is multiple filepaths in array of string , then use for each activity for that array of string and put ‘add queue item’ inside the for each

Thanks Vinay,
I see your point, but I don’t think that would happen in my case. Part of the dispatcher logic is after an email is processed, it moves the email to a different folder. If the dispatcher is run again, the already processed email will not be in the folder. To me it is making more sense to totally separate dispatcher and performer

Hi @joriente Can you please elaborate on the complete process what exactly dispatcher and performer doing individually.

Not sure it relevant as the question is more about best practices but the dispatcher is taking attachments from an email and the performer is running them thru OCR to extract the data. I did wind up separating the dispatcher and performer.

You were mentioning that “Part of the dispatcher logic is after an email is processed”. Just curious about the scenario of how a dispatcher logic works after the performer is processed.

So the dispatcher reads an email box, detaches any attachments, creates a queue item, then moves the email to another folder do its not processed again. The performer uses the transaction items from the queue to do its work. The dispatcher and performer really don’t interact other than writing and reading from the same queue. I believe that is the principle behind the pattern