Think of the “Controller Flow” as the main entity, handling the overall state of the process and being stateless itself. Compared to software development practices, this could be seen as the main routine of your application.
Stateless because the state is managed a JSON message object, which we store in an Azure Storage Queue. The controller picks the message from the queue, then parses and processes the content. Based on the content and the application logic baked in the controller Flow, it knows what to do next.
So, the controller is not storing any state directly, it only processes the state message, generates new state object and calls workers to do stuff. This means that we don’t have any long-running operations and therefore no risk of facing the deadly 30 days Flow run timeout limitation and some of the other known challenges, existing in the service.
Thanks to encapsulation of all state logic in the controller, we now have a kind of separation of logic and “code ”. This allows us to create dedicated “Worker Flows”, carrying out specific process steps or activities. These are small Flows, with a dedicated purpose. Kind of like a function in grown-up software development.
Dr. Flow is calling them “Service Flows”. In the context of a queue architecture, I thought “worker” is a better fit. Workers, follow the same pattern as the controller, pick up messages from an Azure Storage Queue, parses the content and carries out work. Workers report their activities and process step outcome back to the controller, which maintains overall state and fires next actions in the process chain.
From an architecture point of view, this pattern is extremely powerful, generic and allows us to bring Flow to the Enterprise level. Think of multiple controller Flows, for groups of workers.
Sample Implementation
Beauty often lies in simplicity. So, let's see how it's done. As you can see based on the sample implementation, this Flow has a very clear and easy to read and understand structure and is scalable in all dimensions.
Please read the implementation guide for detailed reference on the whole implementation of a State Machine Pattern in Flow: > https://www.thatmarcelhaas.com/blog/microsoft-flow-state-pattern-implementation-guide-2-8
Trigger
Azure Queue Storage
The controller Flows is triggered if a new message (JSON Object) is added to an Azure Storage Queue "approval-controller".
The object can be added by any web-client, capable of talking rest. In our scenario, we use kind of a "launcher" Flow, as we want to approve per selected document in SharePoint and make use of the Flow Launch Panel, to collect relevant data from the user. This launcher Flow put the JSON message object in the "approval-controller" queue, where the Controller Flow sits on, parses the message and takes action.
Connectors
The Controller Flow in it's basic implementation, need the following connector:
Azure Queue Storage
Actions
We actually don't need a lot of actions, to make this pattern work in Flow. This makes it very easy to implement. This is our minimum action set:
Variable
Switch(es)
Add Message to Storage Queue
Delete Message from Storage Queue
Content Index
There is a lot more of content available to you: