Welcome to Beyond #30DaysOfServerless! in October!

Yes, it's October!! And since we ended #ServerlessSeptember with a focus on End-to-End Development for Serverless on Azure, we thought it would be good to share updates in October that can help you skill up even further.

Today, we're following up on the Code to Cloud with azd blog post (Day #29) where we introduced the Azure Developer CLI (azd), an open-source tool for streamlining your end-to-end developer experience going from local development environment to Azure cloud. In today's post, we celebrate the October 2022 release of the tool, with three cool new features.

And if it's October, it must be #Hacktoberfest!! Read on to learn about how you can take advantage of one of the new features, to contribute to the azd open-source community and ecosystem!

Ready? Let's go!

What We'll Cover​

• Azure Friday: Introducing the Azure Developer CLI (Video)
• October 2022 Release: What's New in the Azure Developer CLI?
  • Azure Pipelines for CI/CD: Learn more
  • Improved Infrastructure as Code structure via Bicep modules: Learn more
  • A new azd template gallery: The new azd-templates gallery for community use! Learn more
• Awesome-Azd: The new azd-templates gallery for Community use
  • Features: discover, create, contribute, request - templates
  • Hacktoberfest: opportunities to contribute in October - and beyond!

Azure Friday​

This post is a follow-up to our #ServerlessSeptember post on Code to Cloud with Azure Developer CLI where we introduced azd, a new open-source tool that makes it quick and simple for you to move your application from a local development environment to Azure, streamlining your end-to-end developer workflow in the process.

Prefer to watch a video overview? I have you covered! Check out my recent conversation with Scott Hanselman on Azure Friday where we:

• talked about the code-to-cloud developer journey
• walkthrough the ins and outs of an azd template
• explored Azure Developer CLI commands in the terminal and VS Code, and
• (probably most importantly) got a web app up and running on Azure with a database, Key Vault and monitoring all in a couple of minutes

October Release​

We're pleased to announce the October 2022 release of the Azure Developer CLI (currently 0.3.0-beta.2). Read the release announcement for more details. Here are the highlights:

• Azure Pipelines for CI/CD: This addresses azure-dev#101, adding support for Azure Pipelines (alongside GitHub Actions) as a CI/CD provider. Learn more about usage and related documentation.
• Improved Infrastructure as Code structure via Bicep modules: This addresses azure-dev#543, which recognized the complexity of using a single resources.bicep file for all resources. With this release, azd templates now come with Bicep modules organized by purpose making it easier to edit and understand. Learn more about this structure, and how to use it.
• New Templates Gallery - awesome-azd: This addresses azure-dev#398, which aimed to make templates more discoverable and easier to contribute. Learn more about how the new gallery improves the template discovery experience.

In the next section, we'll dive briefly into the last feature, introducing the new awesome-azd site and resource for templates discovery and contribution. And, since it's #Hacktoberfest season, we'll talk about the Contributor Guide and the many ways you can contribute to this project - with, or without, code.

It's awesome-azd​

Welcome to awesome-azd a new template gallery hosted on GitHub Pages, and meant to be a destination site for discovering, requesting, and contributing azd-templates for community use!

In addition, it's README reflects the awesome-list resource format, providing a location for the community to share "best of" resources for Azure Developer CLI - from blog posts and videos, to full-scale tutorials and templates.

• Visit the awesome-azd Gallery
• Browse the awesome-azd README

The Gallery is organized into three main areas:

• Gallery page hosting templates.
• Contributor Guide with an FAQ for contributors.
• Custom Issues for the types of contributions you can make

Take a minute to explore the Gallery and note the features:

• Search for templates by name
• Requested Templates - indicating asks from the community
• Featured Templates - highlighting high-quality templates
• Filters - to discover templates by and/or query combinations

Check back often to see the latest contributed templates and requests!

Hacktoberfest​

So, why is this a good time to talk about the Gallery? Because October means it's time for #Hacktoberfest - a month-long celebration of open-source projects and their maintainers, and an opportunity for first-time contributors to get support and guidance making their first pull-requests! Check out the #Hacktoberfest topic on GitHub for projects you can contribute to.

And we hope you think of awesome-azd as another possible project to contribute to.

• Explore Custom Issues for actionable ways to contribute code.
• Explore Other Ways To Help for equally important non-code contributions.

Check out the FAQ section to learn how to create, discover, and contribute templates. Or take a couple of minutes to watch this video walkthrough from Jon Gallant:

And don't hesitate to reach out to us - either via Issues on the repo, or in the Discussions section of this site, to give us feedback!

Happy Hacking! 🎃

It's Serverless September in a Nutshell! Join us as we unpack our month-long learning journey exploring the core technology pillars for Serverless architectures on Azure. Then end with a look at next steps to build your Cloud-native applications on Azure.

What We'll Cover​

• Functions-as-a-Service (FaaS)
• Microservices and Containers
• Serverless Integrations
• End-to-End Solutions
• Developer Tools & #Hacktoberfest

Building Cloud-native Apps​

By definition, cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. You can learn more about cloud-native in Kendall Roden's #ServerlessSeptember post on Going Cloud-native with Azure Container Apps.

Serveless technologies accelerate productivity and minimize costs for deploying applications at cloud scale. So, what can we build with serverless technologies in cloud-native on Azure? Anything that is event-driven - examples include:

• Microservices - scaled by KEDA-compliant triggers
• Public API Endpoints - scaled by #concurrent HTTP requests
• Event-Driven Applications - scaled by length of message queue
• Web Applications - scaled by #concurrent HTTP requests
• Background Process - scaled by CPU and Memory usage

Great - but as developers, we really want to know how we can get started building and deploying serverless solutions on Azure. That was the focus of our #ServerlessSeptember journey. Let's take a quick look at the four key themes.

Functions-as-a-Service (FaaS)​

Functions-as-a-Service (FaaS) is the epitome of developer productivity for full-stack modern apps. As developers, you don't manage infrastructure and focus only on business logic and application code. And, with Serverless Compute you only pay for when your code runs - making this the simplest first step to begin migrating your application to cloud-native.

In Azure, FaaS is provided by Azure Functions. Check out our Functions + Serverless on Azure to go from learning core concepts, to building your first Functions app in your programming language of choice. Azure functions support multiple programming languages including C#, F#, Java, JavaScript, Python, Typescript, and PowerShell.

Want to get extended language support for languages like Go, and Rust? You can Use Custom Handlers to make this happen! But what if you want to have long-running functions, or create complex workflows involving more than one function? Read our post on Durable Entities to learn how you can orchestrate this with Azure Functions.

Check out this recent AskTheExpert Q&A session with the Azure Functions team to get answers to popular community questions on Azure Functions features and usage.

Microservices and Containers​

Functions-as-a-Service is an ideal first step towards serverless development. But Functions are just one of the 5 pillars of cloud-native. This week we'll look at two of the other pillars: microservices and containers - with specific focus on two core technologies: Azure Container Apps and Dapr (Distributed Application Runtime).

In this 6-part series of posts, we walk through each technology independently, before looking at the value of building Azure Container Apps with Dapr.

• In Hello Container Apps we learned core concepts & deployed our first ACA.
• In Microservices Communication we learned about ACA environments and virtual networks, and how microservices communicate in ACA with a hands-on tutorial.
• In Scaling Your Container Apps we learned about KEDA (Kubernetes Event-Driven Autoscaler) and configuring ACA for autoscaling with KEDA-compliant triggers.
• In Build with Dapr we introduced the Distributed Application Runtime (Dapr), exploring its Building Block APIs and sidecar architecture for working with ACA.
• In Secure ACA Access we learned how to secure ACA access to external services with - and without - Dapr, covering Secret Stores and Managed Identity.
• Finally, Build ACA with Dapr tied it all together with a enterprise app scenario where an orders processor (ACA) uses Dapr APIs (PubSub, State Management) to receive and store order messages from Azure Service Bus.

Check out this recent AskTheExpert Q&A session with the Azure Container Apps team for answers to popular community questions on core features and usage.

Serverless Integrations​

In the first half of the month we looked at compute resources for building and deploying serverless applications. In the second half, we look at integration tools and resources that automate developer workflows to streamline the end-to-end developer experience.

In Azure, this is enabled by services like Azure Logic Apps and Azure Event Grid. Azure Logic Apps provides a visual designer to create and automate workflows with little or no code involved. Azure Event Grid provides a highly-scable event broker with support for pub/sub communications to drive async event-driven architectures.

• In Tracking Weather Data Changes With Logic Apps we look at how you can use Logic Apps to integrate the MSN weather service with Azure CosmosDB, allowing automated collection of weather data on changes.
• In Teach the Cloud to Read & Categorize Mail we take it a step further, using Logic Apps to automate a workflow that includes a Computer Vision service to "read" images and store the results to CosmosDB.
• In Integrate with Microsoft Graph we explore a multi-cloud scenario (Azure + M365) where change notifications from Microsoft Graph can be integrated using Logic Apps and Event Hubs to power an onboarding workflow.
• In Cloud Events with Event Grid we learn about the CloudEvents specification (for consistently describing event data) - and learn how Event Grid brokers events in this format. Azure Logic Apps can be an Event handler (subscriber) that uses the event to trigger an automated workflow on receipt.

Want to explore other such integrations? Browse Azure Architectures and filter by selected Azure services for more real-world scenarios.

End-to-End Solutions​

We've covered serverless compute solutions (for building your serverless applications) and serverless integration services to automate end-to-end workflows in synchronous or asynchronous event-driven architectures. In this final week, we want to leave you with a sense of end-to-end development tools and use cases that can be enabled by Serverless on Azure. Here are some key examples:

Article	Description
	In this tutorial, you'll learn to deploy a containerized ASP.NET Core 6.0 application to Azure Container Apps - with a Blazor front-end and two Web API projects
	In this tutorial you learn to build and deploy a Java application running on Spring Boot, by publishing it in a container to Azure Container Registry, then deploying to Azure Container Apps,, from ACR, via the Azure Portal.
	In this step-by-step tutorial you learn to integrate a serverless application (built on Azure Functions and OpenAPI) with Power Platforms custom connectors via Azure API Management (API-M).This pattern can empower a new ecosystem of fusion apps for cases like inventory management.
	And in our Serverless Hacks initiative, we walked through an 8-step hack to build a serverless tollbooth. Check out this 12-part video walkthrough of a reference solution using .NET.

Developer Tools​

But wait - there's more. Those are a sample of the end-to-end application scenarios that are built on serverless on Azure. But what about the developer experience? In this article, we say hello to the Azure Developer CLI - an open-source tool that streamlines your develop-deploy workflow, with simple commands that map to core stages of your development journey. Go from code to cloud with one CLI

And watch this space for more such tutorials and content through October, including a special #Hacktoberfest focused initiative to encourage and support first-time contributors to open-source. Here's a sneak peek at the project we plan to share - the new awesome-azd templates gallery.

Join us at Microsoft Ignite!​

Want to continue your learning journey, and learn about what's next for Serverless on Azure? Microsoft Ignite happens Oct 12-14 this year and has multiple sessions on relevant technologies and tools. Check out the Session Catalog and register here to attend online.

Welcome to Day 29 of #30DaysOfServerless!

We are in the final days of the 30-day journey so it seemed appropriate to end the End-to-End Developer Journey with a discussion on tooling that can simplify and enhance the developer experience from development to deployment and beyond. Say hello to the Azure Developer CLI.

Ready? Let's go!

What We'll Cover​

• A new tool has entered the chat: Azure Developer CLI (azd)
• (Template) Anatomy 101: What makes an azd template?
• End-to-end support: Move code to cloud in a single step!
• Best practices: Monitor your application and run CI/CD on every commit
• Exercise: Try this yourself or create your own azd template
• Resources: For self-study!

A new tool has entered the chat: What is the Azure Developer CLI (azd)?​

The Azure Developer CLI (azd) is a new, open source tool that makes it quick and simple for you to move your application from your local development environment to Azure while considering your end-to-end developer workflow. You might be familiar with other CLIs that focus on Infrastructure as Code or scaffolding your application but the Azure Developer CLI does all that and more!

The Azure Developer CLI commands are simple, high-level and map to core stages in your developer workflow. Think project initialization/creation, build, deploy, repeat!

By using idiomatic and flexible application templates, the Azure Developer CLI uses recipes for common application architectures that you can customize for your use case. These templates include:

• best practices
• sample application code that goes beyond "Hello World!"
• infrastructure as code assets so you can move your code to the cloud and set up monitoring for your application, and
• all the bits to set up CI/CD to run on every commit to your repo against resources on Azure

...all in the language(s) you're most comfortable in. You can use an existing template or even create your own (more on that later!).

(Template) Anatomy 101: What makes an azd template?​

So now that you've been introduced to the Azure Developer CLI, let's take a look at an azd-enabled codebase, which we call a template. You can think of a template as a recipe - it provides a solid foundation that you can customize depending on your preference/use case/requirements.

To make this concrete and because it's #ServerlessSeptember, we're going to walk through this ToDo application template that uses Azure Static Web Apps and Azure Functions.

Let's talk about the files in terms of their purpose:

Azure Developer CLI-specific files​

• azure.yaml - contains metadata that describes the application (Azure hosts, languages, template name) and serves as an entrypoint for functionality in Visual Studio Code (oh yeah, you can also use azd using a VS Code extension!).

Application development support (code, run, debug, test)​

• .devcontainer/ - support for if you're writing code in a container
• .vscode/ - support for local development in Visual Studio Code via launch.json (for debugging) and tasks.json (for spinning up the web app for local development)
• src/ - contains all the sample application code which you can modify or swap out for your own application
• tests/ - test for the application, written using Playwright

