DEV Community: Rick van den Bosch

API Management: advanced usage quota

Rick van den Bosch — Tue, 12 Jul 2022 09:48:23 +0000

Introduction

Azure API Management is a hybrid, multicloud management platform for APIs across all environments.

For more information on API Management, check out Microsoft Docs:
About API Management.

API Management (APIM) is an Azure service that enables you to manage APIs as first-class assets throughout their lifecycle. It consists of an API
Gateway, a management plane and a developer portal. All these components are hosted in Azure and are completely managed by default.
Each component has its own place in the ecosystem:

API Gateway Acts as a façade to the backend services
Management Plane Provides full access to the API Management service capabilities
Developer Portal Used to discover the APIs, onboard to use them, and learn how to consume them

Rate limits and quotas

The power of APIM is that it enables you to define different types of policies on different levels, giving you lots of power on how your
APIs are being used. For instance, you can define rate limits and quotas for your APIs. By defining and checking these in APIM, you can
control the consumption of your APIs early; requests that exceed the rate limit or quota will be rejected at APIM level and will not even
hit your backend service.

But sometimes the built-in quotas might not be enough, forcing you to define your own. For one of our customers we had the requirement to
have something like credit for two specific API operations. Customers would buy API-credit (separate from the product they subscribed to)
for a specific amount of requests. Whenever the API is called, it checks to see if the customer still has credit available. If they have,
the API is called as normal. Otherwise, the customer will get a response indicating they don't have credit and they cannot call the API
anymore, or they need to buy more credit. This last scenario should be configurable by the sales team.

Again, these credits are not connected to the product a customer subscribes to. And each customer might have different levels of credit for
the same API operation. This flexibility combined with the requested ease of configuration made it impossible to completely manage this in
APIM without building too complex code and/or policies.

The options

Because of the expected load of the API endpoints, calling out into for instance an Azure Function to check and see if a customer still has
credit available would not be a great fit. The intial reason for this customer to move to APIM was that they were having performance issues
trying to store usage statistics to enable them to implement rate limiting.

In the end we decided to create API middleware that would allow us to check the credit status for a specific API. But it is middleware with
a smart addition...

The solution

Since performance is key, and overshooting quota by a few requests is not an issue, the amount of requests and the customer credit can be
cached in memory for a certain amount of time. At least for now. If need be we can always move it to a distributed cache like Redis. But how
will we know the amount of requests a customer has made? This is where the
Azure API Management REST API comes in, and more specifically the operation
Quota By Counter Keys - List By Service.
This API ...

Lists a collection of current quota counter periods associated with the counter-key configured in the policy on the specified service
instance.

This means it allows us to retrieve the Number of times Counter was called and even the Data Transferred in KiloBytes.

{
  "value": [
    {
      "counterKey": "xxx.xxx.xxx.xxx",
      "periodKey": "SOME_PERIODKEY",
      "periodStartTime": "2022-07-01T00:00:00Z",
      "periodEndTime": "2022-12-31T00:00:00Z",
      "value":
      {
        "callsCount": 42,
        "kbTransferred": 1796.5453825
      }
    }
  ],
  "count": 1,
  "nextLink": null
}

Combining the information from the API Management "Quota By Counter Keys" REST API and the customer credit, we can create middleware that
checks the credit against the number of requests made. Caching the information in the middleware is up to the user's discretion.

Building a Discord bot with Azure Logic Apps

Rick van den Bosch — Thu, 06 May 2021 09:26:16 +0000

The Betatalks Discord

A few months ago we've started a Betatalks Discord server to build a community and enable our friends to
discuss all the Betatalks content we put out there. Think about the
Betatalks videos on YouTube, Betatalks live events and the
most recent addition: Betatalks the podcast.

To notify the corresponding Discord channels about new Betatalks videos or Betatalks the podcast episodes, I created Azure Logic Apps to
check for new additions and post them to the webhook. Here's how I built that.

Creating a Discord webhook

As Discord describes it:

Webhooks are a simple way to post messages from other apps and websites into Discord using internet magic.

When you create a Discord webhook you give it a name (1), select the channel the webhook posts to (2) and you optionally upload an avatar
for the webhook (3). Once you've done all that save your changes, copy the webhook URL (4) and you should be good to go!

Calling Discord webhooks

The most basic form of calling a Discord webhook only needs either a message (in the content property), file contents (in the file
property) or an array of up to 10 embed objects (in the embeds property). This means a most basic, valid payload for a Discord webhook
looks like this:

