Configure the software stack to run your app, including the language and SDK versions.

For Linux apps and custom container apps, you can also set an optional start-up command or file.

Image courtesy of Microsoft.com

Configure settings for the hosting platform, including:

• Platform bitness: 32-bit or 64-bit (for Windows apps only)
• FTP state: Allow only FTPS or disable FTP altogether
• HTTP version: Set to 2.0 to enable support for HTTPS/2 protocol

Configure additional settings, including:

• Web sockets: For ASP.NET SignalR or socket.io, for example
• Always On: Keeps the app loaded even when there's no traffic
• ARR affinity: Ensure that the client is routed to the same instance for the life of the session
• HTTPS Only: Redirect all HTTP traffic to HTTPS
• Minimum TLS version: Select the minimum TLS encryption version required by your app

Configure debugging and security settings, including:

• Debugging: Enable remote debugging for ASP.NET, ASP.NET Core, or Node.js apps
• Incoming client certificates: Require client certificates in mutual authentication

In the Configuration > Path mappings section, you can configure handler mappings and virtual application and directory mappings.

The following options are available for adding certificates in App Service:

• Create a free App Service managed certificate
• Purchase an App Service certificate
• Import a certificate from Key Vault
• Upload a private certificate
• Upload a public certificate

If you want to use a private certificate in App Service, your certificate must meet the following requirements:

• Exported as a password-protected PFX file, encrypted using triple DES
• Contains private key at least 2,048 bits long
• Contains all intermediate certificates and the root certificate in the certificate chain

The free App Service managed certificate is a turn-key solution for securing your custom DNS name in App Service.

Before you create a free managed certificate, make sure you meet the prerequisites for your app.

The free certificate comes with the following limitations:

• Doesn't support wildcard certificates
• Doesn't support usage as a client certificate by using certificate thumbprint
• Doesn't support private DNS
• Isn't exportable
• Isn't supported in an App Service Environment (ASE)

If you purchase an App Service Certificate from Azure, Azure manages the following tasks:

• Takes care of the purchase process from certificate provider
• Performs domain verification of the certificate
• Maintains the certificate in Azure Key Vault
• Manages certificate renewal
• Synchronize the certificate automatically with the imported copies in App Service apps

Azure App Service supports manual scaling and two options for scaling out your web apps automatically:

• Autoscaling with Azure autoscale
• Azure App Service automatic scaling

Autoscaling makes scaling decisions based on rules that you define.

It monitors the resource metrics of a web app as it runs and detects situations where other resources are required to handle an increasing workload.

Automatic scaling makes scaling decisions for you based on the parameters that you select.

It monitors the load and adds instances as your web app starts receiving HTTP traffic.

Autoscaling provides elasticity for your services and improves availability and fault tolerance.

Use autoscaling when you expect increased or reduced activity for a business app during holidays or other events.

Use automatic scaling when you don't want to set up autoscale rules based on resource metrics.

Use automatic scaling when you want your web apps within the same App Service Plan to scale differently and independently of each other.

Azure App Service supports manual scaling and two options for scaling out your web apps automatically:

• Autoscaling with Azure autoscale
• Azure App Service automatic scaling

Autoscaling enables you to specify the conditions under which a web app should be scaled out, and back in again.

Effective autoscaling ensures sufficient resources are available to handle large volumes of requests at peak times, while managing costs when the demand drops.

Autoscaling is a feature of the App Service Plan used by the web app.

When the web app scales out, Azure starts new instances of the hardware defined by the App Service Plan to the app.

Azure provides two options for autoscaling:

• Scale based on a metric
• Scale to a specific instance count according to a schedule

Autoscaling by metric requires that you define one or more autoscale rules.

The metrics you can monitor for a web app are:

• CPU Percentage
• Memory Percentage
• Disk Queue Length
• Http Queue Length
• Data In
• Data Out

Autoscaling works by analyzing trends in metric values over time across all instances.

Analysis is a multi-step process.

When an autoscale rule detects that a metric crossed a threshold, it can perform an autoscale action.

An autoscale action can be scale-out or scale-in.

You should plan for scaling-in when a workload decreases.

Consider defining autoscale rules in pairs in the same autoscale condition.

A single autoscale condition can contain several autoscale rules.