Infrastructure as Code (provisioning and deploying infrastructure on Azure, programmatically)​

• infra/ - contains all infrastructure as code (IaC) assets written in Bicep or Terraform; includes logic to set up all components we need to set up the application on Azure, wire everything up securely, and monitor application health, performance and usage!

CI/CD​

• .github/ - contains a GitHub Actions workflow to set up a CI/CD pipeline that runs on every new commit to the repo
• .azdo/ - contains a Azure Pipelines workflow to set up a CI/CD pipeline that runs on every new commit to the repo

End-to-end support: Move code to cloud in a single step!​

If you want to follow along in this section and don't already have the Azure Developer CLI installed, check out these instructions to install it on Windows, Linux or MacOS in your favorite terminal!​

So now that we've gone over what this template contains on GitHub, let's pull this template code down to our local machine, set it up for local development, provision the right infrastructure, and deploy the code on Azure in a single step.

When designing the CLI, we wanted the experience to be both flexible and non-magical (no side effects, easy to understand). So, we're going to run this all with azd up but you could alternatively run a series of three commands and the outcome would be the same - azd init --t Azure-Samples/todo-python-mongo-swa-func (to pull the code down to your machine), azd provision (to provision infrastructure) and then azd deploy (to deploy application code on Azure). Choose your own adventure!

So let's walk through it. On running azd up -t todo-python-mongo-swa-func, I'm prompted for a couple pieces of information as part of the azd init process being run under the hood:

• An environment name - the prefix for the resource group that will be created to hold all Azure resources
• An Azure region - the Azure location where your resources will be deployed
• An Azure subscription - the Azure subscription where your resources will be deployed

Once that information is provided, azd will pull down the code from GitHub and create a .azure/ directory in the project root that contains all Azure Developer CLI environment information that you just entered. This directory will be important when it comes time to provision and deploy infrastructure in the next step in the up process.

The next step here is provisioning. azd is running azd provision on your behalf and leveraging the IaC assets in the .infra/ directory in the project. As the tool works to provision, you'll see an output of each resource (name alongside a unique identifier which you can use to reference back to the Azure Portal, if you want)

Finally, the final step here in running azd up is deployment. azd is running azd deploy and deploying the application code to the resources that we're provisioned in the previous phase of the process. Once this has completed, you'll be able to click on two different endpoint URLs - one for the backend and one for the frontend.

The backend endpoint (service api) hosts the specification for the API via the openapi.yaml file that's also in the root of the project template. You can explore the endpoints that are available in the web app here.

The frontend endpoint (service web) hosts a fully-fledged and functional ToDo web app with a UI, Cosmos DB for the database and Key Vault for application secrets. This isn't just application hosting. It's really everything you need to be successful and productive, all set up on your behalf by the Azure Developer CLI.

...and that's it! We've successfully deployed our application on Azure!

But there's more!

Best practices: Monitoring and CI/CD!​

In my opinion, it's not enough to just set up the application on Azure! I want to know that my web app is performant and serving my users reliably! I also want to make sure that I'm not inadvertently breaking my application as I continue to make changes to it. Thankfully, the Azure Developer CLI also handles all of this via two additional commands - azd monitor and azd pipeline config.

Application Monitoring​

When we provisioned all of our infrastructure, we also set up application monitoring via a Bicep file in our .infra/ directory that spec'd out an Application Insights dashboard. By running azd monitor we can see the dashboard with live metrics that was configured for the application.

We can also navigate to the Application Dashboard by clicking on the resource group name, where you can set a specific refresh rate for the dashboard, and see usage, reliability, and performance metrics over time.

I don't know about everyone else but I have spent a ton of time building out similar dashboards. It can be super time-consuming to write all the queries and create the visualizations so this feels like a real time saver.

CI/CD​

Finally let's talk about setting up CI/CD! This might be my favorite azd feature. As I mentioned before, the Azure Developer CLI has a command, azd pipeline config, which uses the files in the .github/ directory to set up a GitHub Action. More than that, if there is no upstream repo, the Developer CLI will actually help you create one. But what does this mean exactly? Because our GitHub Action is using the same commands you'd run in the CLI under the hood, we're actually going to have CI/CD set up to run on every commit into the repo, against real Azure resources. What a sweet collaboration feature!

That's it! We've gone end-to-end with the Azure Developer CLI - initialized a project, provisioned the resources on Azure, deployed our code on Azure, set up monitoring logs and dashboards, and set up a CI/CD pipeline with GitHub Actions to run on every commit into the repo (on real Azure resources!).

Exercise: Try it yourself or create your own template!​

As an exercise, try out the workflow above with any template on GitHub!

Or, try turning your own project into an Azure Developer CLI-enabled template by following this guidance. If you create your own template, don't forget to tag the repo with the azd-templates topic on GitHub to help others find it (unfamiliar with GitHub topics? Learn how to add topics to your repo)! We'd also love to chat with you about your experience creating an azd template - if you're open to providing feedback around this, please fill out this form!

Resources​

• Read more about the Azure Developer CLI preview release
• Install the Azure Developer CLI
• Familiarize yourself with our Developer Hub
• Take a look at some foundational templates on GitHub
• Download the Azure Developer CLI VS Code extension

Welcome to Day 28 of #30DaysOfServerless!

Since it's the serverless end-to-end week, I'm going to discuss how to use a serverless application – Azure Functions with OpenAPI extension – to be seamlessly integrated with Power Platform custom connector through Azure API Management - in a post I call "Where am I? My GPS Location with Serverless Power Platform Custom Connector"

OK. Are you ready? Let's get started!

What We'll Cover​

• What is Power Platform custom connector?
• Proxy app to Google Maps and Naver Map API
• API Management integration
• Two ways of building custom connector
• Where am I? – Power Apps app
• Exercise: Try this yourself!
• Resources: For self-study!

What is Power Platform custom connector?​

Power Platform is a low-code/no-code application development tool for fusion teams that consist of a group of people. Those people come from various disciplines, including field experts (domain experts), IT professionals and professional developers, to draw business values successfully. Within the fusion team, the domain experts become citizen developers or low-code developers by Power Platform. In addition, Making Power Platform more powerful is that it offers hundreds of connectors to other Microsoft 365 and third-party services like SAP, ServiceNow, Salesforce, Google, etc.

However, what if you want to use your internal APIs or APIs not yet offering their official connectors? Here's an example. If your company has an inventory management system, and you want to use it within your Power Apps or Power Automate. That point is exactly where Power Platform custom connectors is necessary.

Therefore, Power Platform custom connectors enrich those citizen developers' capabilities because those connectors can connect any API applications for the citizen developers to use.

In this post, let's build a custom connector that provides a static map image generated by Google Maps API and Naver Map API using your GPS location.

Proxy app to Google Maps and Naver Map API​

First, let's build an Azure Functions app that connects to Google Maps and Naver Map. Suppose that you've already got the API keys for both services. If you haven't yet, get the keys first by visiting here for Google and here for Naver. Then, store them to local.settings.json within your Azure Functions app.

{
  "Values": {
    ...
    "Maps__Google__ApiKey": "<GOOGLE_MAPS_API_KEY>",
    "Maps__Naver__ClientId": "<NAVER_MAP_API_CLIENT_ID>",
    "Maps__Naver__ClientSecret": "<NAVER_MAP_API_CLIENT_SECRET>"
  }
}

Here's the sample logic to get the static image from Google Maps API. It takes the latitude and longitude of your current location and image zoom level, then returns the static map image. There are a few hard-coded assumptions, though:

• The image size should be 400x400.
• The image should be in .png format.
• The marker should show be red and show my location.

public class GoogleMapService : IMapService
{
    public async Task<byte[]> GetMapAsync(HttpRequest req)
    {
        var latitude = req.Query["lat"];
        var longitude = req.Query["long"];
        var zoom = (string)req.Query["zoom"] ?? "14";

        var sb = new StringBuilder();
        sb.Append("https://maps.googleapis.com/maps/api/staticmap")
          .Append($"?center={latitude},{longitude}")
          .Append("&size=400x400")
          .Append($"&zoom={zoom}")
          .Append($"&markers=color:red|{latitude},{longitude}")
          .Append("&format=png32")
          .Append($"&key={this._settings.Google.ApiKey}");
        var requestUri = new Uri(sb.ToString());

        var bytes = await this._http.GetByteArrayAsync(requestUri).ConfigureAwait(false);

        return bytes;
    }
}

The NaverMapService class has a similar logic with the same input and assumptions. Here's the code:

public class NaverMapService : IMapService
{
    public async Task<byte[]> GetMapAsync(HttpRequest req)
    {
        var latitude = req.Query["lat"];
        var longitude = req.Query["long"];
        var zoom = (string)req.Query["zoom"] ?? "13";

        var sb = new StringBuilder();
        sb.Append("https://naveropenapi.apigw.ntruss.com/map-static/v2/raster")
          .Append($"?center={longitude},{latitude}")
          .Append("&w=400")
          .Append("&h=400")
          .Append($"&level={zoom}")
          .Append($"&markers=color:blue|pos:{longitude}%20{latitude}")
          .Append("&format=png")
          .Append("&lang=en");
        var requestUri = new Uri(sb.ToString());

        this._http.DefaultRequestHeaders.Clear();
        this._http.DefaultRequestHeaders.Add("X-NCP-APIGW-API-KEY-ID", this._settings.Naver.ClientId);
        this._http.DefaultRequestHeaders.Add("X-NCP-APIGW-API-KEY", this._settings.Naver.ClientSecret);

        var bytes = await this._http.GetByteArrayAsync(requestUri).ConfigureAwait(false);

        return bytes;
    }
}

Let's take a look at the function endpoints. Here's for the Google Maps and Naver Map. As the GetMapAsync(req) method returns a byte array value, you need to transform it as FileContentResult, with the content type of image/png.

// Google Maps
public class GoogleMapsTrigger
{
    [FunctionName(nameof(GoogleMapsTrigger.GetGoogleMapImage))]
    public async Task<IActionResult> GetGoogleMapImage(
        [HttpTrigger(AuthorizationLevel.Anonymous, "GET", Route = "google/image")] HttpRequest req)
    {
        this._logger.LogInformation("C# HTTP trigger function processed a request.");

        var bytes = await this._service.GetMapAsync(req).ConfigureAwait(false);

        return new FileContentResult(bytes, "image/png");
    }
}

// Naver Map
public class NaverMapsTrigger
{
    [FunctionName(nameof(NaverMapsTrigger.GetNaverMapImage))]
    public async Task<IActionResult> GetNaverMapImage(
        [HttpTrigger(AuthorizationLevel.Anonymous, "GET", Route = "naver/image")] HttpRequest req)
    {
        this._logger.LogInformation("C# HTTP trigger function processed a request.");

        var bytes = await this._service.GetMapAsync(req).ConfigureAwait(false);

        return new FileContentResult(bytes, "image/png");
    }
}

Then, add the OpenAPI capability to each function endpoint. Here's the example:

// Google Maps
public class GoogleMapsTrigger
{
    [FunctionName(nameof(GoogleMapsTrigger.GetGoogleMapImage))]
    // ⬇️⬇️⬇️ Add decorators provided by the OpenAPI extension ⬇️⬇️⬇️
    [OpenApiOperation(operationId: nameof(GoogleMapsTrigger.GetGoogleMapImage), tags: new[] { "google" })]
    [OpenApiParameter(name: "lat", In = ParameterLocation.Query, Required = true, Type = typeof(string), Description = "The **latitude** parameter")]
    [OpenApiParameter(name: "long", In = ParameterLocation.Query, Required = true, Type = typeof(string), Description = "The **longitude** parameter")]
    [OpenApiParameter(name: "zoom", In = ParameterLocation.Query, Required = false, Type = typeof(string), Description = "The **zoom level** parameter – Default value is `14`")]
    [OpenApiResponseWithBody(statusCode: HttpStatusCode.OK, contentType: "image/png", bodyType: typeof(byte[]), Description = "The map image as an OK response")]
    // ⬆️⬆️⬆️ Add decorators provided by the OpenAPI extension ⬆️⬆️⬆️
    public async Task<IActionResult> GetGoogleMapImage(
        [HttpTrigger(AuthorizationLevel.Anonymous, "GET", Route = "google/image")] HttpRequest req)
    {
        ...
    }
}

// Naver Map
public class NaverMapsTrigger
{
    [FunctionName(nameof(NaverMapsTrigger.GetNaverMapImage))]
    // ⬇️⬇️⬇️ Add decorators provided by the OpenAPI extension ⬇️⬇️⬇️
    [OpenApiOperation(operationId: nameof(NaverMapsTrigger.GetNaverMapImage), tags: new[] { "naver" })]
    [OpenApiParameter(name: "lat", In = ParameterLocation.Query, Required = true, Type = typeof(string), Description = "The **latitude** parameter")]
    [OpenApiParameter(name: "long", In = ParameterLocation.Query, Required = true, Type = typeof(string), Description = "The **longitude** parameter")]
    [OpenApiParameter(name: "zoom", In = ParameterLocation.Query, Required = false, Type = typeof(string), Description = "The **zoom level** parameter &ndash; Default value is `13`")]
    [OpenApiResponseWithBody(statusCode: HttpStatusCode.OK, contentType: "image/png", bodyType: typeof(byte[]), Description = "The map image as an OK response")]
    // ⬆️⬆️⬆️ Add decorators provided by the OpenAPI extension ⬆️⬆️⬆️
    public async Task<IActionResult> GetNaverMapImage(
        [HttpTrigger(AuthorizationLevel.Anonymous, "GET", Route = "naver/image")] HttpRequest req)
    {
        ...
    }
}

