Pull-Lieferung mit HTTP

Dieser Artikel baut auf dem Artikel Was ist Azure Event Grid? und dem Artikel Event Grid Konzepte auf, um wichtige Informationen zu liefern, bevor Sie mit der Pull-Übertragung von Event Grid über HTTP beginnen. Es werden grundlegende Konzepte, Ressourcenmodelle und unterstützte Nachrichtenübermittlungsmodi behandelt. Am Ende dieses Dokuments finden Sie nützliche Links zu Artikeln, die Sie bei der Verwendung von Event Grid unterstützen, sowie zu Artikeln mit detaillierten konzeptionellen Informationen.

Hinweis

Dieses Dokument hilft Ihnen bei den ersten Schritten mit Event Grid-Funktionen, die das HTTP-Protokoll verwenden. Dieser Artikel eignet sich für Benutzer, die Anwendungen in die Cloud integrieren müssen. Wenn Sie IoT-Gerätedaten übermitteln möchten, siehe Übersicht über die MQTT-Broker-Funktion in Azure Event Grid.

CloudEvents

Event Grid-Namensraumthemen akzeptieren Ereignisse, die dem offenen Standard CloudEvents 1.0 der Cloud Native Computing Foundation (CNCF) entsprechen, unter Verwendung der HTTP-Protokollbindung mit JSON-Format.

Weitere Informationen finden Sie in den CloudEvents-Konzepten.

CloudEvents-Inhaltsmodi

Die CloudEvents-Spezifikation definiert drei Inhaltsmodi, die Sie verwenden können: Binär, Strukturiert und Batched.

Wichtig