{
    "content": "Hello world!"
}

More information on the Discord webhook payload can be found in the
Discord developer portal.

Since calling the webhook is as easy as posting an HTTP request to an URL, you can easily test the content you're building using tools like
Postman, hoppscoth.io or Visual Studio Code using the
REST Client extension.

Building the Logic App

The podcast bot uses the RSS feed to determine if there are new episodes and calls the webhook. The YouTube one uses a
connector to YouTube. We'll use the latter as the example in this post.

Triggering the workflow

The selected trigger for the Logic App is YouTube's "When a video is uploaded by a channel". This enables you to select any of the channels
you've subscribed to on YouTube. You can configure how often the Logic App needs to check for new items and then the triggering part of the
Logic App is done.

On one condition

The workflow should run on one condition. Or two actually, but they can be seen as one 😁. We only want to post content to the webhook if
the title of the video contains the term Betatalks but does not contain podcast. To do this, we add a Condition-action to our workflow.
We toLower the video's title and check the conditions we just specified.

Calling the webhook

Now that we've defined our trigger and checked our conditions, we can configure calling the webhook. To do so we add an HTTP action. We
configure it to do a POST to the webhook endpoint with a body we configure based on dynamic content from the trigger. As we saw in the
example earlier we can create a json payload with a content property to hold the message we want to send.

And that's it! To see the resulting messages yourself, check our Betatalks Discord.

Hope this helps!

Using Azure App Configuration in .NET 5 Functions

Rick van den Bosch — Tue, 30 Mar 2021 15:38:57 +0000

Azure .NET 5 Functions

A lot has been said about .NET 5 support for Azure Functions. The most important news: it is now officially supported! 🥳 To enable running
Azure Functions with .NET 5, the new Isolated Model enables Functions to run as an out-of-process language worker separate from the
Azure Functions runtime. This way you'll have full control over the Function's dependencies on one hand, and new features like a middleware
pipeline on the other. For an awesome write-up about everything around this, check out Oscar van Tol's post
Azure Functions in .NET 5 and beyond.

Azure App Configuration

Azure App Configuration provides a service to centrally manage application settings and feature flags. Modern programs, especially programs
running in a cloud, generally have many components that are distributed in nature. Spreading configuration settings across these components
can lead to hard-to-troubleshoot errors during an application deployment. Use App Configuration to store all the settings for your
application and secure their accesses in one place.

What is Azure App Configuration?

For an introduction to Azure App Configuration you can check my previous post
Azure App Configuration: an introduction.

Bringing the two together

To enable using App Configuration in .NET 5 Functions, you can use the AddAzureAppConfiguration extension method to add App Configuration
as a source to the IConfigurationBuilder. This extension method can be found in NuGet package
Microsoft.Extensions.Configuration.AzureAppConfiguration.
By doing this, you can simply call GetValue on IConfiguration to get a value. Based on the order you add configuration sources to the
builder, you will be able to fallback through different source.

For example: if you first add Environment Variables (which includes settings.json files, too!) and add App Configuration second, asking for
a setting 'Setting1' will first try to get that value from App Configuration. If it can't be found there, the application will search for
the setting 'Setting1' in Environment variables.

Wiring up your Functions App

Program.cs:

public static void Main()
{
    var host = new HostBuilder()
        .ConfigureAppConfiguration(c =>
        {
            // Add Environment Variables since we need to get the App Configuration connection string from settings.
            c.AddEnvironmentVariables();
            // Call Build() so we can get values from the IConfiguration.
            var config = c.Build();
            var connectionString = config.GetValue<string>("AppConfigurationConnectionString");
            // Add Azure App Configuration with the connectionstring.
            c.AddAzureAppConfiguration(connectionString);
        })
        .ConfigureFunctionsWorkerDefaults()
    v.Build();

    host.Run();
}

Getting a value from App Configuration in a Function

Triggered.cs (an HttpTriggered Function):

public class Triggered
{
    // Private field to hold IConfiguration
    private IConfiguration _configuration;

    // Constructor that gets IConfiguration injected
    public Triggered(IConfiguration configuration)
    {
        _configuration = configuration;    
    }

    [Function("Triggered")]
    public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequestData req,
        FunctionContext executionContext)
    {
        var response = req.CreateResponse(HttpStatusCode.OK);
        response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
        // Call GetVallue<string> on IConfiguration to get the setting, this calls out to App Configuration
        var settingOne = _configuration.GetValue<string>("Setting1");
        response.WriteString($"The value of the setting is {settingOne}!");

        return response;
    }
}