Run the function app in the local. Here are the latitude and longitude values for Seoul, Korea.

• latitude: 37.574703
• longitude: 126.978519

It seems to be working! Let's deploy it to Azure.

API Management integration​

Visual Studio 2022 provides a built-in deployment tool for Azure Functions app onto Azure. In addition, the deployment tool supports seamless integration with Azure API Management as long as your Azure Functions app enables the OpenAPI capability. In this post, I'm going to use this feature. Right-mouse click on the Azure Functions project and select the "Publish" menu.

Then, you will see the publish screen. Click the "➕ New" button to create a new publish profile.

Choose "Azure" and click the "Next" button.

Select the app instance. This time simply pick up the "Azure Function App (Windows)" option, then click "Next".

If you already provision an Azure Function app instance, you will see it on the screen. Otherwise, create a new one. Then, click "Next".

In the next step, you are asked to choose the Azure API Management instance for integration. Choose one, or create a new one. Then, click "Next".

Finally, select the publish method – either local publish or GitHub Actions workflow. Let's pick up the local publish method for now. Then, click "Finish".

The publish profile has been created. Click "Close" to move on.

Now the function app is ready for deployment. Click the "Publish" button and see how it goes.

The Azure function app has been deployed and integrated with the Azure API Management instance.

Go to the published function app site, and everything looks OK.

And API Management shows the function app integrated perfectly.

Now, you are ready to create a custom connector. Let's move on.

Two ways of building custom connector​

There are two ways to create a custom connector.

Export custom connector from API Management​

First, you can directly use the built-in API Management feature. Then, click the ellipsis icon and select the "Create Power Connector" menu.

Then, you are redirected to this screen. While the "API" and "API display name" fields are pre-populated, you need to choose the Power Platform environment tied to your tenant. Choose an environment, click "Authenticate", and click "Create".

Check your custom connector on Power Apps or Power Automate side.

However, there's a caveat to this approach. Because it's tied to your tenant, you should use the second approach if you want to use this custom connector on the other tenant.

Import custom connector from OpenAPI document or URL​

Click the ellipsis icon again and select the "Export" menu.

On the Export API screen, choose the "OpenAPI v2 (JSON)" panel because Power Platform custom connector currently accepts version 2 of the OpenAPI document.

Download the OpenAPI document to your local computer and move to your Power Apps or Power Automate page under your desired environment. I'm going to use the Power Automate page. First, go to the "Data" ➡️ "Custom connectors" page. Then, click the "➕ New custom connector" ➡️ "Import an OpenAPI file" at the top right corner.

When a modal pops up, give the custom connector name and import the OpenAPI document exported above. Then, click "Continue".

Actually, that's it! Next, click the "✔️ Create connector" button to create the connector.

Go back to the custom connector page, and you will see the "Maps API" custom connector you just created.

So, you are ready to create a Power Apps app to display your location on Google Maps or Naver Map! Let's move on.

Where am I? – Power Apps app​

Open the Power Apps Studio, and create an empty canvas app, named Who am I with a phone layout.

Custom connector integration​

To use the custom connector created above, you need to add it to the Power App. Click the cylinder icon on the left and click the "Add data" button.

Search the custom connector name, "Maps API", and click the custom connector to add.

To use the custom connector, you also need to create a connection to it. Click the "Connect" button and move on.

Now, you've got the connection to the custom connector.

Controls​

Let's build the Power Apps app. First of all, put three controls – Image, Slider and Button onto the canvas.

Click the "Screen1" control and change the value on the property "OnVisible" to the formula below. The formula stores the current slider value in the zoomlevel collection.

ClearCollect(
    zoomlevel,
    Slider1.Value
)

Click the "Botton1" control and change the value on the property "OnSelected" to the formula below. It passes the current latitude, longitude and zoom level to the custom connector and receives the image data. The received image data is stored in the result collection.

ClearCollect(
    result,
    MAPS.GetGoogleMapImage(
        Location.Latitude,
        Location.Longitude,
        { zoom: First(zoomlevel).Value }
    )
)

Click the "Image1" control and change the value on the property "Image" to the formula below. It gets the image data from the result collection.

First(result).Url

Click the "Slider1" control and change the value on the property "OnChange" to the formula below. It stores the current slider value to the zoomlevel collection, followed by calling the custom connector to get the image data against the current location.

ClearCollect(
    zoomlevel,
    Slider1.Value
);
ClearCollect(
    result,
    MAPS.GetGoogleMapImage(
        Location.Latitude,
        Location.Longitude,
        { zoom: First(zoomlevel).Value }
    )
)

That seems to be OK. Let's click the "Where am I?" button. But it doesn't show the image. The First(result).Url value is actually similar to this:

appres://blobmanager/1090a86393a843adbfcf428f0b90e91b/1

It's the image reference value somewhere you can't get there.

Workaround – Power Automate workflow​

Therefore, you need a workaround using a Power Automate workflow to sort out this issue. Open the Power Automate Studio, create an instant cloud flow with the Power App trigger, and give it the "Where am I" name. Then add input parameters of lat, long and zoom.

Add custom connector action to get the map image.

In the action, pass the appropriate parameters to the action.

Add a "Response" action and put the following values into each field.

• "Body" field:

  {
    "base64Image": <power_automate_expression>
  }
  

  The <power_automate_expression> should be concat('data:', body('GetGoogleMapImage')?['$content-type'], ';base64,', body('GetGoogleMapImage')?['$content']).

• "Response Body JSON Schema" field:

  {
    "type": "object",
    "properties": {
      "base64Image": {
        "type": "string"
      }
    }
  }
  

Let's return to the Power Apps Studio and add the Power Automate workflow you created.

Select "Button1" and change the value on the property "OnSelect" below. It replaces the direct call to the custom connector with the Power Automate workflow.

ClearCollect(
    result,
    WhereamI.Run(
        Location.Latitude,
        Location.Longitude,
        First(zoomlevel).Value
    )
)

Also, change the value on the property "OnChange" of the "Slider1" control below, replacing the custom connector call with the Power Automate workflow call.

ClearCollect(
    zoomlevel,
    Slider1.Value
);
ClearCollect(
    result,
    WhereamI.Run(
        Location.Latitude,
        Location.Longitude,
        First(zoomlevel).Value
    )
)

And finally, change the "Image1" control's "Image" property value below.

First(result).base64Image

The workaround has been applied. Click the "Where am I?" button to see your current location from Google Maps.

If you change the slider left or right, you will see either the zoomed-in image or the zoomed-out image.

Now, you've created a Power Apps app to show your current location using:

• Google Maps API through the custom connector, and
• Custom connector written in Azure Functions with OpenAPI extension!

Exercise: Try this yourself!​

You can fork this GitHub repository to your account and play around with it to see how the custom connector works. After forking the repository, make sure that you create all the necessary secrets to your repository documented in the README file.

Then, click the "Deploy to Azure" button, and it will provision all necessary Azure resources and deploy an Azure Functions app for a custom connector.

Once everything is deployed successfully, try to create a Power Apps app and Power Automate workflow to see your current location in real-time!

Resources: For self-study!​

Want to know more about Power Platform custom connector and Azure Functions OpenAPI extension? Here are several resources you can take a look at:

• Microsoft Learn: Transform your business applications with fusion development
• GitHub repository: Azure Functions OpenAPI Extension

Welcome to Day 26 of #30DaysOfServerless!

Today, we have a special set of posts from our Zero To Hero 🚀 initiative, featuring blog posts authored by our Product Engineering teams for #ServerlessSeptember. Posts were originally published on the Apps on Azure blog on Microsoft Tech Community.

What We'll Cover​

• Monitoring your Azure Functions
• Built-in log streaming
• Live Metrics stream
• Troubleshooting Azure Functions

Monitoring your Azure Functions:​

Azure Functions uses Application Insights to collect and analyze log data from individual function executions in your function app.

Using Application Insights​

Application Insights collects log, performance, and error data. By automatically detecting performance anomalies and featuring powerful analytics tools, you can more easily diagnose issues and better understand how your functions are used. These tools are designed to help you continuously improve performance and usability of your functions. You can even use Application Insights during local function app project development.

Typically, you create an Application Insights instance when you create your function app. In this case, the instrumentation key required for the integration is already set as an application setting named APPINSIGHTS_INSTRUMENTATIONKEY. With Application Insights integration enabled, telemetry data is sent to your connected Application Insights instance. This data includes logs generated by the Functions host, traces written from your functions code, and performance data. In addition to data from your functions and the Functions host, you can also collect data from the Functions scale controller.

By default, the data collected from your function app is stored in Application Insights. In the Azure portal, Application Insights provides an extensive set of visualizations of your telemetry data. You can drill into error logs and query events and metrics. To learn more, including basic examples of how to view and query your collected data, see Analyze Azure Functions telemetry in Application Insights.

Using Log Streaming​

In addition to this, you can have a smoother debugging experience through log streaming. There are two ways to view a stream of log files being generated by your function executions.

• Built-in log streaming: the App Service platform lets you view a stream of your application log files. This is equivalent to the output seen when you debug your functions during local development and when you use the Test tab in the portal. All log-based information is displayed. For more information, see Stream logs. This streaming method supports only a single instance and can't be used with an app running on Linux in a Consumption plan.
• Live Metrics Stream: when your function app is connected to Application Insights, you can view log data and other metrics in near real-time in the Azure portal using Live Metrics Stream. Use this method when monitoring functions running on multiple-instances or on Linux in a Consumption plan. This method uses sampled data. Log streams can be viewed both in the portal and in most local development environments.

In addition to this, Azure Functions uses Azure Monitor to monitor the health of your function apps. Azure Functions collects the same kinds of monitoring data as other Azure resources that are described in Azure Monitor data collection. See Monitoring Azure Functions data reference for detailed information on the metrics and logs metrics created by Azure Functions.

Troubleshooting your Azure Functions:​

When you do run into issues with your function app, Azure Functions diagnostics points out what’s wrong. It guides you to the right information to troubleshoot and resolve the issue more easily and quickly.

Let’s explore how to use Azure Functions diagnostics to diagnose and solve common function app issues.

1. Navigate to your function app in the Azure portal.
2. Select Diagnose and solve problems to open Azure Functions diagnostics.
3. Once you’re here, there are multiple ways to retrieve the information you’re looking for. Choose a category that best describes the issue of your function app by using the keywords in the homepage tile. You can also type a keyword that best describes your issue in the search bar. There’s also a section at the bottom of the page that will directly take you to some of the more popular troubleshooting tools. For example, you could type execution to see a list of diagnostic reports related to your function app execution and open them directly from the homepage.

4. For example, click on the Function App Down or Reporting Errors link under Popular troubleshooting tools section. You will find detailed analysis, insights and next steps for the issues that were detected. On the left you’ll see a list of detectors. Click on them to explore more, or if there’s a particular keyword you want to look for, type it Into the search bar on the top.

Bonus tip:

Welcome to Day 25 of #30DaysOfServerless!

Azure Container Apps enable application code packaged in containers to run and scale without the overhead of managing cloud infrastructure and container orchestration. In this post I'll show you how to deploy a Java application running on Spring Boot in a container to Azure Container Registry and Azure Container Apps.

What We'll Cover​

• Introduction to Deploying Java containers in the cloud
• Step-by-step: Deploying to Azure Container Registry
• Step-by-step: Deploying and running on Azure Container Apps
• Resources: For self-study!

Deploy Java containers to cloud​

We'll deploy a Java application running on Spring Boot in a container to Azure Container Registry and Azure Container Apps. Here are the main steps:

• Create Azure Container Registry (ACR) on Azure portal
• Create Azure Container App (ACA) on Azure portal.
• Deploy code to Azure Container Registry from the Azure CLI.
• Deploy container from ACR to ACA using the Azure portal.

Sign in to Azure from the CLI using the az login command, and follow the prompts in your browser to complete the authentication process. Also, ensure you're running the latest version of the CLI by using the az upgrade command.

1. Get Sample Code​

Fork and clone the sample GitHub repo to your local machine. Navigate to the and click Fork in the top-right corner of the page.

The example code that we're using is a very basic containerized Spring Boot example. There are a lot more details to learn about Spring boot apps in docker, for a deep dive check out this Spring Boot Guide

2. Run Sample Locally (Optional)​

If you have docker installed locally, you can optionally test the code on your local machine. Navigate to the root directory of the forked repository and run the following commands:

docker build -t spring-boot-docker-aca .
docker run -p 8080:8080 spring-boot-docker-aca

Open a browser and go to https://localhost:8080. You should see this message:

Hello Docker World

That indicates the the Spring Boot app is successfully running locally in a docker container.

Next, let's set up an Azure Container Registry an an Azure Container App and deploy this container to the cloud!

3. Step-by-step: Deploy to ACR​

To create a container registry from the portal dashboard, Select Create a resource > Containers > Container Registry.

In the Basics tab, enter values for Resource group and Registry name. The registry name must be unique within Azure, and contain 5-50 alphanumeric characters. Create a new resource group in the West US location named spring-boot-docker-aca. Select the 'Basic' SKU.

Keep the default values for the remaining settings. Then select Review + create, then Create. When the Deployment succeeded message appears, select the container registry in the portal.

Note the registry server name ending with azurecr.io. You will use this in the following steps when you push and pull images with Docker.

3.1 Log into registry using the Azure CLI​

Before pushing and pulling container images, you must log in to the registry instance. Sign into the Azure CLI on your local machine, then run the az acr login command. For this step, use the registry name, not the server name ending with azurecr.io.

From the command line, type:

az acr login --name myregistryname

