Ein IoT-Anbieter stellt Partnern einen benutzerdefinierten Ereignisdienst zur Verfügung. Partner stellen HTTPS-Webhook-Endpunkte bereit, die zeitweise offline sein können. Sie müssen Ereignisse mithilfe eines standardmäßigen sprachübergreifenden Schemas veröffentlichen, Ereignisse nach eventType-Präfix filtern, bis zu 24 Stunden lang mit exponentiellem Backoff wiederholen und, falls die Zustellung letztendlich fehlschlägt, nicht zugestellte Ereignisse zur Überprüfung in einem Speicherkonto speichern. Was sollten Sie implementieren?

Die korrekte Option beschreibt präzise die Funktionen von Azure Event Grid, die alle Anforderungen erfüllen. Ein benutzerdefiniertes Event Grid-Thema mit CloudEvents v1.0-Schema ermöglicht die standardisierte Veröffentlichung. Ereignisabonnements mit erweiterten Filtern nach eventType erfüllen die Filteranforderung. Die konfigurierbare Wiederholungsrichtlinie mit exponentiellem Backoff bis zu 24 Stunden ist eine Kernfunktion von Event Grid. Dead-Lettering in ein Speicherkonto ist die vorgesehene Methode für die Speicherung nicht zugestellter Ereignisse. Die anderen Optionen sind ungeeignet: Azure Service Bus Topics sind Messaging-Dienste, aber Event Grid ist besser für Ereignisverteilung an viele Endpunkte geeignet und bietet nicht direkt die geforderte Filterung und Dead-Lettering-Mechanismen auf diese Weise. Azure Event Hubs sind für das Streaming großer Datenmengen optimiert, nicht für die Verteilung einzelner Ereignisse an Webhooks mit komplexen Wiederholungsstrategien und Dead-Lettering. Eine Event Grid-Domäne ist für die Verwaltung mehrerer Themen gedacht, aber die Deaktivierung von Wiederholungen widerspricht der Anforderung. Azure Logic Apps sind für die Orchestrierung von Workflows gedacht und würden hier einen Pull-Mechanismus statt eines Push-Ereignissystems implementieren, was ineffizient wäre.