The office receives contact lists as CSV files, for example after a trade fair. Until now, someone has retyped them by hand. From this lesson on, you
upload the file to the blob container imports, and shortly afterward the contacts are in the Kladde. Nobody has to press a button for that, and
no program has to search the container at regular intervals: Blob Storage reports the new file itself, through Event Grid.
Event Grid is the service for individual events that stood next to Service Bus in lesson 3.5.1. You learn how it distributes events,
what they look like and how to filter them, and you have it put the event “file created” into the Service Bus queue contact-import.
You know the rest: a worker that works idempotently and puts away poison messages.
Event Grid in four terms
- An event is a small notice that something has happened: “In
imports,contacts-november.csvhas been created.” It describes what happened but doesn't carry the data itself; the file stays in Blob Storage. - The source publishes events to a topic. For Azure services there are system topics: one per resource, for example per storage account, to which only the service itself writes. For custom events there are custom topics.
- An event subscription selects from a topic the events that interest it (filters) and names a destination: a webhook, a Service Bus queue or topic, a Storage queue, Event Hubs, an Azure Function.
- Event Grid actively pushes every event to the destination. If the destination doesn't accept it, Event Grid tries again on a schedule.
The difference from a topic in Service Bus: There, receivers pick up when they have time, and a message waits until it expires. Event Grid holds events only as long as there are still delivery attempts. A destination that isn't running right now can therefore lose events with Event Grid. That is exactly why the Kladde delivers not to a webhook in the worker but to a queue from which the worker picks up.