The command returns Login Succeeded once completed.

3.2 Build & deploy with az acr build​

Next, we're going to deploy the docker container we created earlier using the AZ ACR Build command. AZ ACR Build creates a docker build from local code and pushes the container to Azure Container Registry if the build is successful.

Go to your local clone of the spring-boot-docker-aca repo in the command line, type:

az acr build --registry myregistryname --image spring-boot-docker-aca:v1 .

3.3 List container images​

Once the AZ ACR Build command is complete, you should be able to view the container as a repository in the registry. In the portal, open your registry and select Repositories, then select the spring-boot-docker-aca repository you created with docker push. You should also see the v1 image under Tags.

4. Deploy on ACA​

Now that we have an image in the Azure Container Registry, we can deploy it to Azure Container Apps. For the first deployment, we'll pull the container from our ACR as part of the ACA setup.

4.1 Create a container app​

We'll create the container app at the same place that we created the container registry in the Azure portal. From the portal, select Create a resource > Containers > Container App. In the Basics tab, set these values:

4.2 Enter project details​

4.3 Create an environment​

1. In the Create Container App environment field, select Create new.

2. In the Create Container App Environment page on the Basics tab, enter the following values:

   Setting	Value
   Environment name	Enter my-environment.
   Region	Select westus3.

3. Select OK.

4. Select the Create button at the bottom of the Create Container App Environment page.

5. Select the Next: App settings button at the bottom of the page.

5. App settings tab​

The App settings tab is where you connect to the ACR and pull the repository image:

5.1 Application ingress settings​

5.2 Deploy the container app​

1. Select the Review and create button at the bottom of the page.
2. Select Create.

Once the deployment is successfully completed, you'll see the message: Your deployment is complete.

5.3 Verify deployment​

In the portal, go to the Overview of your spring-boot-docker-aca Azure Container App, and click on the Application Url. You should see this message in the browser:

Hello Docker World

That indicates the the Spring Boot app is running in a docker container in your spring-boot-docker-aca Azure Container App.

Resources: For self-study!​

Once you have an understanding of the basics in ths post, there is so much more to learn!

• Check out the other Serverless September posts.
• For DevOps and Java on Azure, see the tutorials and workshops at https://aka.ms/devopsforjavashops
• Also see https://developer.microsoft.com/java for everything Java on Azure!

Thanks for stopping by!

Welcome to Day 24 of #30DaysOfServerless!

We continue exploring E2E scenarios with this tutorial where you'll deploy a containerized ASP.NET Core 6.0 application to Azure Container Apps.

The application consists of a front-end web app built using Blazor Server, as well as two Web API projects to manage data. These projects will exist as three separate containers inside of a shared container apps environment.

What We'll Cover​

• Deploy ASP.NET Core 6.0 app to Azure Container Apps
• Automate deployment workflows using GitHub Actions
• Provision and deploy resources using Azure Bicep
• Exercise: Try this yourself!
• Resources: For self-study!

Introduction

Azure Container Apps enables you to run microservices and containerized applications on a serverless platform. With Container Apps, you enjoy the benefits of running containers while leaving behind the concerns of manually configuring cloud infrastructure and complex container orchestrators.

In this tutorial, you'll deploy a containerized ASP.NET Core 6.0 application to Azure Container Apps. The application consists of a front-end web app built using Blazor Server, as well as two Web API projects to manage data. These projects will exist as three separate containers inside of a shared container apps environment.

You will use GitHub Actions in combination with Bicep to deploy the application. These tools provide an approachable and sustainable solution for building CI/CD pipelines and working with Container Apps.

Architecture​

In this tutorial, we'll setup a container app environment with a separate container for each project in the sample store app. The major components of the sample project include:

• A Blazor Server front-end web app to display product information
• A products API to list available products
• An inventory API to determine how many products are in stock
• GitHub Actions and Bicep templates to provision Azure resources and then build and deploy the sample app.

You will explore these templates later in the tutorial.

Public internet traffic should be proxied to the Blazor app. The back-end APIs should only be reachable via requests from the Blazor app inside the container apps environment. This setup can be achieved using container apps environment ingress configurations during deployment.

Project Sources​

Want to follow along? Fork the sample below. The tutorial can be completed with or without Dapr integration. Pick the path you feel comfortable in. Dapr provides various benefits that make working with Microservices easier - you can learn more in the docs. For this tutorial you will need GitHub and Azure CLI.

You can run the app locally from Visual Studio:

• Right click on the Blazor Store project and select Set as Startup Project.
• Press the start button at the top of Visual Studio to run the app.
• (Once running) start each API in the background by

• right-clicking on the project node
• selecting Debug --> Start without debugging.

Once the Blazor app is running, you should see something like this:

Configuring Azure credentials​

In order to deploy the application to Azure through GitHub Actions, you first need to create a service principal. The service principal will allow the GitHub Actions process to authenticate to your Azure subscription to create resources and deploy code. You can learn more about Service Principals in the Azure CLI documentation. For this step you'll need to be logged into the Azure CLI.

1. If you have not done so already, make sure to fork the sample project to your own GitHub account or organization.

2. Once you have completed this step, create a service principal using the Azure CLI command below:

   $subscriptionId=$(az account show --query id --output tsv)
   az ad sp create-for-rbac --sdk-auth --name WebAndApiSample --role Contributor --scopes /subscriptions/$subscriptionId
   

3. Copy the JSON output of the CLI command to your clipboard

4. Under the settings tab of your forked GitHub repo, create a new secret named AzureSPN. The name is important to match the Bicep templates included in the project, which we'll review later. Paste the copied service principal values on your clipboard into the secret and save your changes. This new secret will be used by the GitHub Actions workflow to authenticate to Azure.

   :::image type="content" source="./img/dotnet/github-secrets.png" alt-text="A screenshot of adding GitHub secrets.":::

Deploy using Github Actions​

You are now ready to deploy the application to Azure Container Apps using GitHub Actions. The sample application includes a GitHub Actions template that is configured to build and deploy any changes to a branch named deploy. The deploy branch does not exist in your forked repository by default, but you can easily create it through the GitHub user interface.

1. Switch to the Actions tab along the top navigation of your GitHub repository. If you have not done so already, ensure that workflows are enabled by clicking the button in the center of the page.

1. Navigate to the main Code tab of your repository and select the main dropdown. Enter deploy into the branch input box, and then select Create branch: deploy from 'main'.

1. On the new deploy branch, navigate down into the .github/workflows folder. You should see a file called deploy.yml, which contains the main GitHub Actions workflow script. Click on the file to view its content. You'll learn more about this file later in the tutorial.

2. Click the pencil icon in the upper right to edit the document.

3. Change the RESOURCE_GROUP_NAME: value to msdocswebappapis or another valid resource group name of your choosing.

4. In the upper right of the screen, select Start commit and then Commit changes to commit your edit. This will persist the change to the file and trigger the GitHub Actions workflow to build and deploy the app.

1. Switch to the Actions tab along the top navigation again. You should see the workflow running to create the necessary resources and deploy the app. The workflow may take several minutes to run. When it completes successfully, all of the jobs should have a green checkmark icon next to them.

Explore the Azure resources​

Once the GitHub Actions workflow has completed successfully you can browse the created resources in the Azure portal.

1. On the left navigation, select Resource Groups. Next,choose the msdocswebappapis resource group that was created by the GitHub Actions workflow.

2. You should see seven resources available that match the screenshot and table descriptions below.

3. You can view your running app in the browser by clicking on the store container app. On the overview page, click the Application Url link on the upper right of the screen.

   :::image type="content" source="./img/dotnet/application-url.png" alt-text="The link to browse the app.":::

Understanding the GitHub Actions workflow​

The GitHub Actions workflow created and deployed resources to Azure using the deploy.yml file in the .github folder at the root of the project. The primary purpose of this file is to respond to events - such as commits to a branch - and run jobs to accomplish tasks. The deploy.yml file in the sample project has three main jobs:

• Provision: Create the necessary resources in Azure, such as the container apps environment. This step leverages Bicep templates to create the Azure resources, which you'll explore in a moment.
• Build: Create the container images for the three apps in the project and store them in the container registry.
• Deploy: Deploy the container images to the different container apps created during the provisioning job.

The deploy.yml file also accepts parameters to make the workflow more dynamic, such as setting the resource group name or the Azure region resources will be provisioned to.

Below is a commented version of the deploy.yml file that highlights the essential steps.

name: Build and deploy .NET application to Container Apps

# Trigger the workflow on pushes to the deploy branch
on:
  push:
    branches:
    - deploy

env:
  # Set workflow variables
  RESOURCE_GROUP_NAME: msdocswebappapis

  REGION: eastus

  STORE_DOCKER: Store/Dockerfile
  STORE_IMAGE: store

  INVENTORY_DOCKER: Store.InventoryApi/Dockerfile
  INVENTORY_IMAGE: inventory

  PRODUCTS_DOCKER: Store.ProductApi/Dockerfile
  PRODUCTS_IMAGE: products

jobs:
  # Create the required Azure resources
  provision:
    runs-on: ubuntu-latest

    steps:

    - name: Checkout to the branch
      uses: actions/checkout@v2

    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AzureSPN }}

    - name: Create resource group
      uses: azure/CLI@v1
      with:
        inlineScript: >
          echo "Creating resource group in Azure"
          echo "Executing 'az group create -l ${{ env.REGION }} -n ${{ env.RESOURCE_GROUP_NAME }}'"
          az group create -l ${{ env.REGION }} -n ${{ env.RESOURCE_GROUP_NAME }}

    # Use Bicep templates to create the resources in Azure
    - name: Creating resources
      uses: azure/CLI@v1
      with:
        inlineScript: >
          echo "Creating resources"
          az deployment group create --resource-group ${{ env.RESOURCE_GROUP_NAME }} --template-file '/github/workspace/Azure/main.bicep' --debug

  # Build the three app container images
  build:
    runs-on: ubuntu-latest
    needs: provision
    
    steps:

    - name: Checkout to the branch
      uses: actions/checkout@v2

    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AzureSPN }}

    - name: Set up Docker Buildx
      uses: docker/setup-buildx-action@v1

    - name: Login to ACR
      run: |
        set -euo pipefail
        access_token=$(az account get-access-token --query accessToken -o tsv)
        refresh_token=$(curl https://${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/oauth2/exchange -v -d "grant_type=access_token&service=${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io&access_token=$access_token" | jq -r .refresh_token)
        docker login -u 00000000-0000-0000-0000-000000000000 --password-stdin ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io <<< "$refresh_token"

    - name: Build the products api image and push it to ACR
      uses: docker/build-push-action@v2
      with:
        push: true
        tags: ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.PRODUCTS_IMAGE }}:${{ github.sha }}
        file: ${{ env.PRODUCTS_DOCKER }}

    - name: Build the inventory api image and push it to ACR
      uses: docker/build-push-action@v2
      with:
        push: true
        tags: ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.INVENTORY_IMAGE }}:${{ github.sha }}
        file: ${{ env.INVENTORY_DOCKER }}

    - name: Build the frontend image and push it to ACR
      uses: docker/build-push-action@v2
      with:
        push: true
        tags: ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.STORE_IMAGE }}:${{ github.sha }}
        file: ${{ env.STORE_DOCKER }}

  # Deploy the three container images
  deploy:
    runs-on: ubuntu-latest
    needs: build

    steps:

    - name: Checkout to the branch
      uses: actions/checkout@v2

    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AzureSPN }}

    - name: Installing Container Apps extension
      uses: azure/CLI@v1
      with:
        inlineScript: >
          az config set extension.use_dynamic_install=yes_without_prompt

          az extension add --name containerapp --yes

    - name: Login to ACR
      run: |
        set -euo pipefail
        access_token=$(az account get-access-token --query accessToken -o tsv)
        refresh_token=$(curl https://${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/oauth2/exchange -v -d "grant_type=access_token&service=${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io&access_token=$access_token" | jq -r .refresh_token)
        docker login -u 00000000-0000-0000-0000-000000000000 --password-stdin ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io <<< "$refresh_token"

    - name: Deploy Container Apps
      uses: azure/CLI@v1
      with:
        inlineScript: >
          az containerapp registry set -n products -g ${{ env.RESOURCE_GROUP_NAME }} --server ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io

          az containerapp update -n products -g ${{ env.RESOURCE_GROUP_NAME }} -i ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.PRODUCTS_IMAGE }}:${{ github.sha }}

          az containerapp registry set -n inventory -g ${{ env.RESOURCE_GROUP_NAME }} --server ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io

          az containerapp update -n inventory -g ${{ env.RESOURCE_GROUP_NAME }} -i ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.INVENTORY_IMAGE }}:${{ github.sha }}

          az containerapp registry set -n store -g ${{ env.RESOURCE_GROUP_NAME }} --server ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io
          
          az containerapp update -n store -g ${{ env.RESOURCE_GROUP_NAME }} -i ${{ env.RESOURCE_GROUP_NAME }}acr.azurecr.io/${{ env.STORE_IMAGE }}:${{ github.sha }}

    - name: logout
      run: >
        az logout

Understanding the Bicep templates​

During the provisioning stage of the GitHub Actions workflow, the main.bicep file is processed. Bicep files provide a declarative way of generating resources in Azure and are ideal for managing infrastructure as code. You can learn more about Bicep in the related documentation. The main.bicep file in the sample project creates the following resources:

• The container registry to store images of the containerized apps.
• The container apps environment, which handles networking and resource management for the container apps.
• Three container apps - one for the Blazor front-end and two for the back-end product and inventory APIs.
• Configuration values to connect these services together

main.bicep without Dapr​

