If I have an API-only app in Azure App Service where users can send a callback URL in the request. The app sends a POST request to the callback URL upon completion.
There are some complexities in implementing calling a callback URL, for example: retries, time between retries, etc.
Is there a service, or set of services, in Azure that can help me implement a callback URL? For example, in AWS the Simple Notification Service (SNS) allows me to send a "push" to a HTTPS endpoint with retries, etc.
Without knowing what sort of context you might need for your callback, you could drop a message in a service bus queue or topic and then write a simple logic app or function which is triggered by the presence of a new message in the queue or topic.
A logic app would provide a solution with no code, only config. A function would require some very basic coding. Logic apps have built in retry features.
Here is an example which somewhat resembles what I think you're after.
Related
I am converting a monolithic application to microservices. I have set up an API Management layer and a Service Bus all within a Service Fabric. The idea is to use messages to communicate to the microservices so they do not know about eachother.
When one microservice needs information it posts a message to the service bus and it gets fulfilled and a reply is sent and correlated.
The only problem is that the API Management posts the message to the service bus and returns without waiting for a reply therefore the client does not get a response.
Is there a way to have the API Management wait for a reply?
Would this need a sort of broker service in-between?
Is it better to just have a REST layer on each microservice that the API Management could call but then the services would use the service bus?
Thanks for any help.
UPDATE:
I think the only way to have Api Management wait is use of a logic app. Not sure about this.
Any Azure experts out there?
The way APIM is behaving is actually expected.
Service Bus is meant to decouple different (micro)services and inherently doesn't have a request-response style of operation though it can be implemented that way.
Here is one way to can design/implement you system
First, for a request-response style operation with Service Bus, one way you can achieve it is by using two queues.
One for sending the request (along with some Unique ID - GUID will do) and the other for receiving the response (which again contains the Unique ID sent in the request).
Instead of having APIM work with Service Bus, call a Logic App or Function which does this for you.
Finally, waiting for the response is something that will depend on your use case.
If you have a very long running task, its best to follow the Async Pattern implemented by both Logic Apps and Functions (using Durable Functions), which return a 202 Accepted response immediately with a status URI that your client can poll for updates.
But if its a quick response (before the HTTP request times out), you could probably wait for the response service bus message and return the response then. For this, your Logic App or Function would have to poll/wait for the service bus message with the same unique ID and then return the response.
I have an Azure Event Grid topic:
https://xxx.westeurope-1.eventgrid.azure.net/api/events
Is there any way to direct clients to publish events to https://xxx.mydomain.com/api/events without getting certificate validation errors, etc.?
It would appear, after researching further documentation and speaking to Microsoft that this is currently not possible. If you create a CNAME entry in your own DNS to point to the Azure fqdn of the endpoint, certificate errors are (understandably) generated.
You could use some type of API gateway to accomplish this. The gateway would have your desired domain name and route for the public to submit requests. A service
behind the gateway would forward the request to the event topic's endpoint.
Another option, but based on the same idea mentioned above, would be to use Azure Functions. The function becomes the gateway and the client publishes to the function's endpoint. Code within the Azure Function bundles the request and forwards it to the event topic.
I'm currently using the Functions approach. My function accepts a generic JSON body, validates a few things, packages it up so it has everything the event topic needs (access keys, headers, correct properties for the event schema, etc), and sends it off to the event topic endpoint. If everything works, I send the client a 200 HTTP status from the Azure Function. If there's a problem, I send a 400 or 500 series status as appropriate.
I am not able to make the azure generic webhook function work with
authlevel keys (function/host/anonymous etc.)
I created a generic webhook function. I understand it is by default protected with function key auth level - is this correct? In such case how to change the authlevel to Host or anonymous?
Next I am calling it from a request-response logic app flow. So I get a request, call the function and then respond back with the result from the function. From the code view of logic app I cannot see any function call that is taking the code and client as parameters. So my question is why is the function call not failing. Is this happening in anonymous mode? Or is there any way the logic app is calling the function with the appropriate parameters (code and clientid) which is not shown even in the code view? Perhaps I am missing some very basic thing - appreciate any help in this regard.
In such case how to change the authlevel to Host or anonymous?
When creating a generic webhook function, you could set the mode for your trigger and the Mode notes as follows:
The mode of the trigger. "Standard" means that the request will be standard HTTP with no additional semantics. "Webhook" means that the request will be processed according to a specified webhook type.
The authLevel property in function.json file does not apply to the WebHook triggers. To trigger a WebHook function the HTTP request must include an API key (e.g. https://<yourapp>.azurewebsites.net/api/<function>?code=<Host key or Function key>). You could choose your generic webhook function, choose your HTTP trigger, then click the Documentation link for more detailed tutorials about HTTP and webhook bindings.
Next I am calling it from a request-response logic app flow. So I get a request, call the function and then respond back with the result from the function.
Based on your scenario, I did the sample flow as follows:
You just need to choose your generic webhook function and logic app would handle the authorization for you. Moreover, the API keys are stored under D:\home\data\Functions\secrets folder, you could use kudu and find them in the host.json or <function-name>.json file. Also, here is a tutorial using PowerShell to access KUDU REST API for retrieving Azure Function key. Additionally, you could add your comment here.
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..
I am creating a bot using Microsoft Bot Framework (BotBuilder) and want it to message the user when an appointment is about to begin.
I currently use Microsoft Graph api to access the user's Office 365 calendar and store the appointments. A background thread then keeps track of time and then messages the user when an appointment is about to start.
The current idea is to use Graph webhooks to notify my bot about new appointments.
My question is, would it be smarter to use an Azure service (such as Scheduler) to keep track of the appointments, and send rest messages to my bot, which will then send a message to the user?
My worry is, that as the amount of users rise, the amount of appointments and time checks will become too large, and that maybe Azure services would be able to handle it better.
This is a perfect fit for Azure Functions with a HTTP Trigger.
https://learn.microsoft.com/en-us/azure/azure-functions/functions-bindings-http-webhook
This article explains how to configure and work with HTTP triggers and bindings in Azure Functions. With these, you can use Azure Functions to build serverless APIs and respond to webhooks.
Azure Functions provides the following bindings:
An HTTP trigger lets you invoke a function with an HTTP request. This can be customized to respond to webhooks.
An HTTP output binding allows you to respond to the request.