Building a resilient workflow using Durable Functions
XASA Workshop
Congratulations! Today is your first job as a software engineer at XASA, the Xpirit Aeronautics and Space Administration. You are responsible for creating a system which reacts to detected Near-Earth Objects (NEOs).
A satellite is continuously scanning the skies for these NEOs. The satellite transmits its findings to ground stations which in turn send the data to Azure.
It's your job to ensure the incoming data is analyzed to assess the risk of impact, stored, and to notify the one and only person who can save earth in case of an asteroid threat...
Technical solution
You are tasked with implementing the solution using Azure Functions. The reason behind this is that the number of detected NEOs changes heavily over time. And when nothing is being detected XASA prefers not paying for any infrastructure.
Another team was tasked with the ingestion of the NEO data and this data is already being pushed to an Azure Servicebus topic.
You are tasked with creating two Azure Function apps which are decscribed below.
XASA Onboarding Function App
You will be responsible for automating a part of the onboarding process for new XASA employees. This Function App will contain two functions:
- An HTTP trigger function which validates the input (username & email) and puts a message on a queue.
- A Queue trigger function which calls an service to register the user and returns a connectionstring for the Servicebus topic and an API key to call other XASA services. The result is stored in blob storage.
POST --> HTTP trigger --> Queue --> Queue trigger --> Blob
NEO Event Processor Function App
You will also be responsible for creating a Function App that is triggered by messages pushed to the Servicebus topic.
The messages are of type DetectedNEOEvent
and contains the following information:
{
"id" : "77c924dc-883c-4f53-922f-7cddb7325121",
"date" : "2019-04-23T18:25:43.511Z",
"distance": 3.5,
"velocity" : 10,
"diameter" : 0.52
}
- Distance is measured in Astronomical Units (AU). Usually between 1-5 AU.
- Velocity is measured in km/s. Usually between 5-30 km/s
- Diameter is measured in km. Usually between 0.0001 and 10 km.
The Function App needs to make several calls to other services in order to determine:
- the kinetic energy of a potential impact.
- the probability of an impact.
- the Torino impact.
In addition to these API calls, the processed data needs to be stored to blob storage (for events with a Torino impact > 0) and a notification needs to be sent out to Bruce Willis (for events with a Torino impact > 7).
Topic Message --> Servicebus trigger
|
V
NeoEventProcessingOrchestrator
|
+ --> EstimateKineticEnergyActivity
|
+--> EstimateImpactProbabilityActivity
|
+ --> EstimateTorinoImpactActivity
|
When TorinoImpact > 0
|
+ --> StoreProcessedNeoEventActivity
|
When TorinoImpact > 7
|
+ --> SendNotificationActivity
The final implementation (up to Lab 10) is also in this repo. However, it is lots more fun, and you learn way more, by creating your own solution and following all the labs. Only peek at my solution if you're completely stuck (but I would prefer you asking me, or someone else for help).
I strongly suggest you team up with someone to do pair programming and discuss what you're doing.
Have fun! Marc
Labs
- Check Prerequisites
- Creating a new function project with an http trigger
- Adding a queue output binding
- Adding a queue trigger function
- Creating a new function project with a servicebus trigger
- Creating an orchestration client
- Creating the orchestrator function
- Calling other services
- Storing the ProcessedNeoEvent
- Sending a notification
- Unit testing the orchestrator
- Calling activities in parallel (Fan-out/Fan-in)
- Using suborchestrations
- Waiting for external events
- Counting events using Durable Entities
- Creating Azure resources
- Publish to Azure
- Additional features
License
Please see the licensing information.