Its interesting to see how different Logic Apps are implemented and one of the interesting patterns I regularly see is a daisy chaining.
Lets take an example where I have a process which is triggered each night and it will import data from a file in SharePoint into a database. There are 3 separate files which each need parsing, debatching, each record needs to be transformed and the data needs to be loaded into the database.
There are loads of different ways you could implement this requirement, but one of the things id like to see is to break up the process into multiple smaller Logic Apps which work together rather than having 1 big one which does the entire thing. I think those big Logic Apps become overly complicated, untested and difficult to change. Breaking it up is a good thing but then how do you structure those broken up Logic Apps.
The common pattern I see is the below diagram.
This usually comes as a side effect of uncertainty about requirements when development starts where we build an interface to do X, but then it also needs to do Y, and then Z.
The problem here is that the interdependencies between Logic App 1 and 2 mean that they become dependent on each other and difficult to test in isolation and over time as your rolling stone gathers moss they become painful.
I feel that in most cases it is better to have a design which follows the process manager pattern. (https://www.enterpriseintegrationpatterns.com/patterns/messaging/ProcessManager.html)
If we refactor the above diagram we would have the 2 existing Logic Apps simply focus on their one job of getting a file and then loading it to the database, we would then add an additional Logic App who job is to coordinate the order which the sub-processes are executed. It would look something like the below.
In the real world I find that process manager pattern is much more reliable at helping you reduce complexity and create Logic Apps which are easier to change in the future.
Also its important to note that it does not mean in the example that Logic App A could not call another Logic App but id tend to keep those scenarios for things like helper/utility style Logic Apps or for cases where there is a genuinely required dependency between 2 Logic Apps.
I guess the take away is that it’s a good thing to try to separate your Logic Apps into those that do a specific function and those that orchestrate the end to end process rather than mixing them up. Its not always easy to do when project delivery pressures need you to get the job done.