The autoscale rules in an autoscale condition don't have to be directly related.

Clone the Sample App Repository

Run the following git command:

      
        git clone https://github.com/Azure-Samples/html-docs-hello-world.git
      
      Copy
    

Create a Resource Group

Run the following command:

      
        az group create --name myResourceGroup --location westus
      
      Copy
    

Create an App Service Plan

Run the following command:

      
        az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --location westus --sku S1
      
      Copy
    

Create a Web App

Run the following command:

      
        az webapp create --name myWebApp --resource-group myResourceGroup --plan myAppServicePlan --location westus
      
      Copy
    

Deploy the Web App

Run the following command:

      
        az webapp deployment slot create --name myWebApp --resource-group myResourceGroup --slot production
      
      Copy
    

      
        az webapp deployment slot update --name myWebApp --resource-group myResourceGroup --slot production --package ./html-docs-hello-world
      
      Copy
    

Run the following command:

      
        az appservice plan update --name myAppServicePlan --resource-group myResourceGroup --sku S2
      
      Copy
    

Run the following command:

      
        az webapp show --name myWebApp --resource-group myResourceGroup --query defaultHostName --output tsv
      
      Copy
    

      
        az appservice plan update --name myAppServicePlan --resource-group myResourceGroup --sku S1
      
      Copy
    

Delete the Resource Group

Run the following command:

      
        az group delete --name myResourceGroup --yes
      
      Copy
    

• Validate app changes in a staging deployment slot before swapping it with the production slot.
• Deploying an app to a slot first and then swapping it into production ensures that all instances of the slot are warmed up before being swapped into production.
• Eliminates downtime when you deploy your app.
• The traffic redirection is seamless, and no requests are dropped because of swap operations.

Each deployment slot is a live app with its own host name.

App content and configuration elements can be swapped between two deployment slots, including the production slot.

After a swap, the previous production app is located in the staging slot.

Each App Service plan tier supports a different number of deployment slots.

There's no extra charge for using deployment slots.

To find out the number of slots your app's tier supports, visit App Service limits.

To scale your app to a different tier, make sure that the target tier supports the number of slots your app already uses.

For example, if your app has more than five slots, you can't scale it down to the Standard tier, because the Standard tier supports only five deployment slots.

When you create a new deployment slot the new slot has no content, even if you clone the settings from a different slot.

You can deploy to the slot from a different repository branch or a different repository.

The slot's URL has the format http://sitename-slotname.azurewebsites.net.

The following table shows the settings that change when you swap slots:

To make settings swappable, add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS in every slot of the app and set its value to 0 or false.

To configure an app setting or connection string to stick to a specific slot (not swapped), go to the Configuration page for that slot, add or edit a setting, and then select Deployment slot setting.

You can swap deployment slots on your app's Deployment slots page and the Overview page.

Manually Swapping Deployment Slots

To swap deployment slots:

1. Go to your app's Deployment slots page and select Swap.
2. Select the desired Source and Target slots.
3. Verify the configuration changes are expected.
4. Swap the slots immediately by selecting Swap.

Swap with Preview (Multi-Phase Swap)

Before you swap into production as the target slot, validate that the app runs with the swapped settings.

1. Follow the steps in Swap deployment slots section, but select the Perform swap with preview checkbox.
2. When you're ready to start the swap, select Start Swap.
3. When phase 1 finishes, you're notified in the dialog box.
4. Preview the swap in the source slot by going to https://<app_name>-<source-slot-name>.azurewebsites.net.
5. When you're ready to complete the pending swap, select Complete Swap in Swap action and select Complete Swap.

Auto swap streamlines Azure DevOps Services scenarios where you want to deploy your app continuously with zero cold starts and zero downtime for customers of the app.

1. Go to your app's resource page and select the deployment slot you want to configure to auto swap.
2. Set Auto swap enabled to On.
3. Select the desired target slot for Auto swap deployment slot.
4. Select Save on the command bar.

You can swap deployment slots from the command line using the Azure CLI.

      
        az webapp deployment slot swap --resource-group myResourceGroup --name myApp --slot mySlot
      
      Copy
    

To swap with preview:

      
        az webapp deployment slot swap --resource-group myResourceGroup --name myApp --slot mySlot --preview
      
      Copy
    

