Event Grid Management
  • Updated on 21 Mar 2019
  • 4 minutes to read
  • Contributors
  • Print
  • Share
  • Dark
    Light

Event Grid Management

  • Print
  • Share
  • Dark
    Light

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 Activity

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:

Property Description
Subject Publisher-defined path to the event subject
Data Version The schema version of the data object. The publisher defines the schema version
Event Type One of the registered event types for this event source

The event count is also configurable in the Serverless360 activity definition. This activity configuration can also be saved for future usage.
Inline Activity Gif.gif

Scheduled activity

Similar to the Service Bus and Event Hub activities, 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 activity
This activity configuration can also be fired whenever required, similar to Service Bus and Event hub activities.
Scheduled activity .gif

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 entity 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.

The storage account blob that acts as the Dead- Letter destination of the Event Grid Subscription should be associated to the same Composite Application that contains the Event Grid Subscription for accessing and processing the dead- letter events

View Events.gif

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

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.

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.
Resubmit Events.gif

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.
Repair and resubmit Events.gif

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
  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.
Governance Audit.gif

We'd love to hear your thoughts
Please visit our feedback system to suggest new Features or Enhancements. You can also take a look at our Roadmap
Was this article helpful?