param location string = resourceGroup().location

# create the azure container registry
resource acr 'Microsoft.ContainerRegistry/registries@2021-09-01' = {
  name: toLower('${resourceGroup().name}acr')
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

# create the aca environment
module env 'environment.bicep' = {
  name: 'containerAppEnvironment'
  params: {
    location: location
  }
}

# create the various configuration pairs
var shared_config = [
  {
    name: 'ASPNETCORE_ENVIRONMENT'
    value: 'Development'
  }
  {
    name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
    value: env.outputs.appInsightsInstrumentationKey
  }
  {
    name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
    value: env.outputs.appInsightsConnectionString
  }
]

# create the products api container app
module products 'container_app.bicep' = {
  name: 'products'
  params: {
    name: 'products'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: shared_config
    externalIngress: false
  }
}

# create the inventory api container app
module inventory 'container_app.bicep' = {
  name: 'inventory'
  params: {
    name: 'inventory'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: shared_config
    externalIngress: false
  }
}

# create the store api container app
var frontend_config = [
  {
    name: 'ProductsApi'
    value: 'http://${products.outputs.fqdn}'
  }
  {
    name: 'InventoryApi'
    value: 'http://${inventory.outputs.fqdn}'
  }
]

module store 'container_app.bicep' = {
  name: 'store'
  params: {
    name: 'store'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: union(shared_config, frontend_config)
    externalIngress: true
  }
}

main.bicep with Dapr​

param location string = resourceGroup().location

# create the azure container registry
resource acr 'Microsoft.ContainerRegistry/registries@2021-09-01' = {
  name: toLower('${resourceGroup().name}acr')
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

# create the aca environment
module env 'environment.bicep' = {
  name: 'containerAppEnvironment'
  params: {
    location: location
  }
}

# create the various config pairs
var shared_config = [
  {
    name: 'ASPNETCORE_ENVIRONMENT'
    value: 'Development'
  }
  {
    name: 'APPINSIGHTS_INSTRUMENTATIONKEY'
    value: env.outputs.appInsightsInstrumentationKey
  }
  {
    name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
    value: env.outputs.appInsightsConnectionString
  }
]

# create the products api container app
module products 'container_app.bicep' = {
  name: 'products'
  params: {
    name: 'products'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: shared_config
    externalIngress: false
  }
}

# create the inventory api container app
module inventory 'container_app.bicep' = {
  name: 'inventory'
  params: {
    name: 'inventory'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: shared_config
    externalIngress: false
  }
}

# create the store api container app
module store 'container_app.bicep' = {
  name: 'store'
  params: {
    name: 'store'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: shared_config
    externalIngress: true
  }
}

Bicep Modules​

The main.bicep file references modules to create resources, such as module products. Modules are a feature of Bicep templates that enable you to abstract resource declarations into their own files or sub-templates. As the main.bicep file is processed, the defined modules are also evaluated. Modules allow you to create resources in a more organized and reusable way. They can also define input and output parameters that are passed to and from the parent template, such as the name of a resource.

For example, the environment.bicep module extracts the details of creating a container apps environment into a reusable template. The module defines necessary resource dependencies such as Log Analytics Workspaces and an Application Insights instance.

environment.bicep without Dapr​

param baseName string = resourceGroup().name
param location string = resourceGroup().location

resource logs 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: '${baseName}logs'
  location: location
  properties: any({
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  })
}

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: '${baseName}ai'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logs.id
  }
}

resource env 'Microsoft.App/managedEnvironments@2022-01-01-preview' = {
  name: '${baseName}env'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logs.properties.customerId
        sharedKey: logs.listKeys().primarySharedKey
      }
    }
  }
}

output id string = env.id
output appInsightsInstrumentationKey string = appInsights.properties.InstrumentationKey
output appInsightsConnectionString string = appInsights.properties.ConnectionString

environment.bicep with Dapr​

param baseName string = resourceGroup().name
param location string = resourceGroup().location

resource logs 'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: '${baseName}logs'
  location: location
  properties: any({
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  })
}

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: '${baseName}ai'
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId: logs.id
  }
}

resource env 'Microsoft.App/managedEnvironments@2022-01-01-preview' = {
  name: '${baseName}env'
  location: location
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logs.properties.customerId
        sharedKey: logs.listKeys().primarySharedKey
      }
    }
  }
}

output id string = env.id
output appInsightsInstrumentationKey string = appInsights.properties.InstrumentationKey
output appInsightsConnectionString string = appInsights.properties.ConnectionString

The container_apps.bicep template defines numerous parameters to provide a reusable template for creating container apps. This allows the module to be used in other CI/CD pipelines as well.

container_app.bicep without Dapr​

param name string
param location string = resourceGroup().location
param containerAppEnvironmentId string
param repositoryImage string = 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
param envVars array = []
param registry string
param minReplicas int = 1
param maxReplicas int = 1
param port int = 80
param externalIngress bool = false
param allowInsecure bool = true
param transport string = 'http'
param registryUsername string
@secure()
param registryPassword string

resource containerApp 'Microsoft.App/containerApps@2022-01-01-preview' ={
  name: name
  location: location
  properties:{
    managedEnvironmentId: containerAppEnvironmentId
    configuration: {
      activeRevisionsMode: 'single'
      secrets: [
        {
          name: 'container-registry-password'
          value: registryPassword
        }
      ]      
      registries: [
        {
          server: registry
          username: registryUsername
          passwordSecretRef: 'container-registry-password'
        }
      ]
      ingress: {
        external: externalIngress
        targetPort: port
        transport: transport
        allowInsecure: allowInsecure
      }
    }
    template: {
      containers: [
        {
          image: repositoryImage
          name: name
          env: envVars
        }
      ]
      scale: {
        minReplicas: minReplicas
        maxReplicas: maxReplicas
      }
    }
  }
}

output fqdn string = containerApp.properties.configuration.ingress.fqdn

container_app.bicep with Dapr​

param name string
param location string = resourceGroup().location
param containerAppEnvironmentId string
param repositoryImage string = 'mcr.microsoft.com/azuredocs/containerapps-helloworld:latest'
param envVars array = []
param registry string
param minReplicas int = 1
param maxReplicas int = 1
param port int = 80
param externalIngress bool = false
param allowInsecure bool = true
param transport string = 'http'
param appProtocol string = 'http'
param registryUsername string
@secure()
param registryPassword string

resource containerApp 'Microsoft.App/containerApps@2022-01-01-preview' ={
  name: name
  location: location
  properties:{
    managedEnvironmentId: containerAppEnvironmentId
    configuration: {
      dapr: {
        enabled: true
        appId: name
        appPort: port
        appProtocol: appProtocol
      }
      activeRevisionsMode: 'single'
      secrets: [
        {
          name: 'container-registry-password'
          value: registryPassword
        }
      ]      
      registries: [
        {
          server: registry
          username: registryUsername
          passwordSecretRef: 'container-registry-password'
        }
      ]
      ingress: {
        external: externalIngress
        targetPort: port
        transport: transport
        allowInsecure: allowInsecure
      }
    }
    template: {
      containers: [
        {
          image: repositoryImage
          name: name
          env: envVars
        }
      ]
      scale: {
        minReplicas: minReplicas
        maxReplicas: maxReplicas
      }
    }
  }
}

output fqdn string = containerApp.properties.configuration.ingress.fqdn

Understanding configuration differences with Dapr​

The code for this specific sample application is largely the same whether or not Dapr is integrated. However, even with this simple app, there are a few benefits and configuration differences when using Dapr that are worth exploring.

In this scenario most of the changes are related to communication between the container apps. However, you can explore the full range of Dapr benefits by reading the Dapr integration with Azure Container Apps article in the conceptual documentation.

Without Dapr​

Without Dapr the main.bicep template handles wiring up the front-end store app to communicate with the back-end apis by manually managing environment variables. The bicep template retrieves the fully qualified domains (fqdn) of the API apps as output parameters when they are created. Those configurations are then set as environment variables on the store container app.

# Retrieve environment variables from API container creation 
var frontend_config = [
  {
    name: 'ProductsApi'
    value: 'http://${products.outputs.fqdn}'
  }
  {
    name: 'InventoryApi'
    value: 'http://${inventory.outputs.fqdn}'
  }
]

# create the store api container app, passing in config
module store 'container_app.bicep' = {
  name: 'store'
  params: {
    name: 'store'
    location: location
    registryPassword: acr.listCredentials().passwords[0].value
    registryUsername: acr.listCredentials().username
    containerAppEnvironmentId: env.outputs.id
    registry: acr.name
    envVars: union(shared_config, frontend_config)
    externalIngress: true
  }
}

The environment variables are then retrieved inside of the program class and used to configure the base URLs of the corresponding HTTP clients.

builder.Services.AddHttpClient("Products", (httpClient) => httpClient.BaseAddress = new Uri(builder.Configuration.GetValue<string>("ProductsApi")));
builder.Services.AddHttpClient("Inventory", (httpClient) => httpClient.BaseAddress = new Uri(builder.Configuration.GetValue<string>("InventoryApi")));

With Dapr​

Dapr can be enabled on a container app when it is created, as seen below. This configuration adds a Dapr sidecar to the app to streamline discovery and communication features between the different container apps in your environment.