To cancel a pending swap:

      
        az webapp deployment slot swap --resource-group myResourceGroup --name myApp --slot mySlot --cancel
      
      Copy
    

Some apps might require custom warm-up actions before the swap.

The applicationInitialization configuration element in web.config lets you specify custom initialization actions.

      
        <system.webServer>
          <applicationInitialization>
            <add initializationPage="/statuscheck" hostName="[app hostname]" />
            <add initializationPage="/Home/About" hostName="[app hostname]" />
          </applicationInitialization>
        </system.webServer>
      
      Copy
    

In this exercise, you deploy a basic HTML+CSS site to Azure App Service with the Azure CLI az webapp up command. Next, you update the code and deploy the change to a staging slot. Finally, you swap the slots.

Run the following commands:

      
        git clone https://github.com/Azure-Samples/html-docs-hello-world.git
      
      Copy
    

      
        resourceGroup=rg-mywebapp
        appName=mywebapp$RANDOM
        echo $appName
      
      Copy
    

      
        cd html-docs-hello-world
        az webapp up -g $resourceGroup -n $appName --sku P0V3 --html
      
      Copy
    

Run the following command:

      
        az webapp deployment slot create -n $appName -g $resourceGroup --slot staging
      
      Copy
    

Run the following commands:

      
        code index.html
        # update the code
        zip -r stagingcode.zip .
      
      Copy
    

      
        az webapp deploy -g $resourceGroup -n $appName --src-path ./stagingcode.zip --slot staging
      
      Copy
    

Run the following command:

      
        az webapp deployment slot swap -n $appName -g $resourceGroup --slot staging
      
      Copy
    

After swapping the staging and production slots, verify that the changes are reflected in the production slot.

1. Navigate to the web app in the Azure portal.
2. Click on the link to the web app in the Default domain field in the Essentials section.
3. Verify that the changes you made to the index.html file are reflected in the production slot.
4. Refresh the page if necessary to see the changes.

After swapping the staging and production slots, verify that the changes are reflected in the production slot.

      
        az webapp show -n $appName -g $resourceGroup --query defaultHostName
      
      Copy
    

Open a web browser and navigate to the default host name of the web app.

Verify that the changes you made to the index.html file are reflected in the production slot.

Run the following command:

      
        az group delete -n $resourceGroup --yes
      
      Copy
    

Azure Functions is a serverless solution that allows you to build robust apps while using less code, and with less infrastructure and lower costs.

Triggers are mechanisms to start executing your code based on specific events.

Bindings simplify the coding process for input and output data by abstracting away the underlying details.

Azure Functions supports various built-in binding types and allows custom bindings through code.

Here is a summary of the benefits of each hosting option:

• Consumption Plan: Pay-as-you-go, automatic scaling, and no container support.
• Flex Consumption Plan: High scalability, virtual networking, and pay-as-you-go billing.
• Premium Plan: Automatically scales, prewarmed workers, and virtual network connectivity.
• Dedicated Plan: Run functions within an App Service plan at regular rates, best for long-running scenarios.
• Container Apps: Create and deploy containerized function apps in a fully managed environment.

Here are some scenarios to consider when choosing a hosting option:

• Consumption Plan: Suitable for most use cases, especially those with variable or unpredictable traffic.
• Flex Consumption Plan: Choose this plan when you need high scalability, virtual networking, and pay-as-you-go billing.
• Premium Plan: Consider this plan when you need more control over your instances, want to deploy multiple function apps on the same plan, or need virtual network connectivity.
• Dedicated Plan: Use this plan when you need fully predictable billing, want to run multiple web apps and function apps on the same plan, or need access to larger compute size choices.
• Container Apps: Choose this option when you want to package custom libraries with your function code, need to migrate code execution from on-premises or legacy apps, or want to avoid managing Kubernetes clusters.

The functionTimeout property in the host.json project file specifies the time-out duration for functions in a function app.

• Consumption plan: Event-driven scaling, max 200 instances (Windows), 100 instances (Linux)
• Flex Consumption plan: Per-function scaling, limited by total memory usage
• Premium plan: Event-driven scaling, max 100 instances (Windows), 20-100 instances (Linux)
• Dedicated plan: Manual/autoscale, max 10-30 instances, 100 instances (ASE)
• Container Apps: Event-driven scaling, max 10-300 instances

