In this post, we are going to discuss some troubleshooting strategies that you can use when developing custom code solutions in Azure Logic Apps (Standard).
Strategy #1 - Local Debugging
Local debugging is a natural way to troubleshoot a particular use case. You can enable this by starting both the Azure Logic Apps debugger and subsequently the .NET Functions debugger. Using this approach allows you to step through code, regardless if it is a workflow or custom code. Please see the following video for a demonstration of this capability.
When using the debugger, you will find all of the capabilities that you would expect including the ability to Step Over, Step Into, Step Out and Continue. We also can view the values of variables in the Variables pane in the upper left hand corner.
Strategy #2 - Run History
If you deploy your custom code to Azure and you encounter an error, you will have visibility that it has failed. However, in the Azure Portal you will not see a detailed stack trace. This is deliberate. Much like you call an API, you would not expect the API to return a verbose stack trace. It is not a good security practice to do so.
In this particular scenario, what you can benefit from is using the inputs that were passed to the local function and then using that data in combination with Strategy #1 to further troubleshoot.
Strategy #3 - Application Insights
We recently announced Application Insights Enhancements for Azure Logic Apps (Standard) which allows customers to emit workflow related telemetry to Application Insights. In the context of custom code, we can take advantage of Application Insights to get additional information related to custom code failures.
Within the exceptions table, we will find a column called innermostMessage that will provide verbose information related to a custom code failure.
In the following image (which is content from innermostMessage column), we can see that a System.Exception was raised and on the following line can see that it occured within the Run method and even specifices the line of code that it ocurred on (32). We can subsequently look at our code on line 32 to determine what our code was doing. We can subsequently use strategies #1 and #2 to further resolve.
I hope this post has provided you with some ideas on how you can troubleshoot custom code. If you have other ideas/needs on how we can improve this experience, please add them in the comments.
Video Content
If you would like to see this content in video form, please check out the following YouTube video.