Merge pull request Azure#55 from Azure/module9-review

Module 9 review as well as other Miscellaneous changes

Author: waelkdouh

docs/aca/01-deploy-api-to-aca/index.md

@@ -3,6 +3,8 @@ canonical_url: 'https://bitoftech.net/2022/08/25/deploy-microservice-application
 ---
 
 # Module 1 - Deploy Backend API to ACA
+!!! info "Module Duration"
+    60 minutes
 
 In this module, we will start by creating the first microservice named `ACA Web API – Backend` as illustrated in the [architecture diagram](../../assets/images/00-workshop-intro/ACA-Architecture-workshop.jpg). Followed by that we will provision the  Azure resources needed to deploy the service to Azure Container Apps using the Azure CLI.
 ### 1. Create the backend API project (Web API)

docs/aca/02-aca-comm/index.md

@@ -2,10 +2,12 @@
 canonical_url: https://bitoftech.net/2022/08/25/communication-microservices-azure-container-apps/
 ---
 
-# Module 2 - Communication between Microservices in ACA
+# Module 2 - Communication Between Microservices in ACA
+!!! info "Module Duration"
+    60 minutes
 
 In this module, we will add a service named `ACA Web API – Frontend` as illustrated in the [architecture diagram](../../assets/images/00-workshop-intro/ACA-Architecture-workshop.jpg). This service will host a simple ASP.NET Razor pages web app which allows the end users to manage their tasks. After that we will provision Azure resources needed to deploy the service to ACA using Azure CLI.
-### 1. Create the frontend Web App project (Web APP)
+### 1. Create the Frontend Web App project (Web APP)
 
 - Open a command-line terminal and navigate to root folder of your project. Create a new folder as shown below:
     ```shell

docs/aca/03-aca-dapr-integration/index.md

@@ -3,10 +3,12 @@ canonical_url: https://bitoftech.net/2022/08/29/dapr-integration-with-azure-cont
 ---
 
 # Module 3 - Dapr Integration with ACA
+!!! info "Module Duration"
+    60 minutes
 
 In this module, we will start integrating Dapr into both services and see how Dapr with ACA will simplify complex microservices scenarios such as service discovery, service-to-service invocation, calling services asynchronously via pub/sub patterns, auto-scaling for overloaded services, etc..
 
-### Benefits of integrating Dapr in Azure Container Apps
+### Benefits of Integrating Dapr in Azure Container Apps
 
 The Tasks Tracker microservice application is composed of multiple microservices (2 microservices so far), and function calls are spread across the network. To support the distributed nature of microservices, 
 we need to account for failures, retries, and timeouts. While Container Apps features the building blocks for running microservices, the use of Dapr provides an even richer microservices programming model. 
@@ -22,10 +24,10 @@ Although we won't tap into all these benefits in this workshop its worth keeping
 - Control what operations clients can do using access control policies.
 - Capture traces and metrics for all calls between services to provide insights and diagnostics. 
 
-### Configure Dapr on a local development machine
+### Configure Dapr on a Local Development Machine
 In order to run applications using Dapr, we need to install and initialize Dapr CLI locally. The official documentation is quite clear, and we can follow the steps needed to [install](https://docs.dapr.io/getting-started/install-dapr-cli/) Dapr and then [Initialize](https://docs.dapr.io/getting-started/install-dapr-selfhost/) it.
 
-### Run Backend API and Frontend Web App locally using Dapr
+### Run Backend API and Frontend Web App Locally Using Dapr
 You are now ready to run the applications locally using Dapr sidecar in a self-hosted mode. There is a VS code extension called [Dapr](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-dapr) which will allow you to run, debug, and interact with Dapr-enabled applications in VS Code.
 
 - Let's start by running the Backend Web API service using Dapr. From VS Code open a new PowerShell terminal, run the below commands in PS terminal based on your .NET version. 

docs/aca/04-aca-dapr-stateapi/index.md

@@ -3,6 +3,8 @@ canonical_url: https://bitoftech.net/2022/08/29/azure-container-apps-state-store
 ---
 
 # Module 4 - ACA State Store With Dapr State Management API
+!!! info "Module Duration"
+    60 minutes
 
 In this module we will switch the in-memory store of tasks and use a key/value persistent store (Azure Cosmos DB). By using the [Dapr State Management Building Block](https://docs.dapr.io/developing-applications/building-blocks/state-management/state-management-overview/), we will see how we can store the data in Azure Cosmos DB without installing any Cosmos DB SDK or write specific code to integrate our Backend API with Azure Cosmos DB.
 Moreover, we will use Redis to store tasks when we are running the application locally. You will see that we can switch between different stores without any code changes, thanks to the [Dapr pluggable state stores feature](https://docs.dapr.io/developing-applications/building-blocks/state-management/state-management-overview/#pluggable-state-stores). It is a matter of adding new Dapr Component files and the underlying store will be changed. This page shows the [supported state stores](https://docs.dapr.io/reference/components-reference/supported-state-stores/) in Dapr.
@@ -11,7 +13,7 @@ Moreover, we will use Redis to store tasks when we are running the application l
 
 ### Overview of Dapr State Management API
 
-Dapr's state management API allows you to save, read, and query key/value pairs in the supported state stores. To try this out and without doing any code changes or installing any NuGet packages we can directly invoke the State Management API and store the data on Redis locally. When you initialized Dapr in your local development environment, it installed Redis container instance locally. So we can use Redis locally to store and retrieve state. If you navigate to the path `%USERPROFILE%\.dapr\components` you will find a file named `statestore.yaml`. Inside this file, you will see the properties needed to access the local Redis instance. The [state store template component file structure](https://docs.dapr.io/operations/components/setup-state-store/) can be found on this link.
+Dapr's state management API allows you to save, read, and query key/value pairs in the supported state stores. To try this out and without doing any code changes or installing any NuGet packages we can directly invoke the State Management API and store the data on Redis locally. When you initialized Dapr in your local development environment, it installed Redis container instance locally. So we can use Redis locally to store and retrieve state. If you navigate to the path `%USERPROFILE%\.dapr\components (assuming you are using windows)` you will find a file named `statestore.yaml`. Inside this file, you will see the properties needed to access the local Redis instance. The [state store template component file structure](https://docs.dapr.io/operations/components/setup-state-store/) can be found on this link.
 
 To try out the State Management APIs, run the Backend API from VS Code by running the following command. Remember to replace the place holders with your own values:
 
@@ -102,11 +104,11 @@ For example if you execute the following GET [http://localhost:3500/v1.0/state/s
 }
 ```
 