I tried this with a complete connection string, so including the access key. Of course this can also work without an access key using a
Managed Identity. This eliminates the need for having access keys in code or configuration.

Hope this helps. Happy coding!

Azure Static Web Apps: UPDATE

Rick van den Bosch — Sun, 28 Mar 2021 09:38:41 +0000

After my two previous posts Azure Static Web Apps: a first look and
Azure Static Web Apps: quirks & gotchas, let's have an updated look at ASWA in this post.

Support for new languages 👩🏻‍💻

Announced at Microsoft Ignite this year,
Blazor and C# APIs now supported in Azure Static Web Apps.
This enables .NET developers to build and deploy full stack .NET applications with Static Web Apps.

Blazor support

Since ASWA is a static hosting option, which means we don't have a server component*, the Blazor support for ASWA means support for Blazor WebAssembly.

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.

Source: webassembly.org

* Yes, I know. Serving files is normally also done by a server. But in this case we're talking about a server as a machine that executes server-side code for a web application. With Wasm, we don't need this.

C# Functions support

We can now build C# Functions as the API behind our static web app! I've done so to test out the functionality, more details on that under
'Taking it for a spin'.

🐍 Python Functions support

ASWA now also supports Python as your language of choice for building APIs as the backend for your static website.

With these languages now being supported, developers using JavaScript, C#, and Python can use ASWA to automatically build and deploy full
stack applications from a GitHub repository.

Metrics 📉

As far as metrics go: it improved. However, we're not there yet. It now is possible to see metrics like Requests, Function Hits and
Function errors. Unfortunately I was not able to see any details after drilling into logs. This made me track down an error in my Function
that turned out to be caused by a typo for way longer than I care to admit. 😳

Configuration 📃

Although configuration for ASWA hasn't changed, I now had a reason to play with it. The C# Functions API I created for the Blazor
WebAssembly frontend needed a setting to connect to the right Storage Account. So I needed to add that setting to the Configuration tab. If
you've worked with C# Functions before, you know it has a need for a setting called AzureWebJobsStorage.

Because I got a 500-error from the Function, I thought it might be because of the missing AzureWebJobsStorage so I added it. This didn't
solve my issue (as said earlier I made a typo in another setting) but when I went back to remove it to keep things clean the setting was
gone! Seems like ASWA adds that setting for you, making sure your Functions will run.

So there's probably a storage account somewhere that's associated with my ASWA. Question is; will I be able to read the value for the
AzureWebJobsStorage setting from my Function? And if so,will I be able to store information there? I might dive into that later 😇

Taking it for a spin 🔄

I created a fairly simple solution with a Blazor WebAssembly frontend, a Common project for entities and a C# Functions project for the
API my frontend would talk to. This is not the cleanest implementation (since Table Entities are sent to the frontend) but it gets the
example done. The entire solution is available on GitHub in the rickvdbosch/aswa-example02
repository. The result can be found at blue-water-047654a03. If you go to the 'Fetch
data' page, it will get some blogposts on static web apps from Table Storage through the C# Functions API.

When you're using C# Functions, they too are available at <aswa-url>/api/<function-name>, so you can access them from the frontend without
too much hassle.

Creating the ASWA is the same as it used to be, however this time I could select Blazor as a frontend framework. For the API I just
specified the folder that contained the C# Functions and the GitHub workflow to build and deploy them was automatically created. The
contents of that workflow, which is of course available in the repo as well, looked the same as the one that was created for the JavaScript
Functions. That probably means the Azure/static-web-apps-deploy@v0.0.1-preview task determines what needs to be done on the fly?

Conclusion and resources 🔗

This is the first (big) update on Static Web Apps since the launch of their Preview at Build earlier this year. At first I felt like they
rushed it to announce at Build, and then had other things to attend to. Fortunately, we have Blazor and C# support now 🤓

Microsoft is actively listening to feedback. I even got an answer of the program manager of Azure Functions & Azure Static Web Apps about
the quirks and gotchas post. It is very nice to see the improvevements to ASWA. And then to
think it's still only a preview ... 🤯

Some interesting links to be found here:

Blazor and C# APIs now supported in Azure Static Web Apps

Tutorial: Building a static web app with Blazor in Azure Static Web Apps

Making Serverless (do the) work for you

Rick van den Bosch — Thu, 12 Sep 2019 22:37:20 +0000

Introduction

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles are published every day — that's right, every day — from community members and cloud advocates in the month of September.

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/.

