I am about to begin the REFramework practice in Academy and I have some questions…
I want to clearly decouple the functionality of Dispatcher (adding items to queue) and Performer (consuming the queue items)
Having that in mind, my questions come to:
First question: Should I bundle the Performer and Dispatcher workflows in the same package having 2 distinct “main” files? (e.g. Main_Dispatcher.xaml and Main_Performer.xaml). I would schedule a recurrent job in orchestrator (e.g. daily at 09:00) for dispatcher (entry point → Main_Dispatcher.xaml) and set a trigger for the queue so that every time new items are added performer (entry point → Main_Performer.xaml) is executed (this is my idea).
I think that bundling both in the same project has the strong advantage of using one git repository for the project
Second question: For Dispatcher (in this case it is the CalculateClientHash process, where data is fetched from this ACME System 1 application), shall I use the REFramework template? Or is it more practical to generate a more simple Sequence workflow? Any advice?
It think it’s more practical to go with the Sequence. However since the course is about REFramework, it might be more beneficial for the learning experience to try to have the Dispatcher in REFramework template as well.
I use an edited version of REFramework, which has config in json format instead of the REFramework Excel. The json string I usually store in Orchestrator assets. Bucket could be an alternative too.
There is some approaches for this like the one you mentioned
Another one is create an input argument like “in_isDispatcher” and set it as True is your time trigger and this argument as False in Queue Trigger. This way, in your Init State you can check if in_isDispatcher is True and perform the Dispatcher workflow, sequence etc.
Also you can create multiple processes using the same project and decide which workflow to run based in input arguments, alternative for entry points
The only desvantage is that increases the effort to maintain them
For complex dispatcher (various sources or complex logic) I like to segregate it in another bot. For simple ones, most of time I use the “in_isDispatcher” strategy
Using json as asset is also great! I think it’s better than using Config.xlsx file. However (this is sth that @rikulsilva suggested to me in another post), having it as a file in the repository would also allow version control for this one as well…However I think that I’ll stick to the bucket for this one
Got it! I am going to use your strategy, I’ll have 3 files:
Main_Dispatcher.xaml: This one will get the workitems and push to queue if not duplicate (using unique references)
Main_Performer.xaml: This one will process the workitems
Main.xaml: Entry point. Depending on the value of in_IsDispatcher (True/False) it will invoke dispatcher or performer
However, I understand that if the dispatcher is “huge” (or that the combination of dispatcher and performer lead to a massive process with tons of workflows and so on) you create 2 different processes. How do you handle this from CI/CD perspective? Do you create 2 git repositories for each one?
Exactly. For us, the rule is one repo by project. Whenever we need create a new project it becomes a new repo with it own build and release pipelines. This individualization make easy to maintain the projects and it is related to componetization principle. Sometimes we have a dispatcher that can be used for more than one perfomer (e.g email attachment validation)
If you want, we can connect on linkedin (my profile), so I can share with you a little more about our CI/CD architeture
Anil_G
mukesh.singh
postwick
anjani_priya
Anelisa_Bolosha1