• 500 instances per subscription per hour for Linux apps on a Consumption plan
• Some regions have specific limits for Premium plan instances
• App Service plan limits apply to Dedicated plan instances
• Container Apps: Maximum replicas limited by available cores quota

• Azure subscription
• Visual Studio Code
• .NET 8
• C# Dev Kit for Visual Studio Code
• Azure Functions extension for Visual Studio Code
  https://github.com/Azure/azure-functions-core-tools?tab=readme-ov-file#installing
• Azure Functions Core Tools version 4.x

Use Visual Studio Code to create a local Azure Functions project in C#.

Press F1 to open the command palette and search for and run the command Azure Functions: Create New Project...

Select the directory location for your project workspace and choose Select.

Provide the following information at the prompts:

• Select the folder that will contain your function projects
• Select a language (C#)
• Select a .NET runtime (.NET 8.0 Isolated)
• Select a template for your project's first function (HTTP trigger)
• Provide a function name (HttpExample)
• Provide a namespace (My.Function)
• Authorization level (Anonymous)

Visual Studio Code integrates with Azure Functions Core tools to let you run this project on your local development computer.

Press F5 to start the function app project in the debugger.

Output from Core Tools is displayed in the Terminal panel.

Go to the Azure: Functions area and expand Local Project > Functions.

Right-click the HttpExample function and select Execute Function Now...

In Enter request body type the request message body value of { "name": "Azure" }.

Press Enter to send this request message to your function.

Create an Azure Function App resource and deploy the function to the resource.

Sign in to Azure by choosing the Azure icon in the Activity bar and selecting Sign in to Azure...

Create resources in Azure by choosing the Azure icon in the Activity bar and selecting Create resource...

Provide the following information at the prompts:

• Select a resource to create (Create Function App in Azure...)
• Select subscription
• Enter a globally unique name for the function app
• Select a location for new resources
• Select a runtime stack (.NET 8.0 Isolated)
• Select resource authentication type (Secrets)

Deploy the project to Azure by searching for and running the command Azure Functions: Deploy to Function App...

Select the subscription and function app you created.

When prompted about overwriting previous deployments, select Deploy.

After deployment completes, select View Output to view the details of the deployment results.

Delete the cloud resources you created to avoid unnecessary resource usage.

Navigate to the Azure portal and sign in with your Azure credentials.

Navigate to the resource group you created and view the contents of the resources used in this exercise.

On the toolbar, select Delete resource group.

Enter the resource group name and confirm that you want to delete it.

An Azure Storage account is the top-level container for all of your Azure Blob storage.

There are two performance levels of storage accounts:

• Standard: General-purpose v2 account, recommended for most scenarios
• Premium: Higher performance using solid-state drives, with three account types: block blobs, page blobs, or file shares

Azure Storage provides different options for accessing block blob data based on usage patterns.

There are four access tiers:

• Hot: Optimized for frequent access, highest storage costs, lowest access costs
• Cool: Optimized for infrequent access, lower storage costs, higher access costs
• Cold: Optimized for infrequent access, lower storage costs, higher access costs
• Archive: Optimized for data that can tolerate several hours of retrieval latency, lowest storage costs, highest access costs

Azure Storage automatically encrypts your data when persisting it to the cloud.

Encryption protects your data and helps you meet your organizational security and compliance commitments.

Data in Azure Storage is encrypted and decrypted transparently using 256-bit Advanced Encryption Standard (AES) encryption.

Data in a new storage account is encrypted with Microsoft-managed keys by default.

You can continue to rely on Microsoft-managed keys or manage encryption with your own keys.

There are two options for managing encryption with your own keys:

• Customer-managed keys: Stored in Azure Key Vault or Azure Key Vault Managed Hardware Security Model (HSM)
• Customer-provided keys: Provided on Blob Storage operations for granular control over encryption and decryption

The Azure Blob Storage client libraries for .NET, Java, and Python support encrypting data within client applications before uploading to Azure Storage.

The Queue Storage client libraries for .NET and Python also support client-side encryption.

The Blob Storage and Queue Storage client libraries use AES to encrypt user data.

There are two versions of client-side encryption available:

• Version 2: Uses Galois/Counter Mode (GCM) mode with AES
• Version 1: Uses Cipher Block Chaining (CBC) mode with AES

• Hot: Online tier for frequently accessed data
• Cool: Online tier for infrequently accessed data, stored for a minimum of 30 days
• Cold: Online tier for infrequently accessed data, stored for a minimum of 90 days
• Archive: Offline tier for rarely accessed data, stored for at least 180 days

Azure Blob Storage lifecycle management offers a rule-based policy to transition blob data to the appropriate access tiers or to expire data at the end of the data lifecycle.

With the lifecycle management policy, you can:

• Transition blobs from cool to hot immediately when accessed
• Transition blobs to a cooler storage tier if not accessed or modified for a period of time
• Delete blobs at the end of their lifecycles
• Apply rules to an entire storage account, select containers, or a subset of blobs

Consider a scenario where data is frequently accessed during the early stages of the lifecycle, but only occasionally after two weeks.

Beyond the first month, the data set is rarely accessed.

In this scenario, hot storage is best during the early stages, cool storage is most appropriate for occasional access, and archive storage is the best tier option after the data ages over a month.

By moving data to the appropriate storage tier based on its age with lifecycle management policy rules, you can design the least expensive solution for your needs.

You can configure your databases to be globally distributed and available in any of the Azure regions.

This allows you to place the data close to where your users are, reducing latency.

You can add or remove regions associated with your account at any time, without pausing or redeploying your application.

• Unlimited elastic write and read scalability
• 99.999% read and write availability all around the world
• Guaranteed reads and writes served in less than 10 milliseconds at the 99th percentile

Azure Cosmos DB's multi-master replication protocol enables these benefits, allowing every region to support both writes and reads.

Running a database in multiple regions worldwide increases the availability of a database.

If one region is unavailable, other regions automatically handle application requests.

Azure Cosmos DB offers 99.999% read and write availability for multi-region databases.

An Azure Cosmos DB container is the fundamental unit of scalability.

A container can have virtually unlimited provisioned throughput (RU/s) and storage.

Azure Cosmos DB transparently partitions a container using a logical partition key for elastic scaling.

You can create one or multiple Azure Cosmos DB databases under an account.

A database is analogous to a namespace and is the unit of management for a set of containers.

An Azure Cosmos DB container is where data is stored.

A container scales out, unlike relational databases which scale up.

Data is stored on one or more servers called partitions.

A partition key is required when creating a container to distribute data efficiently across partitions.

Azure Cosmos DB uses physical partitions to store data, with a maximum throughput of 10,000 RU/s and 50 GB of storage.

Logical partitions are used to abstract physical partitions, with a maximum storage of 20 GB.

Throughput can be configured in one of two modes:

• Dedicated throughput: Exclusively reserved for a container
• Shared throughput: Specified at the database level and shared with up to 25 containers

Individual data entities can be represented in various ways depending on the API used:

Azure Cosmos DB offers five consistency levels, from strongest to weakest:

1. Strong
2. Bounded staleness
3. Session
4. Consistent prefix
5. Eventual

Each level provides availability and performance tradeoffs.

The consistency levels can be viewed as a spectrum, with strong consistency at one end and eventual consistency at the other.

The levels in between offer varying degrees of consistency and availability.

The consistency levels are region-agnostic, meaning they are guaranteed for all operations, regardless of:

• The region where reads and writes are served
• The number of regions associated with your Azure Cosmos DB account
• Whether your account is configured with a single or multiple write regions

Read consistency applies to a single read operation scoped within a partition-key range or a logical partition.

This ensures that reads are consistent within a specific scope.

Consider the following when choosing an API:

• If you have existing applications
• If you don't want to rewrite your entire data access layer
• If you want to use the open-source developer ecosystem, client-drivers, expertise, and resources for your database

The Azure Cosmos DB API for NoSQL stores data in document format.

It offers the best end-to-end experience as we have full control over the interface, service, and the SDK client libraries.

The Azure Cosmos DB API for MongoDB stores data in a document structure, via BSON format.

It's compatible with MongoDB wire protocol; however, it doesn't use any native MongoDB related code.

Azure Cosmos DB for PostgreSQL is a managed service for running PostgreSQL at any scale.

It stores data either on a single node, or distributed in a multi-node configuration.

The Azure Cosmos DB API for Cassandra stores data in column-oriented schema.

Apache Cassandra offers a highly distributed, horizontally scaling approach to storing large volumes of data.

The Azure Cosmos DB API for Gremlin allows users to make graph queries and stores data as edges and vertices.

Use the API for Gremlin for scenarios:

• Involving dynamic data
• Involving data with complex relations
• Involving data that is too complex to be modeled with relational databases

The Azure Cosmos DB API for Table stores data in key/value format.

If you're currently using Azure Table storage, you might see some limitations in latency, scaling, throughput, global distribution, index management, low query performance.

A request unit (RU) represents the system resources such as CPU, IOPS, and memory that are required to perform the database operations supported by Azure Cosmos DB.

The cost to do a point read, which is fetching a single item by its ID and partition key value, for a 1-KB item is 1RU.

The type of Azure Cosmos DB account you're using determines the way consumed RUs get charged.

There are three modes in which you can create an account:

• Provisioned throughput mode
• Serverless mode
• Autoscale mode

In this mode, you provision the number of RUs for your application on a per-second basis in increments of 100 RUs per second.

To scale the provisioned throughput for your application, you can increase or decrease the number of RUs at any time in increments or decrements of 100 RUs.

In this mode, you don't have to provision any throughput when creating resources in your Azure Cosmos DB account.

At the end of your billing period, you get billed for the number of request units consumed by your database operations.

In this mode, you can automatically and instantly scale the throughput (RU/s) of your database or container based on its usage.

This scaling operation doesn't affect the availability, latency, throughput, or performance of the workload.

Here's a simple stored procedure that returns a "Hello World" response.

      
var helloWorldStoredProc = {
    id: "helloWorld",
    serverScript: function () {
        var context = getContext();
        var response = context.getResponse();

        response.setBody("Hello, World");
    }
}
      
      Copy
	  

When you create an item by using a stored procedure, the item is inserted into the Azure Cosmos DB container and an ID for the newly created item is returned.

      
var createDocumentStoredProc = {
    id: "createMyDocument",
    body: function createMyDocument(documentToCreate) {
        var context = getContext();
        var collection = context.getCollection();
        var accepted = collection.createDocument(collection.getSelfLink(),
              documentToCreate,
              function (err, documentCreated) {
                  if (err) throw new Error('Error' + err.message);
                  context.getResponse().setBody(documentCreated.id)
              });
        if (!accepted) return;
    }
}
      
      Copy
	  

When defining a stored procedure in the Azure portal, input parameters are always sent as a string to the stored procedure.

To work around this, you can define a function within your stored procedure to parse the string as an array.

      
function sample(arr) {
    if (typeof arr === "string") arr = JSON.parse(arr);

    arr.forEach(function(a) {
        // do something here
        console.log(a);
    });
}
      
      Copy
	  

All Azure Cosmos DB operations must complete within a limited amount of time.

Stored procedures have a limited amount of time to run on the server.

You can implement transactions on items within a container by using a stored procedure.

JavaScript functions can implement a continuation-based model to batch or resume execution.

A pretrigger is used to validate the properties of an Azure Cosmos item that is being created.

It adds a timestamp property to a newly added item if it doesn't contain one.

      
function validateToDoItemTimestamp() {
    var context = getContext();
    var request = context.getRequest();

    // item to be created in the current operation
    var itemToCreate = request.getBody();

    // validate properties
    if (!("timestamp" in itemToCreate)) {
        var ts = new Date();
        itemToCreate["timestamp"] = ts.getTime();
    }

    // update the item that will be created
    request.setBody(itemToCreate);
}
      
      Copy
	  

A post-trigger queries for the metadata item and updates it with details about the newly created item.

      
function updateMetadata() {
var context = getContext();
var container = context.getCollection();
var response = context.getResponse();

// item that was created
var createdItem = response.getBody();

// query for metadata document
var filterQuery = 'SELECT * FROM root r WHERE r.id = "_metadata"';
var accept = container.queryDocuments(container.getSelfLink(), filterQuery,
    updateMetadataCallback);
if(!accept) throw "Unable to update metadata, abort";

function updateMetadataCallback(err, items, responseOptions) {
    if(err) throw new Error("Error" + err.message);
        if(items.length != 1) throw 'Unable to find metadata document';

        var metadataItem = items[0];

        // update metadata
        metadataItem.createdItems += 1;
        metadataItem.createdNames += " " + createdItem.id;
        var accept = container.replaceDocument(metadataItem._self,
            metadataItem, function(err, itemReplaced) {
                    if(err) throw "Unable to update metadata, abort";
            });
        if(!accept) throw "Unable to update metadata, abort";
        return;
    }
}
      
      Copy
	  

A user-defined function can be used to calculate income tax for various income brackets.

This user-defined function would then be used inside a query.

      
function tax(income) {

        if(income == undefined)
            throw 'no input';

        if (income < 1000)
            return income * 0.1;
        else if (income < 10000)
            return income * 0.2;
        else
            return income * 0.4;
    }
      
      Copy
	  

Today, you see all inserts and updates in the change feed.

You can't filter the change feed for a specific type of operation.

You can work with the Azure Cosmos DB change feed using either a push model or a pull model.

With a push model, the change feed processor pushes work to a client that has business logic for processing this work.

There are two ways you can read from the change feed with a push model: Azure Functions Azure Cosmos DB triggers, and the change feed processor library.

Azure Functions uses the change feed processor behind the scenes, so these are both similar ways to read the change feed.

You can create small reactive Azure Functions that are automatically triggered on each new event in your Azure Cosmos DB container's change feed.

With the Azure Functions trigger for Azure Cosmos DB, you can use the Change Feed Processor's scaling and reliable event detection functionality without the need to maintain any worker infrastructure.

The change feed processor is part of the Azure Cosmos DB .NET V3 and Java V4 SDKs.

It simplifies the process of reading the change feed and distributes the event processing across multiple consumers effectively.

      
/// 

/// Start the Change Feed Processor to listen for changes and process them with the HandleChangesAsync implementation.
/// 
private static async Task StartChangeFeedProcessorAsync(
    CosmosClient cosmosClient,
    IConfiguration configuration)
{
    string databaseName = configuration["SourceDatabaseName"];
    string sourceContainerName = configuration["SourceContainerName"];
    string leaseContainerName = configuration["LeasesContainerName"];

    Container leaseContainer = cosmosClient.GetContainer(databaseName, leaseContainerName);
    ChangeFeedProcessor changeFeedProcessor = cosmosClient.GetContainer(databaseName, sourceContainerName)
        .GetChangeFeedProcessorBuilder(processorName: "changeFeedSample", onChangesDelegate: HandleChangesAsync)
            .WithInstanceName("consoleHost")
            .WithLeaseContainer(leaseContainer)
            .Build();

    Console.WriteLine("Starting Change Feed Processor...");
    await changeFeedProcessor.StartAsync();
    Console.WriteLine("Change Feed Processor started.");
    return changeFeedProcessor;
}
      
      Copy
	  

The delegate receives batches of changes as they are generated in the change feed and can process them.

      
/// 

/// The delegate receives batches of changes as they are generated in the change feed and can process them.
/// 
static async Task HandleChangesAsync(
    ChangeFeedProcessorContext context,
    IReadOnlyCollection changes,
    CancellationToken cancellationToken)
{
    Console.WriteLine($"Started handling changes for lease {context.LeaseToken}...");
    Console.WriteLine($"Change Feed request consumed {context.Headers.RequestCharge} RU.");
    // SessionToken if needed to enforce Session consistency on another client instance
    Console.WriteLine($"SessionToken ${context.Headers.Session}");

    // We may want to track any operation's Diagnostics that took longer than some threshold
    if (context.Diagnostics.GetClientElapsedTime() > TimeSpan.FromSeconds(1))
    {
        Console.WriteLine($"Change Feed request took longer than expected. Diagnostics:" + context.Diagnostics.ToString());
    }

    foreach (ToDoItem item in changes)
    {
        Console.WriteLine($"Detected operation for item with id {item.id}, created at {item.creationTime}.");
        // Simulate some asynchronous operation
        await Task.Delay(10);
    }

    Console.WriteLine("Finished handling changes.");
}
      
      Copy