Serverless

Serverless is hot. If you Google the term 'Serverless' you get almost 9.5 million results. The Serverless computing Wikipedia page was created on July 10 2016 and currently has a total of 289 edits. That’s an average of one edit every 4 days. The three major cloud vendors (Amazon, Google and Microsoft) all have a Serverless landing page in place. And if you look at the Google Trends chart for worldwide searches for the term 'Serverless', you’ll see that it has been on a steady incline since early 2016.

Serverless doesn't mean there aren't any servers. It doesn't mean there are less servers. It just means you don't have to manage them, since they are abstracted away by the platform. From both a Dev and an Ops perspective, there are no servers. But we all know they're out there...

Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere.

What ‘serverless’ really means is that, as a developer you don’t have to think about those servers. You just focus on code.

— serverless.com

Serverless in Azure

My personal experience is more geared towards Azure, so I have a bit more in-depth knowledge of how Serverless is available there. The most obvious Serverless service Microsoft Azure provides is Azure Functions. These are set out to “accelerate and simplify application development with serverless compute”. And they do just that.

Have a look at the Azure Serverless Community Library which, at the time of writing this, has 98 examples of just how simple it is to get things done with Azure Functions. And an overall count of 115 serverless examples.

But Serverless in Microsoft Azure doesn’t end with Azure Functions. The thing is.... it’s not entirely clear where it does end. Different pages on azure.com have different summaries of all serverless services.

If you look at the list on the Azure serverless page, they define these categories for their serverless services:

Compute
Workflows and integration
DevOps and developer tools
AI and machine learning
Database
Storage
Monitoring
Analytics

You could question if for instance storage or monitoring are Serverless or PaaS. Or maybe even SaaS…? But when you look at the Compute category you see something that I think is just wrong. Azure App Service is mentioned as a Serverless offering. While with App Service, you specify the tier in which to run the application. Determining number of cores, available memory and.... wait a minute...! I’m specifying a server to run this thing on!!!

Since Serverless is hot, we're naming everything serverless!

We've already seen there are a LOT of Serverless services or products available on Azure. I would like to dive in to a few of them...

Flow & Logic Apps

Microsoft Flow and Azure Logic Apps are quite similar. They're both configuration first integration services. Both of them use the same designer, too. As a matter of fact, Microsoft Flow is built on top of Logic Apps.

And where Microsoft Flow "empowers any office worker to perform simple integrations", Logic Apps "enable advanced or mission-critical integrations" and are a part of Azure.

The designers of both Flow and Logic Apps show a bit of that distinction. In the image below, the bright part on the left is Microsoft Flow, the dark part on the right is the Logic App. Both of them are triggered though a tweet with the text '#Serverless". Both of them do sentiment detection using cognitive services. But where the Flow only shows the basics, Logic Apps already shows more options for customization.

These simple pieces of code, of logic, are triggered by the connector or schedule you select and are really easy to create. I've heard people compare it to IFTTT.

Azure Functions

After using Azure Functions quite extensively I can say: they deliver on their promise. In the beginning. developing Functions was only for those who could find their way in pieces of documentation and a LOT of example code. The entire development lifecycle has been streamlined the past couple of years, including anything that has to do with (local) debugging. The Azure Functions Core Tools enable you to run your Functions locally and debug them just like you would any other wpplication. And it has ASCII art, too!

The different development environments for Azure Functions are visible as soon as you create an Azure Function App in the Azure portal and you click the plus-sign to add a function. You can choose Visual Studio, VS Code, Any Editor + Core tools or In-Portal.

The In-Portal experience enables you to do everything you need to do to get an Azure Function up and running right there in the Azure Portal. After you've selected In-Portal, the system will ask you what kind of template you would like to use. The next step is to write the code needed for your Function. And again, this can be done entirely in the Azure Portal using C# Script (.csx).

The .csx format allows you to write less "boilerplate" and focus on writing just a C# function. Instead of wrapping everything in a namespace and class, just define a Run method.

This experience is close to the experience you get when using Microsoft Flow and Azure Logic Apps, although in this situation you actually need some programming knowledge to get the function to do what you want it to do since you need to write the code yourself.

Triggers & Bindings

Where Serverless compute abstracts away the underlying infrastructure for you, using triggers & bindings abstracts away the external resources you're connecting to.

Consider this code:

