Trigger used - when message is received in a queue(auto-complete)
When HTTP action fails, i need to re process the whole flow with same queue item/queue message.
Is this possible, if yes any resource or any workaround would help
Thanks in Advance
You can trigger your logic app with the same queue message, just add a condition action to determine weather your Http action is success or failed based on the Status code.
I designed a logic app workflow for you:
Assuming that your Http action returns a success code of 200, you can continue to process the original process, if not, you can use the Send message action to resend the received message to the queue, which can trigger your logic app again
Related
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.
Logic Apps support calling other Logic Apps with a special action:
They support something they call the "asynchronous pattern" through this option:
where the called Logic App returns a 202 (Accepted) and the calling Logic App will implicitly poll the same trigger URL until completion is signalled using 200 (OK).
How are you supposed to implement this pattern in the called Logic App? I can send a response, but once that's happened, I can't send a response again. Or can I? If so; how? How do you specify the polling URL?
In the response action, you could enable 'Asynchronous Response'. See the dialog below
[]
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.
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.
Is there a way to send http request (to a specific url address) each time i receive email (Google account), with the content of the email received using Google App Engine?
As per your question, it seems that you already have an Incoming Email Handler in your App Engine application.
If the above is true, then in the Incoming Email Handler, you can parse out the message and if it meets your condition for invoking the http request, then you can definitely do that. You can use the URL Fetch service for the same.
One design decision you might want to do is whether you want to keep all your URL Fetch code inside of the incoming Email Handler or you want that to be handled externally via a Task Queue. In that case, I suggest that you can use the Task Queue to create a task when an incoming email comes in to your handler. Then the Task Queue logic can take care of one or more things, which includes invoking the HTTP Service, as you wanted.