I have created an API in Azure API Management to get data from a backend API.
The result from the backend API is paged, including a 'next' url in the response which must be used for the next request.
How to handle this 'next' url, in order to concatenate all paged responses and return the total of all paginated responses as one single response through Azure APIM?
That would be quite complex policy, but could be done by combining retry and send-request. In short keep retrying request every time with next url and concatenating results as long as there is next link in response.
Related
I am working on creating an API to send google form responses to a notion database. I want to send a response to the database each time a form submission is completed, however, the forms API only has two methods for retrieval retrieving all the responses at once or a specific response by the id.
https://developers.google.com/forms/api/guides/retrieve-forms-responses#node.js
How would I create a trigger, with either google app scripts or something else to send this data to my API endpoint.
I have been testing around with the Azure App Services and got this error
App Service Plan Create operation is throttled for subscription.
As I understand I created too many apps in a short period, how long until I can create a new app again?
Thank you
I began receiving this error, but without the Retry-After property in the response. After working with Azure support, it turns out newly-created subscriptions take a while to fully allocate in the background. We had to wait 48 hours before the throttling error would go away, and that was what Azure support validated with us.
Once the 48 hours passed (and the new Azure sub was presumably complete in its creation), we no longer received the errors.
As I understand I created too many apps in a short period, how long
until I can create a new app again?
We dont have any ideal time that how long until you have to wait to create a new app again.
Throttling happens at two levels. Azure Resource Manager throttles requests for the subscription and tenant.
When you reach the limit, you receive the HTTP status code 429 Too many requests. The response includes a Retry-After value, which specifies the number of seconds your application should wait (or sleep) before sending the next request. If you send a request before the retry value has elapsed, your request isn't processed and a new retry value is returned.
You can determine the number of remaining requests by examining response headers. Read requests return a value in the header for the number of remaining read requests. Write requests include a value for the number of remaining write requests.
You refer this documentation,on how to Retrieving these header values in your code.
I am working to pull some objects from an Rest API endpoint where the response is restricted to send only 500 items in one call.
I am doing it in azure synapse and unable to get the specific header value which need to be passed into copy activity to continue the loop until all the data is retrieved.
Can someone help in this ?
I am trying to use Azure Logic Apps to read data from one of the Salesforce objects which has huge number of records. The Salesforce connector fetches the record and returns the pagination link as #odata.nextLink. But when I try to use a JSON parser to read the value it’s coming as null.
I tried to access the nextlink in a browser but it requires authentication. What authentication do we pass here ?
I would like to use an until action to iterate till I get a next link . So how do I check the condition for the until loop ?
nextLink doesn't look like core Salesforce thing, it might be the OData connector preprocessing the results for you. You'd have to consult the documentation for the connector (if any).
Salesforce's REST API will return field with nextRecordsUrl if there's next page of results, you'd call that in loop until the field disappears. You'd call it like any other REST API resource available after login, by passing Authorization: Bearer <sessionId also known as accessToken here>. Again - probably the connector abstracts this away from you. Don't think you can send headers like that in browser, you'd need curl, Postman, SoapUI or similar http client.
If you don't get better answer and documentation is scarce - consider using raw REST API. Or Azure Data Factory has an almost-decent Salesforce connector?
https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_query.htm
I wanna build a small workflow using Azure Logic Apps that contains an "Approval" step, which is simply an API call in my own system, similar to office 365 approval connector.
However, from what I found on the internet, the only way to make a long running task in Azure Logic Apps is to use Webhooks.
In Webhooks, I could not set a value to the parameter I created "Bool-Approved".. so, How can I check it later in a condition step?
The other possible solution maybe is to use Swagger to have an "Bool-Approved" parameter. However, it does not support long running action!
What's the possible solution for me?
As you mentioned, the way to do it is to use the Webhook action, and for that you need to implement the Subscribe/Unsubscribe pattern described here. The webhook action will allow you to get any payload (via an HTTP Post) from the instance-based webhook you are subscribing to.
The points below are a summary of this blog post:
https://www.mexia.com.au/correlation-identifier-pattern-on-logic-apps/
To implement the Subscribe/Unsubscribe Webhook pattern you need to consider:
Subscription store: A database to store the unique message Id and the
instance-based callback URL provided by the webhook action.
Subscribe and Start Request Processing API: this is a RESTful API that is in charge of starting the processing of the request and storing the
subscription.
Unsubscribe and Stop Request Processing API: this is another RESTful API that is only going to be called if the webhook action on the main workflow times out. This API is in charge of stopping the processing and deleting the subscription from the store.
Instance-based webhook: this webhook is to be triggered by your own custom approval event. Once triggered, your webhook is in charge of getting the instance-based callback URL from the store and invoking it. After making the call back to the main workflow instance, the subscription is to be deleted. This is the webhook that is in charge of sending the payload you require to the waiting webhook action in your Logic App.
The subsequent actions will be able to use that response body, so you can implement your conditions, etc.
You can follow the blog post mentioned above to see a detailed example and get more details on how to implement it.
make you api return HTTP code 200 if the response if "ok" and 400 if the response is "not ok". This way you can force logic app to behave the way you need it to behave..