# Create the container app with Dapr enabled
resource containerApp 'Microsoft.App/containerApps@2022-01-01-preview' ={
  name: name
  location: location
  properties:{
    managedEnvironmentId: containerAppEnvironmentId
    configuration: {
      dapr: {
        enabled: true
        appId: name
        appPort: port
        appProtocol: appProtocol
      }
      activeRevisionsMode: 'single'
      secrets: [
        {
          name: 'container-registry-password'
          value: registryPassword
        }
      ]      
      
    # Rest of template omitted for brevity...
  }
}

Some of these Dapr features can be surfaced through the program file. You can configure your HttpClient to leverage Dapr configurations when communicating with other apps in your environment.

// reconfigure code to make requests to Dapr sidecar
var baseURL = (Environment.GetEnvironmentVariable("BASE_URL") ?? "http://localhost") + ":" + (Environment.GetEnvironmentVariable("DAPR_HTTP_PORT") ?? "3500");
builder.Services.AddHttpClient("Products", (httpClient) =>
{
    httpClient.BaseAddress = new Uri(baseURL);
    httpClient.DefaultRequestHeaders.Add("dapr-app-id", "Products");
});

builder.Services.AddHttpClient("Inventory", (httpClient) =>
{
    httpClient.BaseAddress = new Uri(baseURL);
    httpClient.DefaultRequestHeaders.Add("dapr-app-id", "Inventory");
});

Clean up resources​

If you're not going to continue to use this application, you can delete the Azure Container Apps and all the associated services by removing the resource group.

Follow these steps in the Azure portal to remove the resources you created:

1. In the Azure portal, navigate to the msdocswebappsapi resource group using the left navigation or search bar.
2. Select the Delete resource group button at the top of the resource group Overview.
3. Enter the resource group name msdocswebappsapi in the Are you sure you want to delete "msdocswebappsapi" confirmation dialog.
4. Select Delete.
   The process to delete the resource group may take a few minutes to complete.

Welcome to Day 21 of #30DaysOfServerless!

We've so far walked through what Azure Event Grid is and how it generally works. Today, let's discuss how Azure Event Grid deals with CloudEvents.

What We'll Cover​

• What We'll Cover
• What is CloudEvents?
• How Azure Event Grid brokers CloudEvents
  • Azure Event Grid for Azure
  • Azure Event Grid for Systems outside Azure
• How Azure Logic Apps consumes CloudEvents
• Exercise: Try this yourself!
• Resources: For self-study!

OK. Let's get started!

What is CloudEvents?​

Needless to say, events are everywhere. Events come not only from event-driven systems but also from many different systems and devices, including IoT ones like Raspberry PI.

But the problem is that every event publisher (system/device that creates events) describes their events differently, meaning there is no standard way of describing events. It has caused many issues between systems, mainly from the interoperability perspective.

1. Consistency: No standard way of describing events resulted in developers having to write their own event handling logic for each event source.
2. Accessibility: There were no common libraries, tooling and infrastructure to deliver events across systems.
3. Productivity: The overall productivity decreases because of the lack of the standard format of events.

Therefore, CNCF (Cloud-Native Computing Foundation) has brought up the concept, called CloudEvents. CloudEvents is a specification that commonly describes event data. Conforming any event data to this spec will simplify the event declaration and delivery across systems and platforms and more, resulting in a huge productivity increase.

How Azure Event Grid brokers CloudEvents​

Before CloudEvents, Azure Event Grid described events in their own way. Therefore, if you want to use Azure Event Grid, you should follow the event format/schema that Azure Event Grid declares. However, not every system/service/application follows the Azure Event Grid schema. Therefore, Azure Event Grid now supports CloudEvents spec as input and output formats.

Azure Event Grid for Azure​

Take a look at the simple diagram below, which describes how Azure Event Grid captures events raised from various Azure services. In this diagram, Azure Key Vault takes the role of the event source or event publisher, and Azure Logic Apps takes the role of the event handler (I'll discuss Azure Logic Apps as the event handler later in this post). We use Azure Event Grid System Topic for Azure.

Therefore, let's create an Azure Event Grid System Topic that captures events raised from Azure Key Vault when a new version of a secret is added.

As Azure Event Grid makes use of the pub/sub pattern, you need to create the Azure Event Grid Subscription to consume the events. Here's the subscription that uses the Event Grid data format:

![Azure Event Grid System Subscription for Key Vault in Event Grid Format][./img/21-cloudevents-via-event-grid-03.png]

Once you create the subscription, create a new version of the secret on Azure Key Vault. Then, Azure Key Vault raises an event, which is captured in the Event Grid format:

[
  {
    "id": "6f44b9c0-d37e-40e7-89be-f70a6da291cc",
    "topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-aegce-krc/providers/Microsoft.KeyVault/vaults/kv-xxxxxxxx",
    "subject": "hello",
    "eventType": "Microsoft.KeyVault.SecretNewVersionCreated",
    "data": {
      "Id": "https://kv-xxxxxxxx.vault.azure.net/secrets/hello/064dfc082fec463f8d4610ed6118811d",
      "VaultName": "kv-xxxxxxxx",
      "ObjectType": "Secret",
      "ObjectName": "hello",
      "Version": "064dfc082fec463f8d4610ed6118811d",
      "NBF": null,
      "EXP": null
    },
    "dataVersion": "1",
    "metadataVersion": "1",
    "eventTime": "2022-09-21T07:08:09.1234567Z"
  }
]

So, how is it different from the CloudEvents format? Let's take a look. According to the spec, the JSON data in CloudEvents might look like this:

{
  "id" : "C234-1234-1234",
  "source" : "/mycontext",
  "specversion" : "1.0",
  "type" : "com.example.someevent",
  "comexampleextension1" : "value",
  "time" : "2018-04-05T17:31:00Z",
  "datacontenttype" : "application/cloudevents+json",
  "data" : {
    "appinfoA" : "abc",
    "appinfoB" : 123,
    "appinfoC" : true
  }
}

This time, let's create another subscription using the CloudEvents schema. Here's how to create the subscription against the system topic:

Therefore, Azure Key Vault emits the event data in the CloudEvents format:

{
  "id": "6f44b9c0-d37e-40e7-89be-f70a6da291cc",
  "source": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/rg-aegce-krc/providers/Microsoft.KeyVault/vaults/kv-xxxxxxxx",
  "specversion": "1.0",
  "type": "Microsoft.KeyVault.SecretNewVersionCreated",
  "subject": "hello",
  "time": "2022-09-21T07:08:09.1234567Z",
  "data": {
    "Id": "https://kv-xxxxxxxx.vault.azure.net/secrets/hello/064dfc082fec463f8d4610ed6118811d",
    "VaultName": "kv-xxxxxxxx",
    "ObjectType": "Secret",
    "ObjectName": "hello",
    "Version": "064dfc082fec463f8d4610ed6118811d",
    "NBF": null,
    "EXP": null
  }
}

Can you identify some differences between the Event Grid format and the CloudEvents format? Fortunately, both Event Grid schema and CloudEvents schema look similar to each other. But they might be significantly different if you use a different event source outside Azure.

Azure Event Grid for Systems outside Azure​

As mentioned above, the event data described outside Azure or your own applications within Azure might not be understandable by Azure Event Grid. In this case, we need to use Azure Event Grid Custom Topic. Here's the diagram for it:

Let's create the Azure Event Grid Custom Topic. When you create the topic, make sure that you use the CloudEvent schema during the provisioning process:

If your application needs to publish events to Azure Event Grid Custom Topic, your application should build the event data in the CloudEvents format. If you use a .NET application, add the NuGet package first.

dotnet add package Azure.Messaging.EventGrid

Then, create the publisher instance. You've already got the topic endpoint URL and the access key.

var topicEndpoint = new Uri("<Azure Event Grid Custom Topic Endpoint URL>");
var credential = new AzureKeyCredential("<Azure Event Grid Custom Topic Access Key>");
var publisher = new EventGridPublisherClient(topicEndpoint, credential);

Now, build the event data like below. Make sure that you follow the CloudEvents schema that requires additional metadata like event source, event type and content type.

var source = "/your/event/source";
var type = "com.source.event.your/OnEventOccurs";

var data = new MyEventData() { Hello = "World" };

var @event = new CloudEvent(source, type, data);

And finally, send the event to Azure Event Grid Custom Topic.

await publisher.SendEventAsync(@event);

The captured event data looks like the following:

{
  "id": "cc2b2775-52b8-43b8-a7cc-c1c33c2b2e59",
  "source": "/your/event/source",
  "type": "com.source.event.my/OnEventOccurs",
  "data": {
    "Hello": "World"
  },
  "time": "2022-09-21T07:08:09.1234567+00:00",
  "specversion": "1.0"
}

However, due to limitations, someone might insist that their existing application doesn't or can't emit the event data in the CloudEvents format. In this case, what should we do? There's no standard way of sending the event data in the CloudEvents format to Azure Event Grid Custom Topic. One of the approaches we may be able to apply is to put a converter between the existing application and Azure Event Grid Custom Topic like below:

Once the Function app (or any converter app) receives legacy event data, it internally converts the CloudEvents format and publishes it to Azure Event Grid.

var data = default(MyRequestData);
using (var reader = new StreamReader(req.Body))
{
    var serialised = await reader.ReadToEndAsync();
    data = JsonConvert.DeserializeObject<MyRequestData>(serialised);
}

var converted = new MyEventData() { Hello = data.Lorem };
var @event = new CloudEvent(source, type, converted);

The converted event data is captured like this:

{
  "id": "df296da3-77cd-4da2-8122-91f631941610",
  "source": "/your/event/source",
  "type": "com.source.event.my/OnEventOccurs",
  "data": {
    "Hello": "ipsum"
  },
  "time": "2022-09-21T07:08:09.1234567+00:00",
  "specversion": "1.0"
}

This approach is beneficial in many integration scenarios to make all the event data canonicalised.

How Azure Logic Apps consumes CloudEvents​

I put Azure Logic Apps as the event handler in the previous diagrams. According to the CloudEvents spec, each event handler must implement request validation to avoid abuse. One good thing about using Azure Logic Apps is that it has already implemented this request validation feature. It implies that we just subscribe to the topic and consume the event data.

Create a new Logic Apps instance and add the HTTP Request trigger. Once it saves, you will get the endpoint URL.

Then, create the Azure Event Grid Subscription with:

• Endpoint type: Webhook
• Endpoint URL: The Logic Apps URL from above.

Once the subscription is ready, this Logic Apps works well as the event handler. Here's how it receives the CloudEvents data from the subscription.

Now you've got the CloudEvents data. It's entirely up to you to handle that event data however you want!

Exercise: Try this yourself!​

You can fork this GitHub repository to your account and play around with it to see how Azure Event Grid with CloudEvents works. Alternatively, the "Deploy to Azure" button below will provision all necessary Azure resources and deploy an Azure Functions app to mimic the event publisher.

Resources: For self-study!​

Want to know more about CloudEvents in real-life examples? Here are several resources you can take a look at:

• Azure CLI for EventGrid Subscription to Custom Topic
• CloudEvents for Azure EventGrid via Azure Functions
• WebSub to EventGrid via CloudEvents, and Beyond
• Event-Driven KeyVault Secrets Rotation Management

Welcome to Day 20 of #30DaysOfServerless!

Every day millions of people spend their precious time in productivity tools. What if you use data and intelligence behind the Microsoft applications (Microsoft Teams, Outlook, and many other Office apps) to build seamless automations and custom apps to boost productivity?

In this post, we'll learn how to build a seamless onboarding experience for new employees joining a company with the power of Microsoft Graph, integrated with Event Hubs and Logic Apps!

What We'll Cover​

• ✨ The power of Microsoft Graph
• 🖇️ How do Microsoft Graph and Event Hubs work together?
• 🛠 Let's Build an Onboarding Workflow!
  • 1️⃣ Setup Azure Event Hubs + Key Vault
  • 2️⃣ Subscribe to users, receive change notifications from Logic Apps
  • 3️⃣ Create Onboarding workflow in the Logic Apps
• 🚀 Debug: Your onboarding experience
• ✋ Exercise: Try this tutorial out yourself!
• 📚 Resources: For Self-Study

✨ The Power of Microsoft Graph​

Microsoft Graph is the gateway to data and intelligence in Microsoft 365 platform. Microsoft Graph exploses Rest APIs and client libraries to access data across Microsoft 365 core services such as Calendar, Teams, To Do, Outlook, People, Planner, OneDrive, OneNote and more.

You can build custom experiences by using Microsoft Graph such as automating the onboarding process for new employees. When new employees are created in the Azure Active Directory, they will be automatically added in the Onboarding team on Microsoft Teams.

🖇️ Microsoft Graph with Event Hubs​

Microsoft Graph uses a webhook mechanism to track changes in resources and deliver change notifications to the clients. For example, with Microsoft Graph Change Notifications, you can receive change notifications when:

• a new task is added in the to-do list
• a user changes the presence status from busy to available
• an event is deleted/cancelled from the calendar

If you'd like to track a large set of resources at a high frequency, use Azure Events Hubs instead of traditional webhooks to receive change notifications. Azure Event Hubs is a popular real-time events ingestion and distribution service built for scale.

Setup Azure Event Hubs + Key Vault.​

To get Microsoft Graph Change Notifications delivered to Azure Event Hubs, we'll have to setup Azure Event Hubs and Azure Key Vault. We'll use Azure Key Vault to access to Event Hubs connection string.

1️⃣ Create Azure Event Hubs​

1. Go to Azure Portal and select Create a resource, type Event Hubs and select click Create.
2. Fill in the Event Hubs namespace creation details, and then click Create.
3. Go to the newly created Event Hubs namespace page, select Event Hubs tab from the left pane and + Event Hub:
   • Name your Event Hub as Event Hub
   • Click Create.
4. Click the name of the Event Hub, and then select Shared access policies and + Add to add a new policy:
   • Give a name to the policy
   • Check Send and Listen
   • Click Create.
5. After the policy has been created, click the name of the policy to open the details panel, and then copy the Connection string-primary key value. Write it down; you'll need it for the next step.
6. Go to Consumer groups tab in the left pane and select + Consumer group, give a name for your consumer group as onboarding and select Create.

2️⃣ Create Azure Key Vault​

1. Go to Azure Portal and select Create a resource, type Key Vault and select Create.
2. Fill in the Key Vault creation details, and then click Review + Create.
3. Go to newly created Key Vault and select Secrets tab from the left pane and click + Generate/Import:
   • Give a name to the secret
   • For the value, paste in the connection string you generated at the Event Hubs step
   • Click Create
   • Copy the name of the secret.
4. Select Access Policies from the left pane and + Add Access Policy:
   • For Secret permissions, select Get
   • For Principal, select Microsoft Graph Change Tracking
   • Click Add.
5. Select Overview tab from the left pane and copy the Vault URI.

Subscribe for Logic Apps change notifications​

To start receiving Microsoft Graph Change Notifications, we'll need to create subscription to the resource that we'd like to track - here, 'users'. We'll use Azure Logic Apps to create subscription.

To create subscription for Microsoft Graph Change Notifications, we'll need to make a http post request to https://graph.microsoft.com/v1.0/subscriptions. Microsoft Graph requires Azure Active Directory authentication make API calls. First, we'll need to register an app to Azure Active Directory, and then we will make the Microsoft Graph Subscription API call with Azure Logic Apps.

1️⃣ Create an app in Azure Active Directory​

1. In the Azure Portal, go to Azure Active Directory and select App registrations from the left pane and select + New registration. Fill in the details for the new App registration form as below:
   • Name: Graph Subscription Flow Auth
   • Supported account types: Accounts in any organizational directory (Any Azure AD directory - Multitenant) and personal Microsoft accounts (e.g. Skype, Xbox)
   • Select Register.
2. Go to newly registered app in Azure Active Directory, select API permissions:
   • Select + Add a permission and Microsoft Graph
   • Select Application permissions and add User.Read.All and Directory.Read.All.
   • Select Grant admin consent for the organization
3. Select Certificates & secrets tab from the left pane, select + New client secret:
   • Choose desired expiry duration
   • Select Add
   • Copy the value of the secret.
4. Go to Overview from the left pane, copy Application (client) ID and Directory (tenant) ID.

2️⃣ Create subscription with Azure Logic Apps​

1. Go to Azure Portal and select Create a resource, type Logic apps and select click Create.

2. Fill in the Logic Apps creation details, and then click Create.

3. Go to the newly created Logic Apps page, select Workflows tab from the left pane and select + Add:

   • Give a name to the new workflow as graph-subscription-flow
   • Select Stateful as a state type
   • Click Create.

4. Go to graph-subscription-flow, and then select Designer tab.

5. In the Choose an operation section, search for Schedule and select Recurrence as a trigger. Fill in the parameters as below:

   • Interval: 61
   • Frequency: Minute
   • Time zone: Select your own time zone
   • Start time: Set a start time

6. Select + button in the flow and select add an action. Search for HTTP and select HTTP as an action. Fill in the parameters as below:

   • Method: POST
   • URI: https://graph.microsoft.com/v1.0/subscriptions
   • Headers:
     • Key: Content-type
     • Value: application/json
   • Body:

   {
   "changeType": "created, updated",
   "clientState": "secretClientValue",
   "expirationDateTime": "@{addHours(utcNow(), 1)}",
   "notificationUrl": "EventHub:https://<YOUR-VAULT-URI>/secrets/<YOUR-KEY-VAULT-SECRET-NAME>?tenantId=72f988bf-86f1-41af-91ab-2d7cd011db47",
   "resource": "users"
   }
   

   In notificationUrl, make sure to replace <YOUR-VAULT-URI> with the vault uri and <YOUR-KEY-VAULT-SECRET-NAME> with the secret name that you copied from the Key Vault.

   In resource, define the resource type you'd like to track changes. For our example, we will track changes for users resource.

   • Authentication:
     • Authentication type: Active Directory OAuth
     • Authority: https://login.microsoft.com
     • Tenant: Directory (tenant) ID copied from AAD app
     • Audience: https://graph.microsoft.com
     • Client ID: Application (client) ID copied from AAD app
     • Credential Type: Secret
     • Secret: value of the secret copied from AAD app

7. Select Save and run your workflow from the Overview tab.

Check your subscription in Graph Explorer: If you'd like to make sure that your subscription is created successfully by Logic Apps, you can go to Graph Explorer, login with your Microsoft 365 account and make GET request to https://graph.microsoft.com/v1.0/subscriptions. Your subscription should appear in the response after it's created successfully.

After subscription is created successfully by Logic Apps, Azure Event Hubs will receive notifications whenever there is a new user created in Azure Active Directory.

Create Onboarding workflow in Logic Apps​

We'll create a second workflow in the Logic Apps to receive change notifications from Event Hubs when there is a new user created in the Azure Active Directory and add new user in Onboarding team on Microsoft Teams.

1. Go to the Logic Apps you created in the previous steps, select Workflows tab and create a new workflow by selecting + Add:
   • Give a name to the new workflow as teams-onboarding-flow
   • Select Stateful as a state type
   • Click Create.
2. Go to teams-onboarding-flow, and then select Designer tab.
3. In the Choose an operation section, search for Event Hub, select When events are available in Event Hub as a trigger. Setup Event Hub connection as below:
   • Create Connection:
     • Connection name: Connection
     • Authentication Type: Connection String
     • Connection String: Go to Event Hubs > Shared Access Policies > RootManageSharedAccessKey and copy Connection string–primary key
     • Select Create.
   • Parameters:
     • Event Hub Name: Event Hub
     • Consumer Group Name: onboarding
4. Select + in the flow and add an action, search for Control and add For each as an action. Fill in For each action as below:
   • Select output from previous steps: Events
5. Inside For each, select + in the flow and add an action, search for Data operations and select Parse JSON. Fill in Parse JSON action as below:
   • Content: Events Content
   • Schema: Copy the json content from schema-parse.json and paste as a schema
6. Select + in the flow and add an action, search for Control and add For each as an action. Fill in For each action as below:
   • Select output from previous steps: value
7. 1. Inside For each, select + in the flow and add an action, search for Microsoft Teams and select Add a member to a team. Login with your Microsoft 365 account to create a connection and fill in Add a member to a team action as below:
   • Team: Create an Onboarding team on Microsoft Teams and select
   • A user AAD ID for the user to add to a team: id
8. Select Save.

🚀 Debug your onboarding experience​

To debug our onboarding experience, we'll need to create a new user in Azure Active Directory and see if it's added in Microsoft Teams Onboarding team automatically.

1. Go to Azure Portal and select Azure Active Directory from the left pane and go to Users. Select + New user and Create new user. Fill in the details as below:

   • User name: JaneDoe
   • Name: Jane Doe

   

2. When you added Jane Doe as a new user, it should trigger the teams-onboarding-flow to run.

3. Once the teams-onboarding-flow runs successfully, you should be able to see Jane Doe as a member of the Onboarding team on Microsoft Teams! 🥳

📚 Resources​

• Microsoft Graph Fundamentals
• Get change notifications delivered in different ways
• Real-time presence with Microsoft 365, Azure, and Power Platform
• Partner Events overview for customers - Azure Event Grid

Welcome to Day 19 of #30DaysOfServerless!

Today, we have a special set of posts from our Zero To Hero 🚀 initiative, featuring blog posts authored by our Product Engineering teams for #ServerlessSeptember. Posts were originally published on the Apps on Azure blog on Microsoft Tech Community.

What We'll Cover​

• Retry Policy Support - in Apache Kafka Extension
• AutoOffsetReset property - in Apache Kafka Extension
• Key support for Kafka messages - in Apache Kafka Extension
• References: Apache Kafka Extension for Azure Functions

Recently we launched the Apache Kafka extension for Azure functions in GA with some cool new features like deserialization of Avro Generic records and Kafka headers support. We received great responses - so we're back with more updates!

Retry Policy support​

Handling errors in Azure Functions is important to avoid data loss or miss events or monitor the health of an application. Apache Kafka Extension for Azure Functions supports retry policy which tells the runtime to rerun a failed execution until either successful completion occurs or the maximum number of retries is reached.

A retry policy is evaluated when a trigger function raises an uncaught exception. As a best practice, you should catch all exceptions in your code and rethrow any errors that you want to result in a retry.

There are two retry strategies supported by policy that you can configure :- fixed delay and exponential backoff

1. Fixed Delay - A specified amount of time is allowed to elapse between each retry.
2. Exponential Backoff - The first retry waits for the minimum delay. On subsequent retries, time is added exponentially to the initial duration for each retry, until the maximum delay is reached. Exponential back-off adds some small randomization to delays to stagger retries in high-throughput scenarios.

Here is the sample code view of exponential backoff retry strategy

AutoOffsetReset property​

AutoOffsetReset property enables customers to configure the behaviour in the absence of an initial offset. Imagine a scenario when there is a need to change consumer group name. The consumer connected using a new consumer group had to reprocess all events starting from the oldest (earliest) one, as this was the default one and this setting wasn’t exposed as configurable option in the Apache Kafka extension for Azure Functions(previously). With the help of this kafka setting you can configure on how to start processing events for newly created consumer groups.

Due to lack of the ability to configure this setting, offset commit errors were causing topics to restart from earliest offset· Users were looking to be able to set offset setting to either latest or earliest based on their requirements.

We are happy to share that we have enabled the AutoOffsetReset setting as a configurable one to either - Earliest(Default) and Latest. Setting the value to Earliest configures the consumption of the messages from the the earliest/smallest offset or beginning of the topic partition. Setting the property to Latest configures the consumption of the messages from the latest/largest offset or from the end of the topic partition. This is supported for all the Azure Functions supported languages (C# (in & out), Java, Node (JS and TypeScript), PowerShell and python) and can be used for both triggers and output binding

Key support for Kafka messages​

With keys the producer/output binding can be mapped to broker and partition to write based on the message. So alongside the message value, we can choose to send a message key and that key can be whatever you want it could be a string, it could be a number . In case you don’t send the key, the key is set to null then the data will be sent in a Round Robin fashion to make it very simple. But in case you send a key with your message, all the messages that share the same key will always go to the same partition and thus you can enable grouping of similar messages into partitions

Previously while consuming a Kafka event message using the Azure Function kafka extension, the event key was always none although the key was present in the event message.

Key support was implemented in the extension which enables customers to set/view key in the Kafka event messages coming in to the kafka trigger and set keys to the messages going in to kafka topics (with keys set) through output binding. Therefore key support was enabled in the extension to support both trigger and output binding for all Azure Functions supported languages ( (C# (in & out), Java, Node (JS and TypeScript), PowerShell and python)

Here is the view of an output binding producer code where Kafka messages are being set with key

Conclusion:​

In this article you have learnt about the latest additions to the Apache Kafka extension for Azure Functions. Incase you have been waiting for these features to get released or need them you are all set and please go head and try them out!! They are available in the latest extension bundles

References​

• Apache Kafka bindings for Azure Functions | Microsoft Docs

Keep in touch with us on Twitter via @AzureFunctions.

Welcome to Day 19 of #30DaysOfServerless!

Today, we have a special set of posts from our Zero To Hero 🚀 initiative, featuring blog posts authored by our Product Engineering teams for #ServerlessSeptember. Posts were originally published on the Apps on Azure blog on Microsoft Tech Community.

What We'll Cover​

• Log Streaming - in Azure Portal
• Console Connect - in Azure Portal
• Metrics - using Azure Monitor
• Log Analytics - using Azure Monitor
• Metric Alerts and Log Alerts - using Azure Monitor

In past weeks, @kendallroden wrote about what it means to be Cloud-Native and @Anthony Chu the various ways to get your apps running on Azure Container Apps. Today, we will talk about the observability tools you can use to observe, debug, and diagnose your Azure Container Apps.

Azure Container Apps provides several observability features to help you debug and diagnose your apps. There are both Azure portal and CLI options you can use to help understand the health of your apps and help identify when issues arise.

While these features are helpful throughout your container app’s lifetime, there are two that are especially helpful. Log streaming and console connect can be a huge help in the initial stages when issues often rear their ugly head. Let's dig into both of these a little.

Log Streaming​

Log streaming allows you to use the Azure portal to view the streaming logs from your app. You’ll see the logs written from the app to the container’s console (stderr and stdout). If your app is running multiple revisions, you can choose from which revision to view logs. You can also select a specific replica if your app is configured to scale. Lastly, you can choose from which container to view the log output. This is useful when you are running a custom or Dapr sidecar container.

Here’s an example CLI command to view the logs of a container app.

az containerapp logs show -n MyContainerapp -g MyResourceGroup

You can find more information about the different options in our CLI docs.

Console Connect​

In the Azure portal, you can connect to the console of a container in your app. Like log streaming, you can select the revision, replica, and container if applicable. After connecting to the console of the container, you can execute shell commands and utilities that you have installed in your container. You can view files and their contents, monitor processes, and perform other debugging tasks.

This can be great for checking configuration files or even modifying a setting or library your container is using. Of course, updating a container in this fashion is not something you should do to a production app, but tweaking and re-testing an app in a non-production environment can speed up development.

Here’s an example CLI command to connect to the console of a container app.

az containerapp exec -n MyContainerapp -g MyResourceGroup

You can find more information about the different options in our CLI docs.

Metrics​

Azure Monitor collects metric data from your container app at regular intervals to help you gain insights into the performance and health of your container app. Container apps provide these metrics:

• CPU usage
• Memory working set bytes
• Network in bytes
• Network out bytes
• Requests
• Replica count
• Replica restart count

Here you can see the metrics explorer showing the replica count for an app as it scaled from one replica to fifteen, and then back down to one.

You can also retrieve metric data through the Azure CLI.

Log Analytics​

Azure Monitor Log Analytics is great for viewing your historical logs emitted from your container apps. There are two custom tables of interest, the ContainerAppConsoleLogs_CL which contains all the log messages written by your app (stdout and stderr), and the ContainerAppSystemLogs_CL which contain the system messages from the Azure Container Apps service.

You can also query Log Analytics through the Azure CLI.

Alerts​

Azure Monitor alerts notify you so that you can respond quickly to critical issues. There are two types of alerts that you can define:

• Metric alerts based on Azure Monitor metric data
• Log alerts based on Azure Monitor Log Analytics data

You can create alert rules from metric charts in the metric explorer and from queries in Log Analytics. You can also define and manage alerts from the Monitor|Alerts page.

Here is what creating an alert looks like in the Azure portal. In this case we are setting an alert rule from the metric explorer to trigger an alert if the replica restart count for a specific container app is greater than two within the last fifteen minutes.

To learn more about alerts, refer to Overview of alerts in Microsoft Azure.

Conclusion​

In this article, we looked at the several ways to observe, debug, and diagnose your Azure Container Apps. As you can see there are rich portal tools and a complete set of CLI commands to use. All the tools are helpful throughout the lifecycle of your app, be sure to take advantage of them when having an issue and/or to prevent issues.

To learn more, visit Azure Container Apps | Microsoft Azure today!

Welcome to Day 18 of #30DaysOfServerless!

Yesterday my Serverless September post introduced you to making Azure Logic Apps and Azure Cosmos DB work together with a sample application that collects weather data. Today I'm sharing a more robust solution that actually reads my mail. Let's learn about Teaching the cloud to read your mail!

Ready? Let's go!

What We'll Cover​

• Introduction to the ReadMail solution
• Setting up Azure storage, Cosmos DB and Computer Vision
• Connecting it all together with a Logic App
• Resources: For self-study!

Introducing the ReadMail solution​

The US Postal system offers a subscription service that sends you images of mail it will be delivering to your home. I decided it would be cool to try getting Azure to collect data based on these images, so that I could categorize my mail and track the types of mail that I received.

To do this, I used Azure storage, Cosmos DB, Logic Apps, and computer vision. When a new email comes in from the US Postal service (USPS), it triggers a logic app that:

• Posts attachments to Azure storage
• Triggers Azure Computer vision to perform an OCR function on attachments
• Extracts any results into a JSON document
• Writes the JSON document to Cosmos DB

In this post I'll walk you through setting up the solution for yourself.

Setup Azure Services​

First, we'll create all of the target environments we need to be used by our Logic App, then we;ll create the Logic App.

1. Azure Storage​

We'll be using Azure storage to collect attached images from emails as they arrive. Adding images to Azure storage will also trigger a workflow that performs OCR on new attached images and stores the OCR data in Cosmos DB.

To create a new Azure storage account from the portal dashboard, Select Create a resource > Storage account > Create.

The Basics tab covers all of the features and information that we will need for this solution:

Select Review + create to accept the remaining default options, then validate and create the account.

2. Azure CosmosDB​

CosmosDB will be used to store the JSON documents returned by the COmputer Vision OCR process.

See more details and screen shots for setting up CosmosDB in yesterday's Serverless September post - Using Logic Apps with Cosmos DB

To get started with Cosmos DB, you create an account, then a database, then a container to store JSON documents. To create a new Cosmos DB account from the portal dashboard, Select Create a resource > Azure Cosmos DB > Create. Choose core SQL for the API.

Select your subscription, then for simplicity use the same resource group you created when you set up storage. Enter an account name and choose a location, select provisioned throughput capacity mode and apply the free tier discount. From here you can select Review and Create, then Create

Next, create a new database and container. Go to the Data Explorer in your new Cosmos DB account, and choose New Container. Name the database, and keep all the other defaults except:

Press OK to create a database and container

3. Azure Computer Vision​

Azure Cognitive Services' Computer Vision will perform an OCR process on each image attachment that is stored in Azure storage.

From the portal dashboard, Select Create a resource > AI + Machine Learning > Computer Vision > Create.

The Basics and Identity tabs cover all of the features and information that we will need for this solution:

Basics Tab

Identity Tab

Select Review + create to accept the remaining default options, then validate and create the account.

Connect it all with a Logic App​

Now we're ready to put this all together in a Logic App workflow!

From the portal dashboard, Select Create a resource > Integration > Logic App > Create. Name your Logic App and select a location, the rest of the settings can be left at their defaults.

Once the Logic App is created, select Create a workflow from designer.

A workflow is a series of steps that defines a task or process. Each workflow starts with a single trigger, after which you must add one or more actions.

When in designer, search for outlook.com on the right under Add a trigger. Choose outlook.com. Choose When a new email arrives as the trigger.

A trigger is always the first step in any workflow and specifies the condition for running any further steps in that workflow.

Set the following values:

Then add a new parameter:

Choose add an action and choose control > for-each.

Inside the for-each action, in Select an output from previous steps, choose attachments. Then, again inside the for-each action, add the create blob action:

Set the following values:

This extracts attachments from the email and created a new blob for each attachment.

Next, inside the same for-each action, add the get blob content action.

Set the following values:

We create and read from a blob for each attachment because Computer Vision needs a non-virtual source to read from when performing an OCR process. Because we enabled system assigned identity to grant Computer Vision to other existing resources, it can access the blob but not the outlook.com attachment. Also, we pass the ID of the blob to use as a unique ID when writing to Cosmos DB.

Next, inside the same for-each action, choose add an action and choose control > condition. Set the value to Media Type > is equal to > image/JPEG

The USPS sends attachments of multiple types, but we only want to scan attachments that have images of our mail, which are always JPEG images. If the condition is true, we will process the image with Computer Vision OCR and write the results to a JSON document in CosmosDB.

In the True section of the condition, add an action and choose Computer Vision API > Optical Character Recognition (OCR) to JSON.

Set the following values:

In the same True section of the condition, choose add an action and choose Cosmos DB. Choose Create or Update Document from the actions. Select Access Key, and provide the primary read-write key (found under keys in Cosmos DB), and the Cosmos DB account ID (without 'documents.azure.com').

Next, fill in your Cosmos DB Database ID and Collection ID. Create a JSON document by selecting dynamic content elements and wrapping JSON formatting around them.

Be sure to use the ID passed from blob storage as your unique ID for CosmosDB. That way you can troubleshoot and JSON or OCR issues by tracing back the JSON document in Cosmos Db to the blob in Azure storage. Also, include the Computer Vision JSON response, as it contains the results of the Computer Vision OCR scan. all other elements are optional.

When complete, you should have an action the Logic App designer that looks something like this:

Save the workflow and test the connections by clicking Run Trigger > Run. If connections are working, you should see documents flowing into Cosmos DB each time that an email arrives with image attachments.

Check the data in Cosmos Db by opening the Data explorer, then choosing the container you created and selecting items. You should see documents similar to this:

Resources: For self-study!​

Once you have an understanding of the basics in ths post, there is so much more to learn!

• Check out the other Serverless September posts.
• For more detail about Cosmos DB, see the docs at https://learn.microsoft.com/azure/cosmos-db/
• For more info on Logic Apps, see the docs at https://learn.microsoft.com/azure/logic-apps/
• For details on Azure Cognitive Services and Computer Vision, see https://azure.microsoft.com/products/cognitive-services/computer-vision/.

Thanks for stopping by!

Welcome to Day 17 of #30DaysOfServerless!

In past weeks, we've covered serverless technologies that provide core capabilities (functions, containers, microservices) for building serverless solutions. This week we're looking at technologies that make service integrations more seamless, starting with Logic Apps. Let's look at one usage example today!

Ready? Let's Go!

What We'll Cover​

• Introduction to Logic Apps
• Settng up Cosmos DB for Logic Apps
• Setting up a Logic App connection and event
• Writing data to Cosmos DB from a Logic app
• Resources: For self-study!

Introduction to Logic Apps​

Previously in Serverless September, we've covered Azure Functions, where the event triggers code. In Logic Apps, the event triggers a workflow that you design. Logic Apps enable serverless applications to connect to external sources for data then automate business processes via workflows.

In this post I'll walk you through setting up a Logic App that works with Cosmos DB. For this example, we'll connect to the MSN weather service, an design a logic app workflow that collects data when weather changes, and writes the data to Cosmos DB.

Setup Cosmos DB for Logic Apps​

Cosmos DB has many APIs to choose from, but to use the default Logic App connection, we need to choose the a Cosmos DB SQL API. We'll set this up via the Azure Portal.

To get started with Cosmos DB, you create an account, then a database, then a container to store JSON documents. To create a new Cosmos DB account from the portal dashboard, Select Create a resource > Azure Cosmos DB > Create. Choose core SQL for the API.

Select your subscription, then create a new resource group called CosmosWeather. Enter an account name and choose a location, select provisioned throughput capacity mode and apply the free tier discount. From here you can select Review and Create, then Create

Azure Cosmos DB is available in two different capacity modes: provisioned throughput and serverless. You can perform the same database operations in both modes, but the way you get billed for these operations is different. We wil be using provisioned throughput and the free tier for this example.

Next, create a new database and container. Go to the Data Explorer in your new Cosmos DB account, and choose New Container. Name the database, and keep all the orher defaults except:

Press OK to create a database and container

A database is analogous to a traditional DBMS namespace. It's used to organize one or more containers.

Now we're ready to set up our logic app an write to Cosmos DB!

Setup Logic App connection + event​

Once the Cosmos DB SQL API account is created, we can set up our Logic App. From the portal dashboard, Select Create a resource > Integration > Logic App > Create. Name your Logic App and select a location, the rest fo the settings can be left at their defaults. Once you new Logic App is created, select Create a workflow from designer to get started.

A workflow is a series of steps that defines a task or process. Each workflow starts with a single trigger, after which you must add one or more actions.

When in designer, search for weather on the right under Add a trigger. Choose MSN Weather. Choose When the current conditions change as the trigger.

A trigger is always the first step in any workflow and specifies the condition for running any further steps in that workflow.

Add a location. Valid locations are City, Region, State, Country, Landmark, Postal Code, latitude and longitude. This triggers a new workflow when the conditions change for a location.

Write data from Logic App to Cosmos DB​

Now we are ready to set up the action to write data to Cosmos DB. Choose add an action and choose Cosmos DB.

An action is each step in a workflow after the trigger. Every action runs some operation in a workflow.

In this case, we will be writing a JSON document to the Cosmos DB container we created earlier. Choose Create or Update Document from the actions. At this point you should have a workflow in designer that looks something like this:

Start wth the connection for set up the Cosmos DB action. Select Access Key, and provide the primary read-write key (found under keys in Cosmos DB), and the Cosmos DB account ID (without 'documents.azure.com').

Next, fill in your Cosmos DB Database ID and Collection ID. Create a JSON document bt selecting dynamic content elements and wrapping JSON formatting around them.

You will need a unique ID for each document that you write to Cosmos DB, for that you can use an expression. Because we declared id to be our unique ID in Cosmos DB, we will use use that for the name. Under expressions, type guid() and press enter to add a unique ID to the JSON document. When complete, you should have a workflow in designer that looks something like this:

Save the workflow and test the connections by clicking Run Trigger > Run. If connections are working, you should see documents flowing into Cosmos DB over the next few minutes.

Check the data in Cosmos Db by opening the Data explorer, then choosing the container you created and selecting items. You should see documents similar to this:

Resources: For self-study!​

Once you've grasped the basics in ths post, there is so much more to learn!

• Check out the other Serverless September posts.
• For more detail about Cosmos DB, see the docs at https://learn.microsoft.com/azure/cosmos-db/
• For more info on Logic Apps, see the docs at https://learn.microsoft.com/azure/logic-apps/

Thanks for stopping by!

Welcome to Day 15 of #30DaysOfServerless!

This post marks the midpoint of our Serverless on Azure journey! Our Week 2 Roadmap showcased two key technologies - Azure Container Apps (ACA) and Dapr - for building serverless microservices. We'll also look at what happened elsewhere in #ServerlessSeptember, then set the stage for our next week's focus: Serverless Integrations.

Ready? Let's Go!

What We'll Cover​

• ICYMI: This Week on #ServerlessSeptember
• Recap: Microservices, Azure Container Apps & Dapr
• Coming Next: Serverless Integrations
• Exercise: Take the Cloud Skills Challenge
• Resources: For self-study!

This Week In Events​

We had a number of activities happen this week - here's a quick summary:

• On Zero To Hero:
  Anthony Chu took us on a Journey to the Cloud with Azure Container Apps exploring tools to simplify develop-deploy workflows for ACA. And Melony Qin talked about Using Custom Handlers For Go, explaining how this allows extended languages support in Azure Functions.
• On Serverless Hacks:
  Gwyn was joined by Liam Hampton as they talked about How to DevOps and Serverless The Right Way. And it's not too late to complete the hack and submit your solution to our hall of fame.
• On Ask The Expert:
  We had our first Live Q&A Session featuring members of the Azure Functions team, hosted by Gwyn. Catch up on the recording for useful tips and guidance.

This Week in #30Days​

In our #30Days series we focused on Azure Container Apps and Dapr.

• In Hello Container Apps we learned how Azure Container Apps helps you run microservices and containerized apps on serverless platforms. And we build and deployed our first ACA.
• In Microservices Communication we explored concepts like environments and virtual networking, with a hands-on example to show how two microservices communicate in a deployed ACA.
• In Scaling Your Container Apps we learned about KEDA (Kubernetes Event-Driven Autoscaler) and how to configure autoscaling for your ACA based on KEDA-supported triggers.
• In Build with Dapr we introduced the Distributed Application Runtime (Dapr) and learned how its Building Block APIs and sidecar architecture make it easier to develop microservices with ACA.
• In Secure ACA Access we learned how to secure ACA access to external services with - and without - Dapr, covering Secret Stores and Managed Identity.
• Finally, Build ACA with Dapr tied it all together with a enterprise app scenario where an orders processor (ACA) uses Dapr APIs (PubSub, State Management) to receive and store order messages from Azure Service Bus.

Here's a visual recap:

Self Study: Code Samples & Tutorials​

There's no better way to get familiar with the concepts, than to dive in and play with code samples and hands-on tutorials. Here are 4 resources to bookmark and try out:

1. Dapr Quickstarts - these walk you through samples showcasing individual Building Block APIs - with multiple language options available.
2. Dapr Tutorials provides more complex examples of microservices applications and tools usage, including a Distributed Calculator polyglot app.
3. Next, try to Deploy a Dapr application to Azure Container Apps to get familiar with the process of setting up the environment, then deploying the app.
4. Or, explore the many Azure Container Apps samples showcasing various features and more complex architectures tied to real world scenarios.

What's Next: Serverless Integrations!​

So far we've talked about core technologies (Azure Functions, Azure Container Apps, Dapr) that provide foundational support for your serverless solution. Next, we'll look at Serverless Integrations - specifically at technologies like Azure Logic Apps and Azure Event Grid that automate workflows and create seamless end-to-end solutions that integrate other Azure services in serverless-friendly ways.

Take the Challenge!​

The Cloud Skills Challenge is still going on, and we've already had hundreds of participants join and complete the learning modules to skill up on Serverless.

There's still time to join and get yourself on the leaderboard. Get familiar with Azure Functions, SignalR, Logic Apps, Azure SQL and more - in serverless contexts!!

Welcome to Day 14 of #30DaysOfServerless!

In the past few days we focused our attention on Azure Container Apps, building microservices-based solutions and learning related concepts like environments, networking and auto-scaling - before introducing the sidecar capability of Dapr. Today, we look at how Dapr and ACA work seamlessly together to simplify microservices development in the cloud.

What We'll Cover​

• Dapr refresher
• Application scenario we are covering today
• Quickstart: Build your first ACA with Dapr
• Exercise: Try this yourself!
• What's Next: Advanced scenario in 12-part series
• Resources: For self-study!

Introduction To Dapr​

As developers, we are often tasked with create scalable resilient and distributed microservices, but face challenges such as recovering state after failures, establishing reliable communication between services, integrating with external resources and instrumenting distributed tracing for end-to-end solution observability. Dapr (Distributed Application Runtime) offers an approach for solving these common problems more easily.

Dapr provides its core capabilities as a set of Building Blocks as detailed in the introduction to dapr article released as a part of this series. Building Blocks provide consistent APIs that abstract away the implementation details to keep microservices code simple and portable.

Today's App Scenario​

In this blog post we will create an Azure Container App which will act as an internal-only, background processor service. This service will not be accessible from the internet or from other services directly. We will also configure two Dapr building blocks (APIs): Pub/Sub and State Management. Let's take a look at the architecture diagram below to have better understanding of what we are building:

Our service, orders-processor, will be processing messages published to an Azure Service Bus Topic named orderreceivedtopic. The Dapr Pub/Sub building block will be configured by providing a configuration file named pubsub-svcbus.yaml which contains all the needed information to establish the connection between the container app and the service bus topic. Once a message is consumed by the orders-processor service, it will store a copy of it in Azure Cosmos DB. To wire up Cosmos DB, we will use the Dapr State Store building block and a statestore-cosmosdb.yaml component.

Because we are leveraging Dapr, we will not introduce any SDK for Azure Service Bus nor Azure Cosmos DB; everything will be configured using the component files, so let's jump into the code! :)

Build ACA with Dapr​