Skip to main content
Version: v6.0.0

Exception Handler

motivation

Most who have worked with Logic Apps is familiar with the error An action failed. No dependent actions succeeded. This is a very generic error that offers no clear information on what went wrong.

Invictus provides an Exception Handler Framework component that can be used to retrieve the actual error message from an Azure Logic App and optionally translate this to a human readable text.

Access Rights

The Exception Handler component requires the role Logic App Contributor and additionally Website Contributor (for Logic App Standard) to operate correctly. These must be assigned on the Exception Handler component to the resource group where the Logic Apps are located.

Resolve Azure Logic App exceptions​

The Exception Handler component has as single /api/ResolveException endpoint to request inspection of failed Azure Logic App workflow runs. Based on the type of Logic App, the request looks different.

If you want to resolve the exception of a Logic App Consumption use the following body:

JSON propertyRequiredDescription
WorkflowRunIdyesThe ID of the failed Azure Logic App workflow run.
WorkflowNameyesThe name of the Azure Logic App to inspect.
SubscriptionIdyesThe ID of the Azure subscription where the Logic App is located.
ResourceGroupNameyesThe ID of the Azure resource group within the subscription where the Logic App is located.
Request example
// POST -> /api/ResolveException
{
  "WorkflowRunId": "08584773878007282344320782622CU00",
  "WorkflowName": "cdt-dev-we-somelogicapp",
  "SubscriptionId": "fb0519a2-b69f-4cdf-97ff-19735685b5b9",
  "ResourceGroupName": "some-resource-group",
  "Type": "Consumption"
}
Response example

The function will respond with a list of errors for the failed actions, for example:

// 200 OK <- /api/ResolveException
{
    "Status": "Failed",
    "Code": "InvalidURL",
    "Description": "Http request failed with status code 'HostNotFound' and status message: 'No such host is known.'.",
    "Errors": [
        {
            "Code": "InvalidURL",
            "Description": "Http request failed with status code 'HostNotFound' and status message: 'No such host is known.'."
        }
    ]
}

Stored Azure Logic App exceptions translations​

💡 The ExceptionHandler function makes use of the RegexTranslator component to translate the original error from the Logic App.

🔦 To show what we mean by translating the error to a human readable text let's take the following example.

We have a Logic App that used to return the generic An action failed. No dependent actions succeeded error, by using the Exception Handler we have now improved this to the actual error which is Http request failed with status code 'HostNotFound' and status message: 'No such host is known.'..

However, we have a business user that does not really understand what this means. By using the translation functionality of the Exception Handler function we can translate this error to something like Application is not reachable which the business user can clearly understand.

These translations must be set up in the RegexTranslator table in your Invictus storage account. Translations need to be added in the table as follows:

PartitionKeyRowKeyMatchPatternOutputPattern
logicappname.actionnameAny RowKeyThe pattern to be matched in the errorcode(YourTranslationCode)The output translation pattern
Translation examples
PartitionKeyRowKeyMatchPatternOutputPattern
cdt-dev-we-somelogicapp.CallHTTP1No such host is knowncode(Availability)Application is not reachable
cdt-dev-we-somelogicapp.Create1cannot be evaluated because array index '0' cannot be selected from empty arraycode(Account)The accountid for the debtor could not be found
cdt-dev-we-somelogicapp.ParseJSON1Invalid JSON schema type: intcode(Data)The field is not an integer
cdt-dev-we-somelogicapp.ExecuteStoredProcedure1Procedure or function 'upsertData' expects parameter '@Ordernumber'code(Data)Ordernumber is not supplied but is required

By using the translation functionality we will get back the following response:

{
   "status": "Failed",
    "code": "Availability",
    "description": "Application is not reachable",
    "errors": [
        {
            "code": "Availability",
            "description": "Application is not reachable"
        }
    ]
}
Ignore Azure Logic App errors

By using the translation functionality we can also ignore errors. This can be very useful for scenario's where Logic Apps can generate an error that is not relevant to the business and the flow can be seen as successful.

Let's take an example where we have a Logic App that picks up a file from a network location and after it has been published will delete the file. We have seen situations at customers where this delete action will fail because the file has already been removed by another instance of the Logic App, this error can be safely ignored since the message is processed anyway.

To achieve this we can configure the translation as follows:

PartitionKeyRowKeyMatchPatternOutputPattern
cdt-dev-we-somelogicapp.DeleteFile1There is no file with nameignore

This will result in the following response:

{
    "status": "Succeeded",
    "code": "NoCodeSpecified",
    "description": "",
    "errors": []
}

How to implement in your Azure Logic Apps?​

A good way to implement the Exception Handler is to create a common exception handler Logic App that will call the Exception Handler component and return the response. This common Logic App can then be called by all other Logic Apps, this is a nice way to centralize your exception handling functionality.

tip

use a webhook to call the common exception handler Logic App so that if anything fails in the common Logic App you can resubmit this and return the response asynchronously.

Logic Apps setup with Exception Handler

Logic Apps Exception Handling example

logic-app

The code for the Scope Exception Handling is shown below, pay attention to the Terminate action as this uses the information from the Exception Handler component and is nicely shown in the Invictus for Azure dashboard.

dashboard

"Scope_ExceptionHandling": {
  "actions": {
	"ResolveException": {
	  "inputs": {
		"subscribe": {
		  "body": {
			"callbackurl": "@{listCallbackUrl()}",
			"logicApp": "@{workflow().name}",
			"resourceGroup": "@{parameters('resourceGroupName')}",
			"run": "@{workflow()['run']['name']}",
			"subscription": "@{parameters('subscriptionId')}",
			"correlationId": "@trigger().clientTrackingId"
		  },
		  "method": "POST",
		  "uri": "[listCallbackUrl(resourceId(variables('exceptionHandlerResourceGroupName'), 'Microsoft.Logic/workflows/triggers', variables('exceptionHandlerLogicAppName'), 'manual'), providers('Microsoft.Logic', 'workflows').apiVersions[0]).value]"
		},
		"unsubscribe": {}
	  },
	  "runAfter": {},
	  "type": "HttpWebhook"
	},
	"Terminate": {
	  "inputs": {
		"runError": {
		  "code": "@{if(equals(body('ResolveException').Status, 'Failed'), body('ResolveException').code, null)}",
		  "message": "@{if(equals(body('ResolveException').Status, 'Failed'), body('ResolveException').description, null)}"
		},
		"runStatus": "@{body('ResolveException').Status}"
	  },
	  "runAfter": {
		"ResolveException": [
		  "Succeeded"
		]
	  },
	  "type": "Terminate"
	}
  },
  "runAfter": {
	"Scope": [
	  "Failed",
	  "Skipped",
	  "TimedOut"
	]
  },
  "type": "Scope"
}

Customization​

Affected Bicep parameters

The following Bicep parameters control the inner workings of the Exception Handler component. See the deployment of the Invictus Framework to learn more.

Bicep parameterDefaultDescription
exceptionHandlerScaling{ cpuResources: '0.5', memoryResources: '1.0Gi', scaleMaxReplicas: 1, scaleMinReplicas: 0, concurrentRequests: 10 }The Container App options to control scaling. See scaling rules in Azure Container Apps.
exceptionHandlerFunctionNameinv-${resourcePrefix}-exceptionhandlerThe name of the Azure Container App to be created for the Exception Handler component.