-### Use Dapr Client SDK for State Store Management
+### Use Dapr Client SDK For State Store Management
 
 Whereas in the previous section we demonstrated using Dapr State Store without code changes, we will now introduce a change on the Backend API and create a new service named `TasksStoreManager.cs` which will implement the interface `ITasksManager.cs` to start storing tasks data on the persist store. Locally we will start testing with Redis, then we are going to change the state store to use Azure Cosmos DB.
 
-#### 1. Add Dapr Client SDK to the Backend API
+#### 1. Add Dapr Client SDK to The Backend API
 
 Similar to what we have done in the Frontend Web App, we need to use Dapr Client SDK to manage the state store. Update below file with highlighted lines:
 
@@ -119,7 +121,7 @@ Similar to what we have done in the Frontend Web App, we need to use Dapr Client
     </ItemGroup>
     ```
 
-#### 2. Create a new concrete implementation to manage tasks persistence
+#### 2. Create a New Concrete Implementation to Manage Tasks Persistence
 
 As you recall from the previous module, we were storing the tasks in memory. Now we need to store them in Redis and later on Azure Cosmos DB. 
 The key thing to keep in mind here is that switching from redis to Azure Cosmos DB won't require changing the code below which is a huge advantage of using Dapr.
@@ -139,7 +141,7 @@ Add below file under the folder named **Services**. This file will implement the
     The query API will not work against the local Redis store as you need to install [RediSearch](https://redis.io/docs/stack/search/) locally on your machine which is out of the scope for this workshop. 
     It will work locally once we switch to Azure Cosmos DB.
 
-#### 3. Register the TasksStoreManager new service and DaprClient
+#### 3. Register the TasksStoreManager New Service and DaprClient
 
 Now we need to register the new service named `TasksStoreManager` and `DaprClient` when the Backend API app starts up. Update the below file with the highlighted text as shown below.
 
@@ -216,7 +218,7 @@ az cosmosdb keys list `
 --resource-group $RESOURCE_GROUP
 ```
 
-**2. Create a Component file for State Store Management:** Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. 
+**2. Create a Component File for State Store Management:** Dapr uses a modular design where functionality is delivered as a component. Each component has an interface definition. 
 All the components are pluggable so that you can swap out one component with the same interface for another
 
 Components are configured at design-time with a YAML file which is stored in either a components/local folder within your solution, or globally in the `.dapr` folder created when invoking `dapr init`. 
@@ -331,7 +333,7 @@ Keep a note of the property `principalId` as we are going to use it in the next
 }
 ```
 
