Logic App Response action to return status code reason - azure-logic-apps

When a Logic App uses the Request trigger to receive inbound requests and the Response built-in action to send the response back to the caller, the Response action must include the Status Code - 200, 400, 401, etc.
Along with the Status Code, I'd like to be able to send the reason of the status code, in the same way it can be done in the API Management by using the set-status policy.
Is it possible at all to specify the status code reason in the Logic App Response action?

Is it possible at all to specify the status code reason in the Logic App Response action?
No it is not possible using Logic Apps.
But if its business need, as an alternative, You can define it in the response body at your client application and you need to pass the response body as a reason.
You can submit a feature request here in more detail.

Related

Post request to logic app from action group

I am trying to send an email alert when certain conditions are met by creating an alert rule in Azure monitor. For this, I also created an action group which tells what action to take when trigger conditions are met. In logic app I am using dynamic content which will come through POST http request, but in action group on azure portal I don't see any option to populate those parameters for POST request. Can anybody help me how to make a post request with request parameters to logic app in Azure portal?
There is no need to send parameters from Action group to logic app. When an action group is tested or the condition satisfied, automatically details will come in Http post request. Using expressions, you can retrieve details from Http post request to use in next action.
I have reproduced issue from my side. Below are steps I followed,
Created Action group in Azure monitor and added action type as Logic App.
Created logic app as shown below,
In Send Email action, I have used dynamic content from Http request trigger as shown below,
When I test action group, It triggered logic app and run details are shown below,
Output of Http trigger:
Send email Action:
5. As You can see in above picture, I am not getting values in Send email action.
So tried with writing expression instead of using dynamic content to get data from http trigger as shown below,
triggerbody()?['data']?['essentials']?['monitorCondition']
triggerbody()?['data']?['essentials']?['fireDateTime']
7. Tested logic app again and getting values as shown below,
Refer to this MS Doc for more information

How to let users know flow has completed?

I have a flow setup in logicapps that starts with a http response, the user enters data in an excel sheet and clicks a cell/hyperlink which kicks things off. They receive a response saying the flow has started and was wondering how I could update the response once the flow has completed (either successfully or if it has failed). I’ve only created basic flows before and when googling I’m not too sure what I should be searching for but cant find any examples of what I’m trying to achieve, any ideas?
Here is one of the workarounds that might work. You need to add the response at the end of the flow. Consider my logic app as a sample. If my "Var" is yes then in response it sends Success as a response to my postman and if it is other than yes it sends Failed. Here is my logic app for your reference:-
Result:
In postman
In your case, you can use some properties to define if they got classes or not and then use the same condition connector to send the response.

Retrieving the response code or body to use as a condition to send another request within tryMax

I have this request that is querying my service which is inside of tryMax.
The access token to authenticate a request expires every five minutes and is generated at the beginning of the simulation run as ${token}
Is there a way within the tryMax to send another token generation request that will update the expired ${token} (Authorization header value) if the response code is 401 or the response body contains information about the request not being authenticated. Then retry the request before tryMax moves to the next iteration?
I have tried setting status code as a session attribute, however the request is not being sent and the token doesn't update, I tried doing a .doIf after the request exec, putting a doIf inside it's own exec and even playing around with transformResponse, all with no success.
Any suggestions how to approach this?
you can do something like what is outlined in
Gatling (performance test):how to perform task in background every x-minutes
However - is this really the scenario you want to model? How does the client you are simulating handle the 401? The scenario you are proposing only works if the client is in charge of manually handling its own refreshes.

Shopify Webhook getting called multiple times

In my shopify store I have setup an order creation webhook. The webhook points to a Cakephp action URL which receives the data from webhook as following:-
$content = file_get_contents ( "php://input" );
After that it is saving this order data to the app database as:-
$orderData =array('order'=>$data['order_number'],'details'=>$content);
$orders = new Order ();
$orders->saveall($orderData);
Now the issue is that for each single order created the webhook is getting invoked multiple times. Although it performs the necessary action in the first attempt, yet Shopify is not able to identify the call success and is getting it invoked again and again until the limit reaches. After the limit is reached the webhook is getting deleted from the store.
My question is that do we need to send any type of status or response to the webhook call after it performs the necessary action. Because it is not very clear from shopify webhook documentation. They state that webhook call success is determined from HTTP status 200. How can I check what is the status returned by a webhook call? How can I make sure that Shopify is informed of webhook success through my app code and it does not invokes further calls to the webhook?
Yes, you need to send a 200 response to Shopify within a short time 5s. Otherwise, Shopify will send a request in a short time.
The official guide suggests that you store the webhook data and process it with a queue, thread, or whatever ways you preferred. After that, you return a 200 response to Shopify immediately.
IMO, if there are many webhook requests sending to you, it's better to separate the webhook receiver from your app server. You can do it with AWS Lambda or docker swarm so that the webhook requests won't break your app server.
Source:
Time limit: enter link description here
Webhooks with AWS Lambda: enter link description here
Just to clarify for others, you have to explicitly return a 2XX HTTP code or it'll retry 19 times over 48 hours, then delete your webhook if it exceeds that.

duplicate ajax calls in angularjs

I am using express-jwt to build a restful api. Now the client is making duplicate ajax calls, for the first one the initiator is angularjs and for the second one the initiator is other. The first one gets 204 as the response code and the second one gets 200 as the response code. I tried to debug to get to the source of this duplicate requests, but I am not able to.
Below is the header details for the one with 204 status code
Below is the header details for the one with 204 status code
Can any one suggest what could be the issue?
The first call is OPTIONS type. That's a pre-flight call which a browser sends if the page and api are not on same domain.
The purpose of this call is to deal with CORS. Backend usually needs to send the allowed request method types (GET, POST etc.). The browser will then send the real call if the desired request type is among those returned.
Here's a sample of the response headers.
You can ignore it for all intents and purposes. It does not contain any normally useful payload or return data.
Take a look at AJAX in Chrome sending OPTIONS instead of GET/POST/PUT/DELETE? for more info.
Those two requests are different one is OPTIONS and other is GET.
For cross-domain requests, setting the content type to anything other than application/x-www-form-urlencoded, multipart/form-data, or text/plain will trigger the browser to send a preflight OPTIONS request to the server.
You need to handle in the server when the request method OPTIONS , then you need to exit with out processing.

Resources