HTTP Actions and 202 Responses

When calling a Function App that returns a 202 (Accepted) Status Code I found my HTTP action in my Logic App was returning a status code of 405 with the a message of “The HTTP ‘GET’ method is not supported by the ‘GenericJsonWebHookReceiver’ WebHook receiver.”.

This seemed a bit odd because I had tested my Function App using the exact same request using Postman and it was returning a valid 202 response. After reading a bit more about HTTP Actions ( the section on Asynchronous Patterns gave me the answer. To disable the asynchronous behavior previously described, set operationOptions to DisableAsyncPattern in the action inputs. In this case, the action’s output is based on the initial 202 response from the server.

Having made this change to the Logic App the server response was accepted and considered a success.


Azure (not so) Logic Apps

As with any (relatively) new Azure  app there is always pain mixed in with the pleasure. The simplicity of the Logic Apps Designer can throw in curve balls that can only be handled in the Code View.

A good example of this is the SQL -Get Row connector and what happens if the row is not found.


The default logic here is to look for the row and then progress if the Row Id can be matched, and in the Designer view this is all handled for you. But what if you want a condition where you want to handle this failure.  The Designer allows us to put in a check for the failure, although you have to edit it in Advanced mode. The problem is that the Designer does not let you allow ‘Failed’ as a valid option.


In the Designer view this is not obvious (at the moment) so you need to switch to the Code view. The default runAfter option (for the Condition) is set to ‘Succeeded’

"runAfter" {
"Get_row" : [ "Succeeded" ]

So what we need to do is add ‘Failed’ as a valid option

"runAfter" {
"Get_row" : [ "Succeeded", "Failed" ]

The ‘Get row’ is then able to succeed by failure when no matching row is found and the Condition check will be evaluated correctly.