Movatterモバイル変換


[0]ホーム

URL:


Skip to main content

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Download Microsoft EdgeMore info about Internet Explorer and Microsoft Edge
Table of contentsExit editor mode

Azure Event Grid namespaces - Push delivery

Feedback

In this article

This article builds onpush delivery with HTTP for Event Grid basic and provides essential information before you start using push delivery on Event Grid namespaces over HTTP protocol. This article is suitable for users who need to build applications to react to discrete events using Event Grid namespaces. If you're interested to know more about the difference between the Event Grid basic tier and the standard tier with namespaces, seechoose the right Event Grid tier for your solution.

Namespace topics and subscriptions

Events published to Event Grid namespaces land on a topic, which is a namespace subresource that logically contains all events. Namespace topics allows you to create subscriptions with flexible consumption modes to push events to a particular destination orpull events at your pace.

Diagram showing a topic and associated event subscriptions.

Supported event handlers

Here are the supported event handlers:

Push and pull delivery

Event Grid supports push and pull event delivery using HTTP. Withpush delivery, you define a destination in an event subscription, a webhook, or an Azure service, to which Event Grid sends events. Withpull delivery, subscriber applications connect to Event Grid to consume events. Pull delivery is supported for topics in an Event Grid namespace.

Important

Event Hubs is supported as a destination for subscriptions to namespace topics. In coming releases, Event Grid Namespaces will support all destinations currently available in Event Grid Basic along with additional destinations.

High-level diagram showing push delivery and pull delivery with the kind of resources involved.

When to use push delivery vs. pull delivery

The following are general guidelines to help you decide when to use pull or push delivery.

Pull delivery

  • You need full control as to when to receive events. For example, your application might not be up all the time, not stable enough, or you process data at certain times.
  • You need full control over event consumption. For example, a downstream service or layer in your consumer application has a problem that prevents you from processing events. In that case, the pull delivery API allows the consumer app to release an already read event back to the broker so that it can be delivered later.
  • You want to useprivate links when receiving events, which is possible only with the pull delivery, not the push delivery.
  • You don't have the ability to expose an endpoint and use push delivery, but you can connect to Event Grid to consume events.

Push delivery

  • You want to avoid constant polling to determine that a system state change has occurred. You rather use Event Grid to send events to you at the time state changes happen.
  • You have an application that can't make outbound calls. For example, your organization might be concerned about data exfiltration. However, your application can receive events through a public endpoint.

Next steps


Feedback

Was this page helpful?

YesNoNo

Need help with this topic?

Want to try using Ask Learn to clarify or guide you through this topic?

Suggest a fix?

  • Last updated on

In this article

Was this page helpful?

YesNo
NoNeed help with this topic?

Want to try using Ask Learn to clarify or guide you through this topic?

Suggest a fix?