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.
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 have 2 Web APIs in .NET Core which communicate between themselves sending events to an azure event grid topic. This event grid topic has 2 web hooks event subscriptions (one for each API) that do a HTTPS request to the other API whenever a event is send to the topic.
Also I have an Application Insight for logging and monitoring both APIs. I want to be able to relate the logs of both APIs. I know that this is done out of the box for HTTP requests between both APIs using a Request-Id header. Is it possible to add such thing in the web hooks?
Or if not, is it possible to implement a custom middleware or filter to handle this?
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 want to implement event notification webhook method into my app. I am using docusign-java-client SDK for docusign, but I am unable to find any example using SDK. Can anyone provide some example to achieve this?
I'm sorry to report that we (DocuSign) don't yet have a Java recipe for this. We do have a Python example. Java is on the list of things to do. Perhaps someone else can provide an example in the meantime.
Here is a general description:
First, set up your webhook subscription. You can have an envelope-specific webhook subscription by including the eventNotification fields in your envelope create request.
Or you can set up a more general subscription by using the "Connect" feature. You can setup Connect subscriptions either via the DocuSign web tool, or programmatically.
As part of the subscription you provide your url for the incoming XML notification messages.
To handle them, you write a small web app using whatever web app framework is easiest for you and your stack. Your web server will receive the incoming https calls from DocuSign.
You can see what the incoming XML messages look like by using the beta Recipe Framework. Run it on Heroku. Use the embedded signing recipe and click the button to see the Webhook / Connect messages. You can then see the sorts of messages that you will receive.
Your incoming message web server will simply parse the XML messages and then handle them accordingly.
Thanks for using the webhook system. Please ask more questions here if you have any issues.