public static async Task Run(
    [BlobTrigger("upload/{name}", Connection = "scs")]Stream addedBlob,
    [Blob("copied/{name}", FileAccess.Write, Connection = "scs")]Stream stream,
    string name, ILogger log)
 {
    await addedBlob.CopyToAsync(stream);
 }

There's only one (that's 1) actual line of code in this example, the rest is just configuring the triggers and bindings. And although it's just one line of code, there's a LOT that happens: This code is automatically triggerd when a new blob is added to a specific container, making the stream to the new blob available immediately. You also get the name if the added blob, and a new stream in a separate container pointing to a blob with the same name as the uploaded one. And of course, the contents of one blob are copied to the other.

Now imagine the boilerplate code you would have to write if you want to develop this without the power of the cloud. Or 5 years ago... 😲

Let's break down the code.

The BlobTrigger line states: trigger this Function when there's a new Blob in the 'upload' container and pass its name and a Stream 'addedBlob' for it into the Function.
The Blob binding states: create a blob in the 'copied' container with the same name and pass a Stream 'stream' for it into the Function.
The string 'name' contains the name of the added blob that causes the Trigger, the ILogger log is a logging mechanism the platform passes in.
The call to CopyToAsync is the one actual line of code.

There is so much going on here, with so little code. The platform manages a TON of stuff for you, enabling you to focus on what matters. And there's even more where this came from, enabling developers to finally focus on adding business value to code, instead of writing boilerplate code to, for instance, connect to a resource. For a full and up to date list of supported bindings see..... Supported bindings 🤭

Sidenote

By the way, talking about the platform managing stuff for you... If you're using Key Vault to store application secrets, have a look at using a Managed Identities for Azure Resources to connect to the Key Vault. Better yet, have a look at Key Vault references. It enables you to work with secrets from Azure Key Vault in your App Service or Azure Functions application without requiring any code changes.

Azure Storage

Azure Storage is a Microsoft-managed service providing cloud storage that is highly available, secure, durable, scalable, and redundant. Azure Storage includes Azure Blobs (objects), Azure Data Lake Storage Gen2, Azure Files, Azure Queues, and Azure Tables.

So Azure Storage is more than just blobs. Azure storage enables you to ingest data from anywhere, even at the edge. There are several cost-effective options to retain data. You can have security features in place to safeguard data and control access and of course wrangle data with a broad library of supported tools.

Static website hosting

Next to the normal* things Azure Storage facilitates, it also has a nice added feature: Static Website Hosting.

You can serve static content (HTML, CSS, JavaScript, and image files) directly from a storage container named $web. Hosting your content in Azure Storage enables you to use serverless architectures that include Azure Functions and other Platform as a service (PaaS) services.

Content in the $web container are served through anonymous requests, only available through object read operations and case-sensitive.

Static website hosting is available at no extra charge. Of course you are billed for the blob storage that your site utilizes and the operations costs.

Sidenote

* We're already calling everything Azure Storage is providing 'normal'. But it isn't. Read Azure Storage scalability and performance targets for storage accounts, then determine if it's normal... 😲

Azure Event Grid

The next (logical?) step in Serverless architectures are event-based architectures. Event Grid made events a first-class citizen in Azure. Where triggers might get lazy (since they rely on a form of polling), events are instant. In comes Event Grid: it has built-in support for events coming from Azure services, like storage blobs and resource groups. Event Grid also has support for your own events, using custom topics.

The flow inside Event Grid is as follows:

A publisher decides to send events to Event Grid
An event takes place in an event source
The source sends the event to a topic
A subscription to a topic means you're interested in a specific type of event

Event Grid supports both Event Grid events and Cloud events, a specification for describing event data in a common way.

Azure Event Grid is one of the first public cloud services with available support for CloudEvents, so you can now publish and consume events using both CloudEvents and Azure native events schemas. This means today you can pump Azure Storage events in CloudEvents format into the serverless platform of your choice for handling, or you can ingest events from other cloud platform’s services publishing CloudEvents into the Azure platform and process them on your beloved Azure Functions or Logic Apps already connected to Event Grid. All natively done, with no custom code involved.

Conclusion

While writing this I've already thought of a lot of other stuff I also found worth mentioning, since there is so much cool stuff going on in the (Azure) cloud. Especially around Serverless and developer productivity. The platform is managing more and more for us as developers enabling us to focus on actually adding value.

So the title "Making Serverless do the work for you" actually means two things:

Serverless enables your applications to rapidly scale with little to no up-front costs
Serverless enables your developers to leverage the power of the platform, making them (even) more productive

I'm not sure about you, but I'm making Serverless do the work for me... 😉

