Who Should Develop Logic Apps?
Logic apps are a simple and easy tool to use to design and create any integration for any size solution, so the question is, who should develop logic apps? I would say anyone who has some knowledge of how applications are architected and talk to each other. It all depends on how much experience the designer has as to how complex the workflow can be. In my own experience, workflow development has not been a difficult issue, but some of the blockers I have come across relate to the lack of integration into other systems or custom functionality required to complete the workflow.
For example, whilst working on a solution, I was unsure how we could integrate authentication into the flow. The problem I faced was getting authenticated against many AAD instances and then completing the flow. How can you keep the data secure and reuse the tokens? I developed an Azure Function to keep the configuration separate from the calling action and give me greater control over the implementation of the authentication mechanism. I also was able to reuse the same function in other child workflows.
Could Logic Apps be Part of a Domain Solution?
I came across the term Domain Driven Development (DDD) over a decade ago, but never got the opportunity to deep dive and develop a solution with the methodology, so my experience with DDD is very limited. From what I have experienced, using DDD with cloud technologies, I would say (in answer to the question “could Logic Apps be part of a domain solution?”) yes, it’s certainly possible. Especially around handling Azure Service Bus messages from one domain to another or handling interactions from an external source, whether its via web API or WCF. The ability to create custom functions can overcome any specific requirements to connect systems together.
So far so Good?
We covered how to develop Logic Apps, and the benefits, but what are the downside in its current form?
Provisioning and Deployments
I have highlighted from the Workflow Definition Language, connections are generated and hardcoded to the workflow, so what do you do if you want to deploy the workflow into multiple environments? This is where provisioning a workflow can be a painful process. During the development of the last project I worked on, the team discovered an issue with tokenising connection strings, specifically, how to extract the correct API connection string for a specific resource against an environment.
Logic App API Connections are added to workflow and the resource group with the following format <Connection Type><Number>, for example ServiceBus1, ServiceBus2. This is not particularly useful when you wish to provision multiple connections to similar resources.
The best way to add a tokenised connection string is breakdown the connection string into tokenised parameters and variables. An example of the tokenised parameters and variables is shown below: