On my journey for my next Azure certification I explored Azure EventGrid. For those that aren’t acquainted, a description follows;
“Simplify your event-based apps with Event Grid, a single service for managing routing of all events from any source to any destination. Designed for high availability, consistent performance, and dynamic scale, Event Grid lets you focus on your app logic rather than infrastructure.” Source
The service can be used for many different tasks, and it appears that is more typically used to track changes to VMs or changes to a database.
I will also add, that although it mentions EventGrid being part of a application, it can really be used for any number of tasks regardless of the process being part of a larger application.
Personally, I don’t have a current application, or need, for something that is designed for such a heavy workload. Something more simple, that I could conceptualize, was for a smaller business processes.
Here's the scenario
I use Docparser to pull information from incoming invoices, and invoices are usually sent when the product is shipped. A large amount of invoices have shipment tracking numbers attached.
I could set up a 'Topic' in Azure that receives an 'Event' of when an invoice's data is parsed. That information can then be viewed by any number of 'Subscribers'.
I want to set up an Azure Function (the Subscriber) that is listening for that event Topic to be triggered by a 'Publisher' (Docparser). Once that Event data makes its way to the Function there is any number of things that could be done with it.
The data could be checked to ensure that it contains a valid tracking number. It could then use a number of libraries or services (in our case, Shippo) to check the status, set up a webhook, email the receipient, or publish the information to a webapp (maybe your own webapp?).
The Entire Process
The process starts with a vendor sending an email with the PDF attachment to your email address. The email is parsed for the shipping number and, using Docparser's webhook integration, it is sent off to the Topic. The Azure Function receives the information and polls the shippo API for a status. Once is has the status any number of the possibilities in the previous section could be reached.
I could set up Alerts, Monitoring, and Logging for myself to stay connected with data usage. I could also set up Function Output Bindings, Logic Apps, and move data all over the place doing all sorts of things.
This doesn't utilize the workload that EventGrid can handle (EventGrid can also trigger SendGrid to send massive amounts of emails), but I can build all kinds of Subscribers without changing the entire app or business process.
Step 1: Set Up the Topic (InvoiceReceived)
Step 2: Create Docparser Advanced Webook
Step 3: Set Up the Subscriber as an Azure Function
Step 4: Write the code
Step 5: Test
I sent the test webhook from Docparser
I set up an OutPut Binding to save the status object to a Storage Queue to prove that the status was actually extracted.
This is just a small example and could be achieved in other ways. However, having this Event go to a Topic could easily allow us to add more features, processes, functionality, without adding more webhooks from our custom Publisher.
Azure EventGrid Pricing
I was curious about what the pricing was for this service and found the following two bits of information (as of September 8, 2019).
The first 100,000 operations per month are free. Operations are defined as event ingress, subscription delivery attempts, management calls, and filtering by subject suffix. Source
Azure customers receive up to 25,000 emails per month for free with paid packages starting at only $9.95 per month. For customers requiring ability to send larger email volumes, SendGrid also offers Silver, Gold, Platinum and Premier packages, which include a dedicated IP as well as additional IP and user management features. Source