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.
Related
I am using service that can only send messages using webhook. The only thing I can set up in that webhook are HTTP endpoint, user name and password (you can see it on the screenshot below). I would like to send messages to my event hub, but I don't know how to find its HTTP endpoint. The only thing I could find was SAS Endpoint.
Event Hubs offers a REST API that allows you to perform a subset of the operations supported by its AMQP API. Publishing basic events via REST is possible and would use the endpoint: https://{servicebusNamespace}.servicebus.windows.net/{eventHubPath}/messages.
The full set of documentation for the REST API can be found here, and the specifics for sending events here.
Scenario
When business transactions are performed, we're supposed to make that data available to end clients.
Current Design
Our web app publishes transaction messages are added to a topic on the Azure Service Bus.
We expose APIs to clients through which they can consume the data from those transactions.
Upon calling these APIs, we read the messages from the Subscription and return it to the client.
Problem
We want a guaranteed delivery - we want to make sure the client acknowledges the delivery of the data. So we don't want to remove the message from the subscription immediately. We want to keep it until the client acknowledges it.
So we only want to do a "Peek" instead of "Receive".
So the client calls the first API, to get the data, where we do a Peek.
And once the client has received the packets, the client would call a second API, to acknowledge.
At this point, we want to remove the message from the Subscription, making it Complete.
The current design of the Service Bus Message Receiver is that, a Complete can be performed only using the same Receiver instance that performed the Peek, as per the documentation, and we also observed the same when we tried it out.
Both the APIs, are two separate APIs and we cannot do the Peek and Complete using the same instance of the Receiver.
Thinking about options to somehow make the Receiver as a Singleton, across APIs within that App Service.
However this will be a problem when the App Service scales out.
Is there a different way to achieve what we're trying to do here ?
There is an option available in Azure Service Bus to defer messages. Once a message is deferred, it can be received with the help of it's sequence number.
The first client should receive the message and instead of completing it, it should defer it and return it.
The second client (which has sequence number) can receive the message from the Subscription. Refer here for more details.
Another option would be to not use a Service Bus Client on your backend and instead your clients could directly work with Service Bus using its Service REST API (assuming they can't use the AMQP client if I am understanding your scenario correctly).
There are APIs to
Peek-Lock
Renew Lock
Unlock
Delete (Complete)
You could also proxy these requests if you'd like using your backend itself or a service like APIM if you are already using it.
PS: Cross posting the answer for the same query on the MSDN forum
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.
The azure event grid allows an https endpoint (my web hook event handler) to be registered with a subscriber for a topic. So when an event is received by the topic that matches the subscription filter criteria, the event is pushed by the event grid to my https endpoint.
I have a use case where the my https endpoint requires a client certificate to be supplied with this http push mechanism by event grid.
Does event grid allow a way to attach/configure a client certificate, related to the my web hook https endpoint? If so, how do I configure this?
If the client certificate functionality (for push) is currently not available in event grid, what are the other easier security mechanisms that I can employ to keep out unwanted and malicious events push by non-event grid publishers? (Other than firewall rules, white listing of IPs etc.)
Thanks.
For your scenario can be used an EventGridTrigger Function as a subscriber-integrator to your client endpoint. This function will handle forwarding an event message based on your needs.
Update:
Other option using a declarative integration for delivery an event grid to the https endpoint with a client certificate authorization is subscribing by Logic Apps and then forwarding to the custom endpoint. The following screen snippet shows this case:
Note, that the Azure Event Grid supports customizing a Webhook subscriber endpoint only at the url address (included a query string). That's documented in the https://learn.microsoft.com/en-us/azure/event-grid/security-authentication as it has been commented by #KenWMSFT.
Both of Roman's answers should work quite well. Depending on your particular constraints and throughput, a third option would be to use Hybrid Connections as an intermediary.
This would involve adding a bit of code at your event handling endpoint to open a WebSocket connection to Hybrid Connections, and then routing your events form Event Grid to Hybrid Connections.
This should allow you to fully circumvent your client certificate issue and would allow for high throughput. The downside is adding some client-side code to open the WebSocket. The best solution for you is highly dependant on your requirements.
Here is a sample on using Hybrid Connections to route events if you choose to go that route.
I am now using a Beacon Reveiver to get the iBeacon Information.
Here is the problem:
the receiver platform server only allow me to type a url.
How should I do to send the information to azure eventhub??
I found this API:
https://NAMESPACE.servicebus.windows.net/EVENTHUB-NAME/publishers/PUBLISHER-NAME/messages
I tried it ,but it seems doesn't work.
Do i miss anything?? or Can anyone teach me how to add the authentication in url? What should I do now?
Thanks
You must set an authentication HTTP header in order to send events to Event Hubs. You can't include authentication information in the request URL.
Even though you can't send messages directly to Event Hubs, you can develop a custom Web API that uses your own URL-based authentication mechanism and forwards the requests to Event Hubs (or another service). That defeats the purpose of using Event Hubs to some degree but gives you more flexibility.