Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I talked about some of the essential best practices you should have while working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today I’m going to speak about another critical Best practice, Tips, and Tricks that is often overlooked: learning from failures.
#7 Learn from failures
It is important for you from time to time to do an assessment of your existing Logic Apps, especially when they failed. Not only analyze the business process to see what can be improved but you should also analyze the run history of our Logic Apps and learn from the failures or mistakes that are happening.
Based on my long experience in Enterprise Integration, I can certainly say: Failure is critical! And we need to understand why is failing and address that issue so it doesn’t occur again.
And don’t be offended, we all make mistakes, and failures and errors will always exist, whether they are unplanned or not addressed in the initial requirements, a bug committed by the developer, or simply because certain external parts are offline or having problems. Here the idea is to be transparent, honest, concrete, bluntly trying to find those responsible or assign blame and really make our Logic Apps more and more robust to errors or failures, progressively learning from failures. In a way as with aviation. Unfortunately, with each accident, aviation becomes safer because whenever this happens, a thorough analysis is carried out to discover the causes of the accident, and then new measures are applied so that this does not happen again.
If they found that a component without redundancy broke down for sure they will implement a rule forcing companies to add a secondary component to avoid this to happen again. The same can be applied to Logic Apps, if a system is not always available we may need to implement a reentrant mechanism to handle these situations, if possible. For example, sending the message to a Service Bus queue to be processed later.
In some cases in traditional programming languages like C#, we call it defensive code:
Note: maybe this is not the best C# code but that is not the goal here.
In this case, when we try to read something from SQL Server, we don’t assume that the query brings always records, or at least we shouldn’t, we first see if there are any records to read and only then we try to read them.
So, why not apply the same principles and best practices to our Logic Apps?
One time I was passing by in the hallway at DevScope for coffee and I noticed that one of my colleagues was working on a Logic App. Out of curiosity, I went to see what he was doing and after a few minutes, I asked him to show me. I immediately notice in the run history that from time to time the Logic App was failing so I ask him: why this is failing on a regular basis? He replies to me that “this is normal, there are no records on the SQL so it fails“!
Again, Failure is critical! If it is failing due to expected behavior, then you must redesign your business logic, so it doesn’t end up in a failure status!
And to fix this sample above is simple as adding a condition to check for example:
- If a particular field exists or contains certain value:
- first(body(‘Exec_SP_-_GetLastExecutionTime’)?[‘resultsets’]?[‘Table1’])?[‘LastRun’]
- Or if the Table1 structure is empty
- empty(body(‘Exec_SP_-_GetLastExecutionTime’)?[‘resultsets’]?[‘Table1’])
This is just a simple case, but I think you got the point!
Stay tuned for the following Logic App Best practices, Tips, and Tricks.
