I have configured an Azure Logic App with an HTTP trigger and added a few actions with respect to my requirements. In the If condition false block, I used the terminate action to stop the current run for a workflow instance.
I configured the above Azure Logic App endpoint as a webhook. But sometimes the webhook receives a bad request from Azure Logic App. But in the Azure Logic App I didn’t return any response.
Can anyone suggest me Is the issue with 'Terminate' Action or not?
Can anyone suggest me Is the issue with 'Terminate' Action or not?
No, it is not with the Terminate action rather it is with the HTTP Connector that you are using.
After reproducing from my end, I have observed that the below bad request is due to
502 status code which in general is caused when the server did not receive a response.
Since you are using a HTTP Webhook connector, the flow just loops every time the condition is true, and it never ends unless the logic app receives a response in that flow. One way to resolve this is to use a HTTP connector instead of HTTP Webhook since it doesn't require a response to complete the flow rather it just calls the URL.
Related
We are using Azure Logic Apps with webhooks.
The webhooks are calling some APIs (service fabric backend - but this shoudn't matter) via Azure APIM.
On completing the specific job, the APIs call the Logic App's webhook callback - just by the book.
On the other hand, there is an IP range limitation setup on LA's trigers.
Everything was working fine until recently - for just some of our environments, sometimes the callback call from the APIs fail - apparently because the IP is not recognized by the Logic App.
First question: why (is) the restriction applied also for callbacks - those are not actual triggers?
Second question: how is it possible that the callbacks still work in some of our environments, having the same restrictions applied.
As for the IP Restrictions, the gateway through which all incoming requests are processed is the same for both the Request Connector and the HTTP WebHook Connector. While you may be using the action here, there is a WebHook Trigger that works in a similar fashion but as a trigger instead.
As for why you are getting failures at times would depend on how requests are being routed from your APIs to Logic Apps. One way to ensure access just from a single IP is to route these callbacks to APIM and let APIM forward the request to your Logic Apps. This way, all requests to your Logic Apps would be coming from APIM.
To route the callback requests through APIM, you will need a special API/Operation in APIM that will forward requests to the URL passed in the header or a query parameter.
So instead of directly calling the callback URL, you will call this APIM endpoint with the callback URL in a custom header or as a query parameter. The APIM policy for this operation will use the set-backend-service and rewrite-uri policies to forward this call to the logic apps endpoint.
I have a scenario where we have an Azure multi tenant app. Customers grant permission to our service to talk to Azure AD and search (users/AD groups) data from their Azure AD tenant using the authorization code flow granted to our multi-tenant app.
Post the Azure AD setup users login to our UI and try to search users/groups from their AAD tenant. Our service calls AAD APIs using the authorization granted to our multi tenant app.
Now if customer's AAD admin removes the access to our AAD multi tenant app by logging to their AAD console, AAD starts throwing http 403(Forbidden) when our service try to call AAD API to search users.
What http status code should be returned to UI for this particular scenario?
We want to inform the user about this so that they can restore the authorization of our multi tenant app.
I don't think returning http 4xx is a good idea. If we see from the UI prospective it's not a client error.
I think it is some kind of server error. Where our service to AAD connection is broken due to lack of authorization.
Please suggest a reasonable http status code from 5xx series or 4xx series for this scenario.
The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent
condition.
The payload is the primary way to communicate to the end user what the actual problem is.
HTTP status codes are meta-data; the target audience is the general purpose components participating in the message exchange. On the web, the payload is for the human being; the status codes are for the browser, caches, spiders, and so on.
In your case, the request is fine. In particular, there is nothing that the client can do to improve the result. So 4xx should be off the table.
The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the
requested method.
The 5xx class of status codes is a lot less specific than the 4xx class (primarily because there are no corrective actions that can be taken by the other components).
The real options available to you are
500 Internal Server Error
503 Service Unavailable
Service Unavailable is interesting in that it has a bunch of Retry-After semantics defined; you get communicate to the general purpose components an estimate of when the problem may be fixed, and then those components can judge what to do with that information.
The 503 (Service Unavailable) status code indicates that the server
is currently unable to handle the request due to a temporary overload
or scheduled maintenance, which will likely be alleviated after some
delay.
So if you think you can estimate the delay before things are working again, then 503 may make sense.
The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling
the request.
That's a perfectly satisfactory alternative. "We are unexpectedly broken right now".
Again the payload of the 5xx response can be used to communicate more specific semantics to the client.
You should keep with 4xx.
HTTP 403 is a standard HTTP status code communicated to clients by an
HTTP server to indicate that access to the requested (valid) URL by
the client is Forbidden for some reason.
In the end your application reaches a status where the current user is not allowed to do something. Depending on how technically skilled your average user is you can give her a more or less technical information. Since you seem to be able to define what particular is wrong you have the chance to tell the user about it and how she should react. In my opinion no HTTP code is needed then. There is not really a benefit of giving it to the user (except she is technically skilled). So I would go with a good explanation in the UI (and maybe a text in small font size holding the HTTP code). But this is only my opinion how I would do it.
In the end this also depends on the business process you are implementing with your software. And so I would recommend you to ask your question to the person(s) responsible for the business part behind the software (like a Product Owner). Also asking your UX designer(s) would be a good idea, if you have some.
In our deployed environment, we will have an Azure Function that is triggered via ServiceBus, which is great. But for local testing, I want to be able to make use of the following advice from the following article:
For all kinds of functions other than HTTP triggers and webhooks, you can test your functions locally by calling an administration endpoint. Calling this endpoint with an HTTP POST request on the local server triggers the function. You can optionally pass test data to the execution in the body of the POST request. This functionality is similar to the Test tab in the Azure portal.
However, when I do said post request to localhost:7071/admin/functions/NameOfMyFunction, the following exception gets thrown from within the Azure code:
System.InvalidOperationException: 'No authentication handler is configured to authenticate for the scheme: ArmToken'
For functions with ServiceBusTrigger on them, is there some Authentication header that I need to put on this test HTTP post?
For functions with ServiceBusTrigger on them, is there some Authentication header that I need to put on this test HTTP post?
It odd that you get that error. Based on my test, there is no need to add authentication header for it. I test it with VS 2017,it works correctly on my side.
The following is my detail steps, you could refer to:
1.Create an azure function app and add service bus trigger.
2.Test it with postman
post localhost:7071/admin/functions/{functionName}
body
{"input":"Service Bus Message"}
Console output:
I have an Azure bot which is all developed and working fine. It currently talks to a 3rd party workflow application via a simple webhook.
I am now trying to replicate this using Azure Logic App. I have a simple logic app that responds fine to requests from POSTMAN. However, when I set the Messaging Endpoint in the Azure Bot service to the URL of the logic app's top node (when a http request is received), I see 401 unauthorized responses from all of my channels in the bot and I don't know why. POSTMAN is using the exact same target URL and works fine.
Any ideas what is going on here?
I had a similar problem, and found the solution was to first ensure an Authorization header is being sent, and 2nd, set the value to null.
Refer: https://learn.microsoft.com/en-us/outlook/actionable-messages/security-requirements#action-authorization-header
We have API exposed to our customers through API Management. The security is handled using subscription key which is expected in "Ocp-Apim-Subscription-Key" header.
One of our methods supports polling trigger specifications, with "Location" and "Retry-After" header in response. For one of our customers we want to create Logic Apps, that would fire some actions on this trigger.
We set up HTTP trigger where we provided "Ocp-Apim-Subscription-Key" header in inputs parameters.
Here is the problem. The header is added only to the first request. Subsequent requests using "Location" url don't have this "Ocp-Apim-Subscription-Key" header, so they are rejected by API Management proxy.
I verified that header is in fact missing with some mock API, so it's definitely on Logic Apps end.
Does anyone have any idea how to resolve it?