Mit jedem Inhaltsmodus können Sie Text (JSON, text/*, etc.) oder binär kodierte Ereignisdaten austauschen. Der Modus für binäre Inhalte wird nicht ausschließlich zum Senden von Binärdaten verwendet.

Bei den Inhaltsmodi geht es nicht um die verwendete Kodierung (binär oder Text), sondern darum, wie die Ereignisdaten und ihre Metadaten beschrieben und ausgetauscht werden. Der strukturierte Inhaltsmodus verwendet eine einzige Struktur, z. B. ein JSON-Objekt, bei dem sowohl die Kontextattribute als auch die Ereignisdaten in der HTTP-Nutzlast enthalten sind. Der binäre Inhaltsmodus trennt Kontextattribute, die auf HTTP-Header abgebildet werden, und Ereignisdaten, bei denen es sich um die HTTP-Payload handelt, die entsprechend dem Medientypwert in Content-Type kodiert ist.

Weitere Informationen finden Sie unter CloudEvents-Inhaltsmodi.

Nachrichten und Ereignisse

Ein CloudEvent enthält normalerweise Ereignisdaten, die ein Ereignis in einem System ankündigen, d. h. eine Änderung des Systemzustands. Sie können jedoch jede Art von Daten übermitteln, wenn Sie CloudEvents verwenden. Sie könnten zum Beispiel das CloudEvents-Austauschformat verwenden, um eine Befehlsnachricht zu senden, die eine Aktion an eine nachgeschaltete Anwendung anfordert. Ein weiteres Beispiel ist die Weiterleitung von Nachrichten vom MQTT-Broker des Event Grid an ein Topic. In diesem Szenario leiten Sie eine MQTT-Nachricht weiter, die in einen CloudEvents-Umschlag verpackt ist.

Pullübermittlung

Bei der Pull-Bereitstellung stellt Ihre Anwendung eine Verbindung zum Event Grid her, um CloudEvents mit einer Warteschlangen-ähnlichen Semantik zu lesen.

Die Pull-Lieferung bietet diese Vorteile für den Konsum von Veranstaltungen:

• Verarbeiten Sie Ereignisse in Ihrem eigenen Tempo, in großem Umfang oder mit einer Eingangsrate, die Ihre Anwendung unterstützt.

• Konsumieren Sie Ereignisse zu einem Zeitpunkt Ihrer Wahl. Zum Beispiel werden Nachrichten aufgrund von Geschäftsanforderungen nachts verarbeitet.

• Verbrauchen Sie Ereignisse über eine private Verbindung, damit Ihre Daten einen privaten IP-Raum nutzen.

Hinweis

• Namespaces bieten ein einfacheres Ressourcenmodell mit einer einzelnen Art von Thema. Derzeit unterstützt Event Grid die Veröffentlichung Ihrer eigenen Anwendungsereignisse über Namespacethemen. Sie können keine Ereignisse von Azure-Diensten oder SaaS-Systemen von Partnern mithilfe von Namespacethemen verwenden. Sie können in einem Namespace auch keine Systemthemen, Domänenthemen oder Partnerthemen erstellen.
• Namespacethemen unterstützen das JSON-Format von CloudEvents.

Warteschlangen-Ereignis-Abonnements

Beim Empfang von Ereignissen oder bei der Verwendung von Operationen, die den Ereignisstatus verwalten, gibt eine Anwendung einen Namespace-HTTP-Endpunkt, einen Themennamen und den Namen eines Queue-Ereignisabonnements an. Bei einem Warteschlangen-Ereignisabonnement ist der deliveryMode auf „queue“ eingestellt. Warteschlangen-Ereignisabonnements werden verwendet, um Ereignisse über die Pull Delivery API zu konsumieren. Weitere Informationen über die Erstellung dieser Ressourcen finden Sie unter Namespaces, Themen und Ereignisabonnements erstellen.

Sie verwenden ein Ereignisabonnement, um die Filterkriterien für Ereignisse festzulegen, und definieren damit die Menge der Ereignisse, die über dieses Ereignisabonnement konsumiert werden können. Eine oder mehrere abonnierte (Verbraucher-)Anwendungen können sich mit demselben Namespace-Endpunkt verbinden und dasselbe Thema und Ereignisabonnement verwenden.

Auslieferungsvorgänge ziehen

Ihre Anwendung verwendet die folgenden Operationen, wenn Sie mit der Pull-Lieferung arbeiten.

• Ein receive-Vorgang wird verwendet, um ein oder mehrere Ereignisse mit einer einzelnen Anforderung an Event Grid zu lesen. Standardmäßig wartet der Makler bis zu 60 Sekunden, bis Ereignisse verfügbar werden. So werden beispielsweise Ereignisse zum Zeitpunkt ihrer ersten Veröffentlichung zur Verfügung gestellt. Eine erfolgreiche Empfangsanforderung liefert null oder mehr Ereignisse. Wenn Ereignisse verfügbar sind, werden so viele Ereignisse wie möglich zurückgegeben, bis die angeforderte Anzahl erreicht ist. Event Grid gibt auch ein Sperrtoken für jedes gelesene Ereignis zurück.
• Ein Lock-Token ist eine Art Handle, das ein Ereignis identifiziert, mit dem man seinen Zustand kontrollieren kann.
• Sobald eine Verbraucheranwendung ein Ereignis empfängt und verarbeitet, quittiert sie dieses Ereignis. Dieser Vorgang weist Event Grid an, das Ereignis zu löschen, damit es nicht erneut an einen anderen Client zugestellt wird. Die Consumeranwendung bestätigt ein oder mehrere Token mit einer einzelnen Anforderung, indem sie ihre Sperrtoken angibt, bevor sie ablaufen.

In anderen Fällen kann es vorkommen, dass Ihre Verbraucheranwendung Ereignisse freigeben oder zurückweisen möchte.

• Ihre Verbraucheranwendung gibt ein empfangenes Ereignis frei, um dem Event Grid zu signalisieren, dass es nicht bereit ist, dieses Ereignis zu verarbeiten und es für eine erneute Zustellung verfügbar zu machen. Dies geschieht durch den Aufruf der Operation freigeben mit den Sperrtoken, die die Ereignisse identifizieren, die an das Ereignisraster zurückgegeben werden sollen. Ihre Anwendung kann steuern, ob das Ereignis sofort freigegeben werden soll oder ob eine Verzögerung eintreten soll, bevor das Ereignis für eine erneute Zustellung verfügbar ist.

• Sie können ein Ereignis zurückweisen, wenn eine - möglicherweise dauerhafte - Bedingung vorliegt, die Ihre Verbraucheranwendung daran hindert, das Ereignis zu verarbeiten. Beispielsweise kann eine nicht wohlgeformte Nachricht abgelehnt werden, da sie nicht erfolgreich analysiert werden kann. Abgelehnte Ereignisse werden mit einer unzustellbaren Nachricht versehen, wenn ein Ziel für unzustellbare Nachrichten verfügbar ist. Andernfalls werden sie gelöscht.

Umfang, in dem Pull-Liefervorgänge ablaufen

Wenn Sie eine Operation Empfangen, Bestätigen, Freigeben, Ablehnen oder Sperre erneuern aufrufen, werden diese Aktionen im Kontext des Ereignisabonnements ausgeführt. Wenn Sie z. B. ein Ereignis bestätigen, ist dieses Ereignis nicht mehr über das Ereignisabonnement verfügbar, das beim Aufruf der Aktion Bestätigen verwendet wird. Andere Ereignisabonnements könnten immer noch das „gleiche“ Ereignis zur Verfügung haben. Das liegt daran, dass ein Ereignisabonnement eine Kopie der veröffentlichten Ereignisse erhält. Diese Ereigniskopien sind über die verschiedenen Ereignisabonnements hinweg effektiv voneinander verschieden. Jedes Ereignis hat seinen eigenen Zustand, unabhängig von anderen Ereignissen.

Datenform beim Empfang von Ereignissen mit Pull-Lieferung

Wenn Ereignisse mit Pull Delivery geliefert werden, enthält Event Grid ein Array von Objekten, das wiederum die Objekte event und brokerProperties enthält. Der Wert der Eigenschaft event ist das CloudEvent, das im strukturierten Inhaltsmodus geliefert wird. Das brokerProperties-Objekt enthält das mit dem gelieferten CloudEvent verknüpfte Sperr-Token. Das folgende json-Objekt ist eine Beispielantwort von einer receive Operation, die zwei Ereignisse zurückgibt:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Push- und Pullübermittlung

Event Grid unterstützt Push- und Pull-Ereignisübermittlung über HTTP. Mit push delivery definieren Sie ein Ziel in einem Ereignisabonnement, einem Webhook oder einem Azure-Dienst, an das Event Grid Ereignisse sendet. Mit der Pullübermittlung stellen Abonnentenanwendungen eine Verbindung mit Event Grid her, um Ereignisse zu nutzen. Die Pull-Lieferung wird für Themen in einem Ereignisraster-Namespace unterstützt.

Wichtig

Event Hubs wird als Ziel für Abonnements für Namespace-Themen unterstützt. In den kommenden Versionen werden Event Grid Namespaces alle derzeit in Event Grid Basic verfügbaren Ziele sowie zusätzliche Ziele unterstützen.

Wann sollte die Pushübermittlung gegenüber der Pullübermittlung verwendet werden?

Die folgenden allgemeinen Richtlinien helfen Ihnen bei der Entscheidung, wann die Pull- oder Pushübermittlung verwendet werden sollte.

Pullübermittlung

• Sie benötigen die volle Kontrolle darüber, wann Ereignisse empfangen werden sollen. So kann es beispielsweise sein, dass Ihre Anwendung nicht die ganze Zeit läuft, nicht stabil genug ist oder dass Sie Daten zu bestimmten Zeiten verarbeiten.
• Sie benötigen die vollständige Kontrolle über die Ereignisnutzung. Beispielsweise weist ein nachgelagerter Dienst oder eine nachgeschaltete Ebene in Ihrer Consumeranwendung ein Problem auf, das verhindert, dass Sie Ereignisse verarbeiten können. In diesem Fall ermöglicht die Pullübermittlungs-API der Consumer-App, ein bereits gelesenes Ereignis wieder zurück an den Broker freizugeben, sodass es später zugestellt werden kann.
• Sie möchten beim Empfang von Ereignissen private Links verwenden, was nur mit der Pull-Zustellung, nicht mit der Push-Zustellung möglich ist.
• Sie können einen Endpunkt nicht verfügbar machen und die Pushübermittlung verwenden, aber Sie können eine Verbindung mit Event Grid herstellen, um Ereignisse zu nutzen.

Pushübermittlung

• Sie möchten nicht ständig abfragen müssen, um festzustellen, ob eine Systemzustandsänderung eingetreten ist. Stattdessen verwenden Sie Event Grid, damit dieses Ihnen zu dem Zeitpunkt Ereignisse sendet, zu dem Zustandsänderungen auftreten.
• Sie verfügen über eine Anwendung, die keine ausgehenden Aufrufe tätigen kann. Ihr Unternehmen könnte sich zum Beispiel Sorgen über eine Datenexfiltration machen. Ihre Anwendung kann jedoch Ereignisse über einen öffentlichen Endpunkt empfangen.

Nächste Schritte

Die folgenden Artikel bieten Informationen zur Verwendung von Event Grid bzw. zusätzliche Informationen zu Konzepten.

• Veröffentlichen und abonnieren Sie Ereignisse mit Hilfe von Namespace Topics.

Weitere hilfreiche Links

• SDKs für die Steuerebene und die Datenebene.
• Ankündigung von SDKs für die Datenebene mit einer Fülle von Informationen, Beispielen und Links
• Kontingente und Grenzwerte.