-#### 2. Assign the container app system-identity to the built-in Cosmos DB role
+#### 2. Assign the Container App System-Identity To the Built-in Cosmos DB Role
 
 Next, we need to associate the container app system-identity with the target Cosmos DB resource. 
 You can read more about Azure built-in roles for Cosmos DB or how to create custom fine-tuned roles [here](https://learn.microsoft.com/en-us/azure/cosmos-db/how-to-setup-rbac#built-in-role-definitions). 
@@ -361,7 +363,7 @@ We have to create a [dapr component schema file](https://learn.microsoft.com/en-
 Azure Container Apps. Reason for this variance is that ACA Dapr schema is slightly simplified to support Dapr components and removes unnecessary fields, including `apiVersion`, `kind`, and redundant metadata and 
 spec properties.
 
-#### 1. Create an ACA-Dapr Component file for State Store Management
+#### 1. Create an ACA-Dapr Component File For State Store Management
 
 Here it is recommended to separate the component files that will be used when deploying to Azure Container Apps from the ones which we will use when running our application locally (Dapr self-hosted). 
 
@@ -381,7 +383,7 @@ Create a new folder named **aca-components** under the directory **TasksTracker.
     - We are not referencing any Cosmos DB Keys/Connection strings as the authentication between Dapr and Cosmos DB will be configured using Managed Identities. 
     - We are setting the `scopes` array value to `tasksmanager-backend-api` to ensure Cosmos DB component is loaded at runtime by only the appropriate container apps. In our case it will be needed only for the container apps with Dapr application IDs `tasksmanager-backend-api`. In future modules we are going to include another container app which needs to access Cosmos DB.
 
-#### 2. Build Frontend Web App and Backend API App images and push them to ACR
+#### 2. Build Frontend Web App and Backend API App Images and Push Them to ACR
 
 As we have done previously we need to build and deploy both app images to ACR, so they are ready to be deployed to Azure Container Apps. 
 To do so, continue using the same PowerShell console and paste the code below (Make sure you are on the following directory **TasksTracker.ContainerApps**):
@@ -428,7 +430,7 @@ az containerapp dapr enable --name $FRONTEND_WEBAPP_NAME `
 
     For a complete list of the supported Dapr sidecar configurations in Container Apps, you can refer to [this link](https://learn.microsoft.com/en-us/azure/container-apps/dapr-overview?tabs=bicep1%2Cyaml#dapr-enablement).
 
-#### 5. Deploy new revisions of the Frontend Web App and Backend API to Container Apps
+#### 5. Deploy New Revisions of the Frontend Web App and Backend API to Container Apps
 
 The last thing we need to do here is to update both container apps and deploy the new images from ACR. To do so we need to run the commands found below. 
 

docs/aca/05-aca-dapr-pubsubapi/TasksNotifierController.cs

@@ -1,5 +1,7 @@
 using Dapr.Client;
 using Microsoft.AspNetCore.Mvc;
+using SendGrid;
+using SendGrid.Helpers.Mail;
 using TasksTracker.Processor.Backend.Svc.Models;
 
 namespace TasksTracker.Processor.Backend.Svc.Controllers
@@ -10,27 +12,50 @@ public class TasksNotifierController : ControllerBase
     {
         private readonly IConfiguration _config;
         private readonly ILogger _logger;
-        public TasksNotifierController(IConfiguration config, ILogger<TasksNotifierController> logger)
+        private readonly DaprClient _daprClient;
+        public TasksNotifierController(IConfiguration config, ILogger<TasksNotifierController> logger, DaprClient daprClient)
         {
             _config = config;
             _logger = logger;
+            _daprClient = daprClient;
         }
 
-        public IActionResult Get()
-        {
-            return Ok();
-        }
-
-        [Dapr.Topic("taskspubsub", "tasksavedtopic")]
+        [Dapr.Topic("dapr-pubsub-servicebus", "tasksavedtopic")]
         [HttpPost("tasksaved")]
         public async Task<IActionResult> TaskSaved([FromBody] TaskModel taskModel)
         {
             _logger.LogInformation("Started processing message with Task Name '{0}'", taskModel.TaskName);
-
-             //Do the actual sending of emails here, return 200 ok to consumer of the message
-             return Ok();
-            //In case we need to return message back to the topic, return http 400 bad request
-            //return BadRequest();
+ 
+            var sendGridResponse = await SendEmail(taskModel);
+ 
+            if (sendGridResponse.Item1)
+            {
+                return Ok($"SendGrid response staus code: {sendGridResponse.Item1}");
+            }
+ 
+            return BadRequest($"Failed to send email, SendGrid response status code: {sendGridResponse.Item1}");
+        }
+ 
+        private async Task<Tuple<bool, string>> SendEmail(TaskModel taskModel)
+        {
+ 
+            var apiKey = _config.GetValue<string>("SendGrid:ApiKey");
+            var sendEmailResponse = true;
+            var sendEmailStatusCode = System.Net.HttpStatusCode.Accepted;
+            var client = new SendGridClient(apiKey);
+            var from = new EmailAddress("taiseer.joudeh@gmail.com", "Tasks Tracker Notification");
+            var subject = $"Task '{taskModel.TaskName}' is assigned to you!";
+            var to = new EmailAddress(taskModel.TaskAssignedTo, taskModel.TaskAssignedTo);
+            var plainTextContent = $"Task '{taskModel.TaskName}' is assigned to you. Task should be completed by the end of: {taskModel.TaskDueDate.ToString("dd/MM/yyyy")}";
+            var htmlContent = plainTextContent;
+            var msg = MailHelper.CreateSingleEmail(from, to, subject, plainTextContent, htmlContent);
+           
+	     var response = await client.SendEmailAsync(msg);
+	     sendEmailResponse = response.IsSuccessStatusCode;
+	     sendEmailStatusCode = response.StatusCode;
+           
+	     return new Tuple<bool, string>(sendEmailResponse, sendEmailStatusCode.ToString());
+ 
         }
     }
 }