Event Grid Management

Send Events to Event Grid Topics

Event grid topics are created by the event publishers to forward the events to the destination. The event grid topics are endpoints to which the source (publisher) sends the event. Azure provides some system topics which can only be subscribed by the event grid subscriptions. They belong to the event publishers, which are mainly the Azure services like Service Bus namespaces.
Custom event grid topics can be created when the event publishers aren’t azure services. For example, when an event must be sent to a destination (say storage account blob) from a custom application we can make use of event grid topics. It is also possible to create multiple event grid subscriptions for the same event grid topic so that all the destinations receive the event published to that event grid topic.

Inline Automated Tasks

Consider a scenario where there are multiple event grid subscriptions created for a single event grid topic in a business process. There may be a need to verify whether the events sent to the event grid topic is received by all the event grid subscriptions. Serverless360 provides this capability of sending the events to event grid topics.
Events can be sent to the event grid topics associated to the composite application of Serverless360. It is also possible to define the following properties along with the actual event data:

The event count is also configurable in the Serverless360 automated tasks definition. This automated tasks configuration can also be saved for future usage.

Scheduled Automated Tasks

Similar to the Service Bus and Event Hub automated tasks, sending events to event grid topics can also be automated. Serverelss360 lets user simulate a real time scenario by allowing the user to configure the following parameters:
• Send Batch- the specified number of events will be spilt across the batches
• Task Count - defines the number of parallel instances
• Think time- will define the time gap between every event. In case of more than 1 batch it will define the time gap between every batch
• Event Data Count - number of events to be sent by this automated tasks
This automated tasks configuration can also be fired whenever required, similar to Service Bus and Event hub automated tasks.

Accessing failed events of Event Grid Subscription

Azure Event Grid is used to build event driven architectures. Event Grid Topics and Event Grid Subscriptions are involved in event publishing and subscribing to the events.
For any reason if the Event Subscription fails to receive the events, there is a Dead-lettering mechanism available to capture the failed events. Unlike the Service Bus Dead-lettering Event Grid stores the failed events in a Storage Blob Container.
Consider a scenario where the destination resource of the Event Grid Subscription is a Service Bus Queue and an Azure Function listens for the messages from the Queue. If the Queue is deleted accidentally the events would fail and eventually get stored in a Storage Blob Container configured at the time of creation of the Event Subscription.

Serverless360 provides an user interface to access the failed events of the Event Grid Subscription from the configured Blob Container. This will help to rectify the problem and keep track of the failed events.

It is possible to view the event content with basic properties along with the Dead-letter reason.

Processing the Dead-Letter Events of Event Grid Subscription

Consider a scenario where the endpoint configured to an event subscription was down for an hour and the events sent to it from the event grid topic have been dead-lettered. Now when the endpoint is available to receive the events there may be a need to reprocess the dead-lettered events of the event grid subscription.
This can be achieved using Serverless360. The dead-lettered events can be either resubmitted or repaired and resubmitted to the event grid topic.

By default 20 events will be retrieved from the associated storage account. To fetch subsequent events click load more.

Resubmit dead-lettered events

Resubmitting the dead-lettered event to an event grid topic preserves all the properties of the event grid event like Id, Subject, Event Type, Event Time, Data Version, Metadata Version and Event Data.

Repair and Resubmit dead-lettered events

Repair and resubmitting of dead-lettered events can be used when there is a need to modify the event properties. For example Event time of the dead-lettered event can be modified before resubmitting it to the event grid topic.

Delete dead-lettered events

Once the dead-letter events are processed manually either through resubmission or repair and resubmission, the dead-letter events can be deleted from the configured dead-letter destination.

Pre-requisites for processing the dead-lettered events

The dead-letter event processing of event grid subscription can be done only if the following requirements are met.

1. The event grid subscription must be configured with a custom event grid topic. If the event grid subscription is under domain scope then that particular domain has to be associated under Other resources.
2. The storage account container configured as dead-letter destination of event grid subscription must have public anonymous access either to the container or to its blobs

All the reprocess actions on dead-lettered event grid events are captured in the Messaging section of Governance and Audit.