Resources

You can find some examples in the GitHub repo Making Serverless Work For You. More context might be found in my articles Using Triggers & Bindings in Azure Functions V2 and Dynamic output bindings in Azure Functions.

Disclaimer

The numbers in this article have been updated on Thursday September 12^th 2019. They give a general feel of the order of magnitude. I'm not aiming at keeping them updated, so if you're reading this at a (much) later point in time, make sure to check the numbers before basing important (business) decisions on them. 🤓

One other thing: do Serverless if it fits. Don't do it because it's hip. Don't use it because everyone else is. Use it because it's the best choice for the situation. And if it isn't, don't!

Using Triggers & Bindings in Azure Functions V2

Rick van den Bosch — Fri, 30 Aug 2019 08:18:17 +0000

To start things off: yes. There’s some pretty decent documentation on all the available Triggers & Bindings in Azure Functions. Like this overview page. And you can also find documentation on specific bindings, like the Service Bus Binding. Nevertheless, I wanted to add to that documentation with some simple, real-world examples using triggers & bindings. So here goes.

Writing to Blob Storage

Consider this very simple BlobTriggered Azure Function. It copies the triggering file into a different container in Azure Blob Storage:

public static async Task Run(
    [BlobTrigger("upload/{name}", Connection = "scs")]Stream addedBlob, 
    string name, ILogger log)
{
    // Setting up my BlobStorageRepository (it's a wrapper)
    var connectionString = Environment.GetEnvironmentVariable("scs", EnvironmentVariableTarget.Process);
    var blobStorageRepository = new BlobStorageRepository(connectionString);

    await blobStorageRepository.AddFileAsync("copied", name, addedBlob);
}

This looks like a decent solution. But bindings can make this code so much simpler!

Consider the next code:

public static async Task Run(
    [BlobTrigger("upload/{name}", Connection = "scs")]Stream addedBlob,
    [Blob("copied/{name}", FileAccess.Write, Connection = "scs")]Stream stream,
    string name, ILogger log)
 {
    await addedBlob.CopyToAsync(stream);
 }

The result here is the same! By using the out binding, you can directly access the stream in the “copied” container. And you can use the “name” parameter from the input binding.

Next to that, it’s not just Stream you can bind to. For the out bindings, here’s the list of types you can bind to (taken from this article):

TextWriter
out string
out byte[]
CloudBlobStream
Stream
CloudBlobContainer
CloudBlobDirectory
ICloudBlob
CloudBlockBlob
CloudPageBlob
CloudAppendBlob

This means you can also bind against, for instance, a CloudBlobContainer to output multiple blobs.

Putting messages on a Service Bus
When it comes to Blobs, chances are you wouldn’t want to write a large amount of them based on one trigger. Although I can think of some scenario’s...

For Service Bus however, this scenario is far more likely. Lets have a look at how we can implement that using a ServiceBusBinding. The below Function reads a file. It then splits the contents on a space, and puts every word on a Service Bus queue as a separated message:

public static void Run(
    [BlobTrigger("to-process/{name}", Connection = "scs")]Stream addedBlob,
    [ServiceBus("process", Connection = "sbcss", EntityType = EntityType.Queue)] ICollector queueCollector,
    string name, ILogger log)
{
    using (var reader = new StreamReader(addedBlob))
    {
        var words = (await reader.ReadToEndAsync()).Split(' ');
        Parallel.ForEach(words.Distinct(), (word) =>     
        {
            queueCollector.Add(word);     
        }); 
    }
}

Now that almost feels like magic ? Almost everything is abstracted away for you: connecting and writing to a Service Bus are not even your concern anymore.
For Service Bus out bindings, the types you can bind to are (taken from here):

out T paramName
out string
out byte[]
out Message
ICollector or IAsyncCollector

The ICollector and IAsyncCollector are for creating multiple messages. A message is created when you call the Add method. In async functions, use the return value or IAsyncCollector instead of an out parameter.

The IAsyncCollector.AddAsync() behavior depends on the type of binding you’re using> And on whether or not the underlying service supports batches. If the service does, calling AddAsync only prepares the items. In that case, calling FlushAsync() actually flushes them. When a function completes successfully, FlushAsync() will be called automatically.

The services that currently support batching:

SendGrid
Twilio
EventHub

There’s an open issue on GitHub that states they Need to drive consistency for IAsyncCollector batching across bindings. Something to keep an eye on.

Hope this helps.

This article was originally posted on rickvandenbosch.net