DEV Community: Sam Vanhoutte

Building a streaming AI companion in your own API

Sam Vanhoutte — Sat, 02 May 2026 09:42:06 +0000

I am co-founder of libelo, which is a platform for discovering parks and nature highlights. One of the features we are building is a conversational companion: an AI assistant that helps users plan hikes, find species, check trail conditions, and get context about the nature around them. The backend is powered by Azure AI Foundry. This post explains why the mobile app does not talk to Foundry directly, how we structure the response so the app can render rich UI cards alongside the text, and how the streaming connection between client and server works.

Why route through your own API

The straightforward implementation is to put Azure AI Foundry credentials in the mobile app and have it call the agent endpoint directly. That approach has enough problems that we ruled it out immediately.

Security.

We are using Azure Entra External Id as authentication mechanism, so we want to keep those tokens for our internal validation and security rules. Storing Azure credentials on a client device are credentials waiting to be extracted. Routing through the API keeps all secrets server-side. The mobile app authenticates to our API with its existing JWT; the API authenticates to Foundry using a managed identity. The client never sees an Azure key.

Monitoring.

We run OpenTelemetry traces on every controller action. By going through our own endpoint we get request counts, latency, token usage, and error rates in the same dashboards as the rest of the API, without any extra instrumentation work. Token consumption shows up as a metric tagged with user ID and operation, which matters when you are watching costs.

Validation and context enrichment.

The companion endpoint accepts a message and an optional context block containing the user's current location, the park or highlight they are viewing, their activity goals, and available time. A FluentValidation pipeline checks all of that before the agent ever sees it. The API then assembles a per-request system instruction block that injects this context into the conversation, something a direct Foundry call from the client would have to replicate itself.

Resilience.

Foundry has transient errors. The server-side client wraps every agent call in a Polly retry pipeline with exponential backoff. The controller catches any unrecoverable failure and returns a 503 Service Unavailable rather than letting an SDK exception propagate to the client as a 500.

Setting up the Azure AI Foundry agent

The agent itself lives in Azure AI Foundry and is created once through the portal. The application code never creates or modifies the agent definition; it only retrieves the existing agent by ID and attaches the per-request tool instances to it.

Start at ai.azure.com. You need an Azure AI Foundry Hub and a project inside it. The Hub is the shared resource that holds model deployments; the project is the workspace where agents live. If you are deploying into an existing Azure subscription, create both from the portal under the Azure AI Foundry service.

Inside the project, deploy a model from the model catalog. For a conversational assistant that calls tools, GPT-4o is the practical choice, but here we are using claude-sonet-4-6. Give the deployment a name you will reference in the agent configuration.

Open the Agents section in the left menu and click New agent. Configure the following:

Model: select the deployment you just created
Name: a display name for the agent (used for identification in logs and the portal)
Instructions: the base system prompt that describes the agent's role and behaviour. Ensure you really test these through. (we have for example added an instruction to not promote competitive products 🤣)

Below you can see the setup of another agent we have to collect user feedback. This agent is having a tool configured that will take input from users and automatically create tickets in a github repo in our organization. (just enabling the tool with a PAT is all what was needed)

The instructions here are the static part of the system prompt. The application injects per-request context (user location, current park, language, safety warnings) on top of this as a system message on each turn. Keep the base instructions focused on persona and rules; leave context for the application to supply.

Once the agent is saved, the portal shows an Agent ID on the overview page. That value goes into your Companion:AgentId configuration setting. The project endpoint URL is shown under Project details and takes the form https://<project>.services.ai.azure.com/api/projects/<project>. That goes into Companion:AzureAIProjectEndpoint.

Granting access to the managed identity

The application authenticates to Azure AI Foundry using DefaultAzureCredential. In production that resolves to the user-assigned managed identity attached to the container app. That identity needs the Azure AI User role assigned on the AI Foundry project resource. This role grants permission to retrieve agent definitions, create conversation sessions, run agents, and read streaming results.

In the Azure Portal, navigate to the AI Foundry project resource, open Access control (IAM), click Add role assignment, and select Azure AI User. Assign it to your managed identity.

For local development, DefaultAzureCredential falls back to your Azure CLI login. Run az login and make sure your account has the same Azure AI User role on the project. The application code requires no changes between local and production.

With the agent ID, the project endpoint, and the role assignment in place, the AIProjectClient initialisation resolves cleanly at startup:

services.AddSingleton<AIProjectClient>(sp =>
{
    var options = sp.GetRequiredService<IOptions<CompanionOptions>>().Value;
    return new AIProjectClient(
        new Uri(options.AzureAIProjectEndpoint),
        new DefaultAzureCredential());
});

The tools

The agent is not just a chat model. It will have access to a set of tools that let it query (sometimes live) data.

ParkStatusTool - retrieves the current status and trail difficulty ratings for a park from the Libelo database
WeatherTool - uses our Meteo Service to get current conditions at a coordinate; weather codes above a severity threshold are prefixed with [SAFETY] so the model can warn users appropriately
RecentSightingsTool - searches the species catalog with an optional name filter
UserFavouritesTool - retrieves the user's saved parks and highlights so the agent can reference places they already know
EmitCardsTool - a special final-turn tool described in the next section

Tools are registered with the agent using AIFunctionFactory.Create() from the Microsoft.Agents.AI package:

public IList<AITool> BuildTools()
{
    return
    [
        AIFunctionFactory.Create(parkStatusTool.GetParkStatusAsync),
        AIFunctionFactory.Create(weatherTool.GetWeatherAsync),
        AIFunctionFactory.Create(recentSightingsTool.GetRecentSightingsAsync),
        AIFunctionFactory.Create(userFavouritesTool.GetUserFavouritesAsync),
        AIFunctionFactory.Create(emitCardsTool.EmitCardsAsync),
    ];
}

Each tool class is registered as a scoped dependency, so it gets a fresh instance per request with its own injected services.

Structured replies: cards

When the agent responds, it often references specific entities: a park it recommends, a species it identified, a trail it describes. The mobile app needs to render those as tappable UI elements that deep-link into the relevant screen, not just as text the user has to read and act on manually.

The mechanism for this is cards. A card is a typed entity reference: a type (park, highlight, species) and a GUID. The final CompanionMessageResponse carries both the message text and an array of cards that the app renders below the response.

public class CompanionMessageResponse
{
    public string Message { get; set; } = string.Empty;
    public List<CompanionCard> Cards { get; set; } = [];
}

public class CompanionCard
{
    public string Type { get; set; } = string.Empty;
    public Guid Id { get; set; }
}

The challenge is that language models can hallucinate. If you let the model emit card references without checking them against what it actually retrieved, it will sometimes reference parks or species it invented. We prevent that with an anti-hallucination check that tracks two sets of IDs per request.

Surfaced IDs are recorded by the data tools. When ParkStatusTool returns park and trail data, it records those IDs in the buffer. When RecentSightingsTool returns species, it records those. These are the entities the model actually saw in its context window.

Emitted IDs are recorded by EmitCardsTool, which the model calls at the end of its turn to declare which entities it wants to surface in the response.

public async Task<string> EmitCardsAsync(List<CompanionCard> cards)
{
    var validCards = cards
        .Where(c => validTypes.Contains(c.Type))
        .Where(c => c.Id != Guid.Empty)
        .ToList();

    cardBuffer.RecordEmitted(validCards);
    return "Cards emitted successfully.";
}

When the response is assembled, GetValidatedCards() returns only the intersection: entities that were both surfaced by a tool and claimed by the model. If the model tries to emit a card for an entity it never actually retrieved, it is silently dropped.

public IReadOnlyList<CompanionCard> GetValidatedCards()
{
    return emitted
        .Where(e => surfaced.Any(s => s.Type == e.Type && s.Id == e.Id))
        .ToList();
}

This approach means the card list in the response is always grounded in data the model actually had access to during that turn.

Streaming the response

Waiting for the full agent response before sending anything to the client produces noticeable latency. Instead, the endpoint streams tokens as they arrive using Server-Sent Events (SSE). The client receives text deltas immediately and renders them word by word, with the final structured data arriving at the end.

The controller sets up the SSE response and delegates to the service:

[HttpPost("threads/{threadId}/messages")]
[ProducesResponseType(StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status503ServiceUnavailable)]
public async Task<IActionResult> SendMessageAsync(
    [FromRoute] Guid threadId,
    [FromBody] SendCompanionMessageRequest request,
    CancellationToken cancellationToken)
{
    Response.Headers.ContentType = "text/event-stream";
    Response.Headers.CacheControl = "no-cache";
    Response.Headers.Connection = "keep-alive";

    try
    {
        await companionService.StreamMessageAsync(
            threadId, userId, request, Response.Body, cancellationToken);
        return new EmptyResult();
    }
    catch (CompanionUnavailableException)
    {
        return StatusCode(StatusCodes.Status503ServiceUnavailable);
    }
}

The service writes two kinds of SSE events to the response body. Text delta events arrive continuously as the model generates its response:

data: The Hoge Veluwe national park covers

data:  5,400 hectares of heathland and forest.

Once streaming completes and the card buffer has been validated, a final envelope event is written containing the complete message text and the card array:

data: __envelope__:{"message":"The Hoge Veluwe...","cards":[{"type":"park","id":"..."}]}

The mobile app accumulates the text deltas for live rendering, then on the envelope event it replaces the accumulated text with the canonical message and renders the card strip. This gives users the perception of a fast response while ensuring the final state is always consistent with the validated data.

The agent integration

All direct interaction with the Azure AI Foundry SDK is isolated in a single class: FoundryAgentClient. No other class in the application imports Microsoft.Agents.AI types. This keeps the rest of the codebase insulated from SDK changes and makes it straightforward to swap the underlying model provider if needed.

The client wraps a FoundryAgent instance that is built per-request by the DI container, with the scoped tool instances for that request injected at construction time:

services.AddScoped<FoundryAgent>(sp =>
{
    var projectClient = sp.GetRequiredService<AIProjectClient>();
    var options = sp.GetRequiredService<IOptions<CompanionOptions>>().Value;
    var toolFactory = sp.GetRequiredService<CompanionToolFactory>();

    return projectClient.GetFoundryAgentClient().GetAgent(
        options.AgentId,
        new FoundryAgentOptions { Tools = toolFactory.BuildTools() });
});

The agent holds the Foundry agent ID (configured at startup) and the tool list for this request. When RunStreamingAsync is called, it creates or resumes a Foundry conversation session, injects the per-request system instructions and the user message, then streams back AgentResponseUpdate events:

public async IAsyncEnumerable<string> RunStreamingAsync(
    string sessionId,
    string systemInstructions,
    string userMessage,
    [EnumeratorCancellation] CancellationToken cancellationToken)
{
    var session = await agent.CreateConversationSessionAsync(sessionId, cancellationToken);

    await session.SendSystemMessageAsync(systemInstructions, cancellationToken);
    await session.SendMessageAsync(userMessage, cancellationToken);

    await foreach (var update in session.RunStreamingAsync(cancellationToken))
    {
        if (update.Text is { Length: > 0 } text)
            yield return text;
    }
}

The system instructions are built fresh each request by CompanionContextBuilder, which formats the user's language preference, current coordinates, the park or highlight in view, and any safety warnings triggered by trail difficulty or weather severity. This context is never stored in Foundry; it travels as a system message on every turn so the model always has an accurate picture of where the user is and what they are looking at.

Putting it together

The full flow from a mobile app perspective is simple: send a POST with a message and optional context, read the SSE stream for text deltas, wait for the envelope event, render the cards. The complexity lives entirely on the server.

POST /api/v1/companion/threads/{threadId}/messages
Authorization: Bearer <user-jwt>

{
  "message": "Do you have a nice suggestion for a walk today?",
  "context": {
    "latitude": 52.0705,
    "longitude": 5.1214,
    "availableMinutes": 120
  }
}

On the server, that request creates or resumes a conversation session, enriches it with context, streams through the Foundry agent with live tool calls, validates the card buffer, and writes the SSE response. The mobile app gets a token stream it can render immediately and a final envelope it can trust.

The required configuration is minimal:

{
  "Companion": {
    "AzureAIProjectEndpoint": "https://<project>.services.ai.azure.com/api/projects/<project>",
    "AgentId": "<foundry-agent-name>"
  }
}

Authentication to Azure uses DefaultAzureCredential, so locally it picks up your Azure CLI login and in production it uses the managed identity assigned to the container app. No secrets in configuration files.

The pattern scales cleanly. Adding a new tool means implementing a scoped service, registering it in DI, and adding one line to BuildTools(). The card buffer picks it up automatically as long as the new tool records its surfaced IDs before returning. The rest of the pipeline does not change.

Using PostGIS with Azure Database for PostgreSQL

Sam Vanhoutte — Sat, 02 May 2026 09:04:56 +0000

With libelo we are building a platform for discovering parks and nature highlights. Almost all entities in our platform have a location attached: parks have boundaries, highlights like waterfalls or viewpoints have a precise coordinate, and users browse the app with their current position in hand. That means almost every interesting query the backend runs is spatial in some way. Which parks are nearby? Which park contains this highlight? What is the closest trail to where I am standing right now?

You could answer those questions by pulling coordinates out of the database and doing the math in application code. For a small dataset that works. The moment your dataset grows (people are adding new highlights every daily) and you want to filter and sort spatially at query time, you need the database to do that work. PostGIS is the extension that gives PostgreSQL exactly that capability, and it is available out of the box on Azure Database for PostgreSQL Flexible Server.

This post walks through how to enable it, how to wire it into a .NET application using Entity Framework Core and NetTopologySuite, and I'll use the auto-linking of highlights to parks as a concrete example.

What PostGIS gives you

PostGIS adds native geometry and geography column types to PostgreSQL, along with several hundred spatial functions that operate on them. The ones that matter most for an application like Libelo are:

ST_DWithin

Returns true if two geometries are within a given distance of each other. This is the workhorse for "find everything within X kilometers of this point."

SELECT name FROM parks
WHERE ST_DWithin(location, ST_SetSRID(ST_MakePoint(4.9041, 52.3676), 4326), 10000);
-- returns all parks within 10 km of Amsterdam city centre

ST_Distance

Calculates the exact distance between two geometries. You use this to order results by proximity.

SELECT name, ST_Distance(location, ST_SetSRID(ST_MakePoint(4.9041, 52.3676), 4326)) AS distance_m
FROM parks
ORDER BY distance_m;
-- returns all parks sorted by distance from a point, closest first

ST_Contains

Returns true if one geometry completely contains another. This is how you answer "is this highlight inside the boundaries of a given park?"

SELECT name FROM parks
WHERE ST_Contains(location::geometry, ST_SetSRID(ST_MakePoint(4.9180, 52.3542), 4326)::geometry);
-- returns the park whose boundary polygon contains the given coordinate

GiST indexes

A special index type that understands spatial data. Without a GiST index, every spatial query is a full table scan. Using such an index will make proximity queries on a table with millions of rows complete in milliseconds.

PostGIS also distinguishes between geometry and geography column types. Geometry works in a flat 2D plane and uses whatever units your coordinate system defines. Geography works on the surface of the Earth and always uses meters for distance calculations. For a platform such as libelo, where users are scattered across the globe, geography is the right choice because it stays accurate at large distances without requiring a projected coordinate system.

Every geometry or geography value in PostGIS is tagged with an SRID: a Spatial Reference ID that identifies which coordinate system the coordinates belong to. SRID 4326 refers to WGS 84, the coordinate system that GPS uses. It represents positions on the Earth's surface as latitude and longitude in decimal degrees, with the origin at the Greenwich meridian and the equator. When you store a point as (4.9041, 52.3676) with SRID 4326, PostGIS knows those numbers mean longitude 4.9041 and latitude 52.3676, and it can do correct Earth-surface calculations with them. Without the SRID tag, coordinates are just numbers and spatial functions have no frame of reference to work with. You will see 4326 appear in column type declarations, geometry constructors, and index definitions throughout this post. It is always doing the same job: telling PostGIS that the data is in the global GPS coordinate system.

Enabling PostGIS on Azure Database for PostgreSQL

On Azure Database for PostgreSQL Flexible Server, PostGIS is a pre-installed extension that you activate rather than install. Before you can use it, you need to allowlist it in the server configuration.

In the Azure Portal, navigate to your PostgreSQL Flexible Server, open the Server parameters blade, and search for azure.extensions. Add POSTGIS to the allowed list and save. This tells Azure that the extension is permitted to be loaded.

Once it is allowlisted, you enable it in your database with a single SQL statement:

CREATE EXTENSION IF NOT EXISTS postgis;

If you are using Flyway for migrations (as we do on Libelo), put this in your first migration file and it will run once on initial database setup:

-- V001__Enable_extensions.sql
CREATE EXTENSION IF NOT EXISTS postgis;

In case of using Entity Framework (which we do for now), you also declare the extension in your EF Core model so that tooling is aware of it:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.HasPostgresExtension("postgis");
    // ...
}

Setting up the .NET packages

NetTopologySuite is the .NET library that represents spatial types like Point, Polygon, and MultiPolygon. The Npgsql EF Core provider has a plugin that bridges between NetTopologySuite and PostGIS, translating LINQ expressions like IsWithinDistance into the correct PostGIS SQL functions.

Add the following packages to your infrastructure project:

<PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.0" />
<PackageReference Include="Npgsql.EntityFrameworkCore.PostgreSQL.NetTopologySuite" Version="10.0.0" />

Then enable the plugin when configuring the database connection:

options.UseNpgsql(connectionString, npgsql =>
    npgsql.UseNetTopologySuite());

That one call is what makes the translation layer work. Without it, EF Core has no idea that Point and MultiPolygon should map to PostGIS geography columns, and spatial LINQ methods will not translate to SQL.

Defining geometry columns

On Libelo, parks have boundaries and highlights have positions. These map to different geometry types.

A highlight is a single point: a specific waterfall, a peak, a cave entrance. The data entity stores it as a Point:

[Column("location", TypeName = "geography(Point, 4326)")]
public Point Location { get; set; } = null!;

A park is a boundary, and parks are not always simple single polygons. A national park can have non-contiguous sections separated by private land, or a coastal reserve can include several islands. See the screenshot of our app.
Using MultiPolygon handles that without needing special cases:

public MultiPolygon Location { get; set; } =
    new MultiPolygon(Array.Empty<Polygon>()) { SRID = 4326 };

The entity configurations register the column types and create GiST indexes:

// Park configuration
builder.Property(p => p.Location)
    .HasColumnType("geography(MultiPolygon, 4326)");

builder.HasIndex(p => p.Location)
    .HasMethod("gist");

// Highlight configuration
builder.Property(e => e.Location)
    .HasColumnType("geography(Point, 4326)")
    .IsRequired();

builder.HasIndex(e => e.Location)
    .HasMethod("gist");

The GiST index is not optional. PostGIS spatial queries can only use index-accelerated lookup when a GiST index exists on the column.

Auto-linking highlights to parks

When a user submits a new highlight through the app, they provide a coordinate. They do not define if the highlight is linked with a park. (we don't want users to do our data management, right?) The backend automatically determines which park that coordinate falls inside, and links the highlight to it. This is one of the places where PostGIS earns its place.

The containment check runs a PostGIS query that asks: does any park's boundary polygon contain this point?

public async Task<Park?> GetContainingPointAsync(
    Point location,
    CancellationToken cancellationToken = default)
{
    var entity = await context.Parks
        .AsNoTracking()
        .Where(p => p.DeletedAt == null)
        .Where(p => p.Location.IsWithinDistance(location, 0))
        .FirstOrDefaultAsync(cancellationToken);

    return entity == null ? null : MapToDomain(entity);
}

The IsWithinDistance(location, 0) call translates to ST_DWithin(location, @point, 0) in SQL. Using a distance of zero is the geography-safe way to test containment. PostGIS has a ST_Contains function, but it only works on the geometry type, not geography. Because our columns are geography for accurate Earth-surface distance calculations, ST_DWithin(..., 0) is the correct idiom: a point is "within zero meters" of a polygon only when it lies inside it.

In the service layer, this containment check plugs into the highlight creation flow. When a highlight is created without an explicit park ID, the service resolves the park automatically:

private async Task<Guid?> ResolveParkIdAsync(
    Guid? parkId,
    Location location,
    CancellationToken cancellationToken)
{
    if (parkId.HasValue)
        return parkId;

    var containingPark = await parkService.FindParkContainingLocationAsync(
        location.Latitude, location.Longitude, cancellationToken);

    if (containingPark == null)
        return null;

    logger.LogInformation(
        "Auto-linked highlight at ({Lat}, {Lon}) to park {ParkId} ({ParkName})",
        location.Latitude, location.Longitude,
        containingPark.Id, containingPark.Name);

    return containingPark.Id;
}

The result is that users never have to think about park assignment. They drop a pin on a waterfall inside a park, and the link is created in the database automatically. If the coordinate falls outside any park boundary (a highlight on a public trail that is not inside a mapped park, for example), the highlight is simply created without a park association.

Proximity queries

The other core use case is finding things near a location. When the app loads, it sends the user's current coordinates to the backend, and the API returns parks and highlights within a configurable radius, ordered by distance.

The query uses IsWithinDistance for the filter and Distance for the ordering:

var query = context.Parks
    .AsNoTracking()
    .Where(p => p.DeletedAt == null)
    .Where(p => p.Status == published)
    .Where(p => p.Location.IsWithinDistance(queryPoint, radiusMeters))
    .OrderBy(p => p.Location.Distance(queryPoint));

IsWithinDistance translates to ST_DWithin, which uses the GiST index and returns only rows within the specified radius before ordering. Without that filter, ORDER BY ST_Distance would scan the entire table to compute distances. The two-step pattern, filter with ST_DWithin then sort with ST_Distance, is the standard way to write efficient proximity queries in PostGIS.

The query point is constructed from the user's latitude and longitude with an explicit SRID:

var geometryFactory = new GeometryFactory(new PrecisionModel(), 4326);
var queryPoint = geometryFactory.CreatePoint(new Coordinate(longitude, latitude));

Note that NetTopologySuite follows the GIS convention of (x, y) which means (longitude, latitude), not (latitude, longitude). This is a common source of bugs when first working with the library.

What the database sees

If you connect to the database directly and inspect what is happening, the EF Core queries translate cleanly into PostGIS SQL. A nearby parks query looks like this:

SELECT p.*
FROM parks p
WHERE p.deleted_at IS NULL
  AND p.status = 'Published'
  AND ST_DWithin(p.location, ST_SetSRID(ST_MakePoint($1, $2), 4326), $3)
ORDER BY ST_Distance(p.location, ST_SetSRID(ST_MakePoint($1, $2), 4326));

And the containment check for auto-linking becomes:

SELECT p.*
FROM parks p
WHERE p.deleted_at IS NULL
  AND ST_DWithin(p.location, ST_SetSRID(ST_MakePoint($1, $2), 4326), 0)
LIMIT 1;

These are exactly the queries you would write by hand. The NetTopologySuite translation layer does not add overhead or generate surprising SQL.

Keeping it simple

The setup has a few moving pieces: enabling the extension on Azure, adding two NuGet packages, one line in the DbContext configuration, and geography column types with GiST indexes in the entity configurations. Beyond that, spatial queries in EF Core look like any other LINQ query. You do not need to drop down to raw SQL or manage spatial types manually.

The main thing to be aware of is the geography versus geometry distinction. Geography columns use spherical calculations and always measure distance in meters, which is what you want for a mapping application. If you use geometry columns instead, you lose that accuracy and distance calculations become coordinate-system-dependent. Stick with geography and SRID 4326 and the math stays correct regardless of where in the world your data is.

How to track API requests in Azure APIM to Table Storage

Sam Vanhoutte — Sat, 02 May 2026 08:19:19 +0000

When you run a mobile API (like us at libelo), you quickly reach a point where you want to understand how people are actually using it. Not just error counts or latency histograms, but the real detail: which operations are called, from which platform, with what location data, at what time. We log all requests with Azure Application Insights, but that is mostly for troubleshooting purposes and comes with sampling risks, and a retention window.

In our backend, I have added an extra option: write every incoming API request directly to Azure Table Storage, right from the APIM policy, in a fire-and-forget way. The cost is minimal, the data is ours to query whenever we like, and the extra latency added to your API responses is zero. And the most important thing is that we are storing this data for further analytics and platform usage insights.

This post walks through how to set it up.

Why Azure Table Storage

Table Storage gives you cheap, durable, schemaless rows with a partition and row key. That is all you need for an audit log. You can partition by date so that querying a single day is fast, you can set a retention policy to purge old data automatically, and you can query it directly from Azure Storage Explorer or export it to Power BI without any extra infrastructure.

The catch is that you need to give APIM a way to authenticate against the Table Storage endpoint. The cleanest option for write-only access from a policy is a Shared Access Signature (SAS) token stored as a Named Value. More on that below.

The send-one-way-request policy

APIM has a policy called send-one-way-request that issues an HTTP request and does not wait for a response before continuing. This is exactly what we want here. The client calling your API never experiences the round-trip to Table Storage, and the policy does not block the outbound flow.

You can place this policy in both the <outbound> section (after a successful response) and the <on-error> section (when the backend or the policy itself fails). Covering both sections means you get a complete picture of every request, regardless of outcome.

Step by step

Setting up Table Storage

First, you need a storage account and a table. Use an existing, if you have one. Otherwise, create a standard StorageV2 account with Standard_LRS redundancy in the same region as your APIM instance.

Inside the storage account, create a table. In the Azure Portal, navigate to your storage account, open the Tables blade, and click + Table. Give it a name like apirequests. That is the table name you will reference in the policy URL.

Generating the SAS token

APIM needs write access to insert new rows. Rather than giving it a full account key, you create a SAS token scoped to the table service with only the permissions it needs.

In the Azure Portal, navigate to your storage account and open the Shared access signature blade. Configure the following settings:

Allowed services: Table only
Allowed resource types: Object (this covers individual table entities)
Allowed permissions: Add (this is the only permission APIM needs to insert rows)
Expiry: Set this to something practical for your rotation cadence. One year is common for internal tooling, but make sure you have a process to rotate it before it expires.
Allowed protocols: HTTPS only

Click Generate SAS and connection string. Copy the value in the SAS token field. It starts with sv= and will look something like this:

sv=2022-11-02&ss=t&srt=o&sp=a&se=2026-12-31T00:00:00Z&st=2025-01-01T00:00:00Z&spr=https&sig=<signature>

You will use this value in the next step.

Storing the SAS token as a Named Value in APIM

APIM Named Values are the right place to store configuration that policies reference but that should not be hardcoded in the policy XML. They also support Key Vault references if you want to manage the secret lifecycle there.

In the Azure Portal, navigate to your APIM instance and open the Named values blade. Click + Add and fill in the following:

Name: tablestorage-sas
Display name: tablestorage-sas
Type: Secret
Value: the SAS token you generated above

Save it. The policy will reference this value as {{tablestorage-sas}}.

Creating a policy fragment

The tracking logic needs to run in two places: the <outbound> section fires after a successful response, and the <on-error> section fires when something goes wrong. Obviously, we don't want to duplicate the entire send-one-way-request block. APIM solves this with policy fragments: reusable snippets that you define once and reference by name from any policy.

The only structural difference between the success and error cases is the ErrorReason field. context.LastError?.Reason is safe to evaluate in both contexts. In the <outbound> path there is no last error, so it returns an empty string. That means the fragment body is identical for both cases, and you do not need any branching inside it.

In the Azure Portal, navigate to your APIM instance, open the APIs section, and click Policy fragments in the left menu. Click + Create and give the fragment the name track-api-request. Paste the following XML as the fragment body:

<fragment>
  <send-one-way-request mode="new" timeout="10">
    <set-url>https://<your-storage-account>.table.core.windows.net/apirequests?{{tablestorage-sas}}</set-url>
    <set-method>POST</set-method>
    <set-header name="Content-Type" exists-action="override">
        <value>application/json</value>
    </set-header>
    <set-header name="Accept" exists-action="override">
        <value>application/json;odata=nometadata</value>
    </set-header>
    <set-header name="x-ms-version" exists-action="override">
        <value>2019-02-02</value>
    </set-header>
    <set-body>
    @{
      var now = DateTime.UtcNow;
      var requestId = context.RequestId;
      var rowKey = (DateTime.MaxValue.Ticks - now.Ticks).ToString("D19")
                  + "_" + requestId;
      return new JObject(
          new JProperty("PartitionKey", now.ToString("yyyy-MM-dd")),
          new JProperty("RowKey", rowKey),
          new JProperty("Timestamp", now),
          new JProperty("OperationId", requestId),
          new JProperty("Operation", context.Operation.Name),
          new JProperty("Path", context.Request.Url.Path),
          new JProperty("Query", context.Request.Url.QueryString),
          new JProperty("UserId", context.Request.Headers.GetValueOrDefault("app-user-id","")),
          new JProperty("UserName", context.Request.Headers.GetValueOrDefault("app-user-name","")),
          new JProperty("Lat", context.Request.Headers.GetValueOrDefault("x-lat","")),
          new JProperty("Lon", context.Request.Headers.GetValueOrDefault("x-lon","")),
          new JProperty("Language", context.Request.Headers.GetValueOrDefault("Accept-Language","")),
          new JProperty("Platform", context.Request.Headers.GetValueOrDefault("x-platform","")),
          new JProperty("Status", context.Response?.StatusCode ?? 0),
          new JProperty("Ip", context.Request.IpAddress),
          new JProperty("ErrorReason", context.LastError?.Reason ?? "")
      ).ToString();
    }
    </set-body>
  </send-one-way-request>
</fragment>

A few things worth pointing out in the body expression.

The RowKey.

The row key is constructed by subtracting the current ticks from DateTime.MaxValue.Ticks and zero-padding the result to 19 digits, then appending the request ID. Table Storage sorts rows alphabetically within a partition, so this descending tick value means that when you open a day's partition in Storage Explorer or query it via the REST API, the most recent requests appear at the top. Without this trick you would have to sort results in the client.

The PartitionKey.

Using the date in yyyy-MM-dd format keeps each day's data in its own partition. Queries scoped to a single day will only scan that partition, which keeps them fast even when the table accumulates months of data.

The fields.

The policy captures the APIM operation name, the full path and query string, user identity fields that were extracted from the JWT earlier in the inbound policy, device location and platform headers sent by the client, the HTTP status code from the response, and the client IP address. The ErrorReason field is populated from context.LastError?.Reason, which returns an empty string on the success path and the actual failure reason on the error path.

The Accept header.

The value application/json;odata=nometadata tells the Table Storage REST API to return the minimal OData envelope. For a write operation this does not change the response, but it is good practice and avoids any surprises if you later add response handling.

The APIM policy

With the fragment in place, the policy itself becomes lightweight. Both sections reference the fragment by name using <include-fragment>, and APIM expands it at runtime:

<outbound>
    <base />
    <include-fragment fragment-id="track-api-request" />
</outbound>
<on-error>
    <base />
    <include-fragment fragment-id="track-api-request" />
</on-error>

This is the policy you attach at the API or product level. The fragment handles all the tracking logic, and any future change to what gets recorded only needs to happen in one place.

Deploying with Bicep

If you are managing your APIM configuration with Bicep (or azd), the policy fragment maps to a Microsoft.ApiManagement/service/policyFragments child resource. Define the fragment body as a variable, substitute the storage account name at deploy time, and declare the resource as a dependency of any API that uses it:

var trackApiRequestFragment = '''
<fragment>
  <send-one-way-request mode="new" timeout="10">
    <set-url>https://__STORAGE_ACCOUNT_NAME__.table.core.windows.net/apirequests?{{tablestorage-sas}}</set-url>
    ...
  </send-one-way-request>
</fragment>
'''

resource apimService 'Microsoft.ApiManagement/service@2023-05-01-preview' existing = {
  name: apiManagementName
}

resource trackApiRequestPolicyFragment 'Microsoft.ApiManagement/service/policyFragments@2023-05-01-preview' = {
  name: 'track-api-request'
  parent: apimService
  properties: {
    description: 'Tracks every API request to Table Storage in a fire-and-forget way'
    format: 'rawxml'
    value: replace(trackApiRequestFragment, '__STORAGE_ACCOUNT_NAME__', storageAccount.name)
  }
}

The main API policy then only needs the two <include-fragment> references, and the storage account name placeholder is resolved without touching the policy string itself. Storing the SAS token as a Named Value can be linked with an Azure KeyVault secret. The {{tablestorage-sas}} placeholder in the fragment simply needs to match the name of the Named Value you created in the portal.

What you end up with

Once this is running, every API request that passes through APIM writes a row to the apirequests table. You can open Azure Storage Explorer and browse by date partition, export a day's worth of data to CSV, or query directly via the Table Storage REST API. For more structured analysis you can connect the table to Power BI or Azure Data Factory.

The setup has been running in production on libelo without any noticeable overhead on API response times, and the cost for the storage itself is negligible at consumer app scale. It gives a lightweight, always-on audit trail that complements Application Insights rather than replacing it, and it is easy to extend by adding fields to the JSON body whenever you need to track something new.

The main thing to watch out for is the SAS token expiry. Set a calendar reminder to rotate it before the expiry date, or move the secret into Key Vault and reference it from the Named Value so that rotation becomes a Key Vault operation rather than a manual portal step.

And as a result we are now having a nice overview of the requests in our own platform:

Using the Options pattern with .NET Aspire

Sam Vanhoutte — Mon, 14 Apr 2025 06:58:16 +0000

When using .NET Aspire Hosted App, most samples use Environment Variables when configuring your services. However, when you are migrating existing services, the chance is that you are using the Options pattern for .NET Core.

So, I decided to write this post in order to share how I achieved this.

Using Environment variables

The default approach seems to be the following.

The AppHost

In the AppHost, you are just adding the service (or project, as they call it in Aspire) and you can pass environment variables to the services.

var builder = DistributedApplication.CreateBuilder(args);

builder
    .AddProject<MySolution_Service1>("worker")
    .WithEnvironment("config1", "value1")
    .WithEnvironment("config2", "value2");

await builder.Build().RunAsync();

The Service

In the Service project, you can easily access the environment variables, by using this code.

Console.WriteLine(Environment.GetEnvironmentVariable("config1"));

Or you can use the Configuration builder for it.

builder.Configuration.GetValue<string>("config1");

Using one centralized approach for Options pattern

In order to have the default AppSettings shared from the Hosting project, and made available with the Micro services projects, we define an appsettings.base.json file in the Hosting project and have that automatically copied to all the services that need it. Every service can then still define an appsettings.json file to override or add extra configuration items per service.

The actual file reference

Define a file appsettings.base.json in the Hosting project.
Update the services project(s) files to indicate files should be copied from the hosting project to the service project itself.

<Target Name="CopySharedAppSettings" AfterTargets="Build">
    <!-- Define the source files -->
    <ItemGroup>
        <SharedFiles Include="..\MyApp.Host\appsettings.base.json" />
    </ItemGroup>

    <!-- Copy files to the output directory -->
    <Copy SourceFiles="@(SharedFiles)" DestinationFolder="$(ProjectDir)" />
</Target>
<ItemGroup>
    <Content Update="appsettings.base.json">
        <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </Content>
</ItemGroup>

Injecting the IOptions

In .NET Aspire, runtime configuration is typically done, through the Service Defaults. In this project, we will be adding the configuration method to inject all the relevant (common) Options into the services. Obviously, this can also be done by performing this in the services project itself.

As you can see, we are first loading the base file, and after that, the overrides from the service specific file. And, as this mainly focuses on the dev/local experience (with the appsettings file), we also inject the Environment variables, so that we can also leverage the deployment configuration when deployed onto a cluster.

private static TBuilder ConfigureOptions<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
{
    var cfgBuilder = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory());

    cfgBuilder
        .AddJsonFile($"appsettings.base.json", true, true)
        .AddJsonFile($"appsettings.json", true, true)
        .AddEnvironmentVariables();

    var configuration = cfgBuilder.Build();

    builder.Services.Configure<SqlOptions>(configuration.GetSection("sql"));
    return builder;
}

And we are calling this method from the "main method" of the Service Defaults project:

public static TBuilder AddServiceDefaults<TBuilder>(this TBuilder builder) where TBuilder : IHostApplicationBuilder
    {
        builder.ConfigureOpenTelemetry();

        builder.ConfigureOptions();
        // ... skipped for brevity
        return builder;
    }

Putting Azure APIM in front of your Service Bus queue

Sam Vanhoutte — Thu, 27 Mar 2025 19:47:26 +0000

For a specific scenario, we wanted to expose a queuing endpoint towards a customer, in a secure way, but at the same time abstracting our internal usage of Azure Service Bus.

As we already had Azure API Management in place to expose our API, we decided to leverage this and see if we could avoid the typical scenario where we'd have to develop a strong typed custom API that then just takes the incoming request and maps it to a Service Bus message that should be be processed to the right endpoint.

And this post describes exactly how you can achieve this.

Azure API Management policy

The following abstract is the full policy that we configured. So, you could see this as the "tldr;" of this blog post. In the rest of the article, we'll dive deeper in the details and discuss what's behind everything.

<policies>
    <inbound>
        <base />
        <validate-content unspecified-content-type-action="detect" max-size="262144" size-exceeded-action="detect" errors-variable-name="schema-validation-error">
            <content type="application/json" validate-as="json" action="prevent" schema-id="OrderRequest" allow-additional-properties="false" />
        </validate-content>
        <trace source="Order create">Request validated</trace>
        <authentication-managed-identity resource="https://servicebus.azure.net" output-token-variable-name="sbBearerToken" ignore-error="false" />
        <set-header name="Authorization" exists-action="override">
            <value>@{return $"Bearer {(String)context.Variables["sbBearerToken"]}";}</value>
        </set-header>
        <set-backend-service base-url="https://{{serviceBusNamespaceFQDN}}" />
        <rewrite-uri template="/orders/messages?api-version=2015-01" />
        <set-header name="MessageType" exists-action="override">
            <value>Order</value>
        </set-header>
    </inbound>
    <backend>
        <retry condition="@(new List<int>() { 408, 429, 500, 502, 503, 504 }.Contains(context.Response.StatusCode))" count="2" interval="1" max-interval="10" delta="1">
            <forward-request buffer-request-body="true" />
        </retry>
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Set up the API operation contract

As we want to have a strong typed operation, enforcing the contract, we have to define both the actual operation (http resource) as well as the incoming payload schema first.

In the following screenshot, you can see we define the resource (POST /order). We also indicate that the operation expects an instance of the definition CreateOrderRequest in the request.

The schema itself is defined in the Definitions tab (at the bottom), where you can define the schema itself, or have the schema generated from a sample instance.

Enable security and access rights on Service Bus

In order to allow the API Management service to send messages to the Azure Service Bus endpoint, it is important to assign the correct permissions. We will do this by providing the Azure Service Bus Data Sender role to the System Identity of Azure API Management.

Please verify the System Assigned Identity is enabled on API Management, by navigating to the 'Managed Identities' tab.
Take note of the Object (principal) ID.
Navigate to your Service Bus namespace in the Azure portal
Assign the right permissions in Role Assignments, as shown in the next screenshot

The result should be looking like the following

In case you use a User Assigned managed identity, the client id of the role should be stored as it will be used in the APIM policy , to authenticate against the API of Servicebus (here: 60ec8160***). (If needed.

The XML policy explained

Validating the schema

As we're not having custom code, hosted in an API to perform validation, we have to fall back on the out of the box schema validation, provided by Azure API Management. This way, we will ensure only valid messages are delivered into our messaging backend. This comes with limitations as we are not returning a 404, in case the ArticleNumber does not exist, for example. So, those exceptions have to be handled asynchronously.

<validate-content unspecified-content-type-action="detect" max-size="262144" size-exceeded-action="detect" errors-variable-name="schema-validation-error">
    <content type="application/json" validate-as="json" action="prevent" schema-id="OrderRequest" allow-additional-properties="false" />
</validate-content>

When the request is not valid, an HTTP 400 (BadRequest) will be returned to the caller of the API. We also indicate

Add tracing

The next fragment, just adds a trace that will be integrated in the APIM trace and even a connected Application Insights instance.

<trace source="Order create">Request validated</trace>

Configure managed identity authentication

The authentication-managed-identity fragment, enables the authentication of the Azure APIM managed identity (system identity in our case) against the Azure Service Bus resource. A call to the Microsoft Entra ID happens and the result is being stored in the sbBearerToken variable, to be used in the next step.

<authentication-managed-identity resource="https://servicebus.azure.net" output-token-variable-name="sbBearerToken" ignore-error="false" />

Setting the Service Bus Authorization header

In this step, we are setting (and overriding, should it exist) the Authorization header on the outgoing HTTP call that will be made.

<set-header name="Authorization" exists-action="override">
    <value>@{return $"Bearer {(String)context.Variables["sbBearerToken "]}";}</value>
</set-header>

Configure the actual Service Bus entity url

Two steps are taken to define the actual entity url for the service call.

<set-backend-service base-url="https://{{serviceBusNamespaceFQDN}}" />
<rewrite-uri template="/orders/messages?api-version=2015-01" />

We are setting the base-url of the backend service to the https address of the service bus. (the {{serviceBusNamespaceFQDN}} value is retrieved from a namedvalue, as to configure this with the IaC pipelines.

After that, we are providing the name of the topic or queue to which we want to send the incoming message. (As per following document, the 2015-01 is still the latest version).

Adding custom message properties

If you want to add custom message properties, you can do so by adding HTTP headers with the correct name and value to the HTTP request.
This is what happens in the last snippet.

<set-header name="MessageType" exists-action="override">
    <value>Order</value>
</set-header>

Setting the retry policies

For certain HTTP status codes, we are indicating a retry policy to be used. This is certainly relevant for the 429 status code (throttling), but can also be enabled for the other ones.
This snippet is to be set on the backend node.

<retry condition="@(new List<int>() { 408, 429, 500, 502, 503, 504 }.Contains(context.Response.StatusCode))" count="2" interval="1" max-interval="10" delta="1">
    <forward-request buffer-request-body="true" />
</retry>

Testing

When testing the API call from the Azure API portal, we can clearly see the message appear on our subscription (linked to the Orders topic we were sending to). We can also see the MessageType custom property in the Service Bus explorer view.

Conclusions

This approach clearly helps in directly exposing a Service Bus entity, while still abstracting that as an implementation detail and maintaing some basic validation on the incoming request.

However, that validation is somewhat limited and lacks certain synchronous validation logic (even business logic) to be executed, which is what you typically would use a custom WebAPI project for (that then would forward the validated - or enriched - request to the Service Bus.)

Processing Time Series data in Azure: the options

Sam Vanhoutte — Mon, 24 Mar 2025 20:17:58 +0000

Time series data are data points that are collected or recorded at successive points in time. This type of data is becoming increasingly important in today's digital world as more systems, sensors, and applications generate continuous streams of information.
From IoT devices and financial markets to website analytics and industrial monitoring, time-stamped data enables organizations to detect trends, predict outcomes, and respond to changes in real time. As industries strive for smarter operations and faster decision-making, the ability to efficiently collect, store, and analyze time series data has become a critical capability for modern data solutions.

When working with several companies in different industries, I came across many different options and approaches to store time series data and that's why I decided to write this blog post series.

The different options in Microsoft Azure

There are several approaches and options to process and store timeseries data in Microsoft Azure, and this article will quickly list and touch upon them.

Some technologies will get a more detailed article later on.

What is Time Series data?

Time series data is a set of events. In messaging solutions, there are several types of messages that get exchanged between systems:

Messages: these are intents. A message can be a command, a query, a request. It implies something should happen and is expected.
Events: these are facts. An event just states something has happened and can be a measurement, a report or notification.

Time series falls under that second category. However, they are not discrete events (who are independent and actionable on their own).

Time series are order in time and are typically partitioned by a given context. (for example: MeterId , WebSiteVisitorId...). So one application will have multiple time series, typically. And these can be analysable on their own, or compared to each other.

The 4 components of Time Series data

There are four main components that make up time series data.

The trend: the long term direction of time series data
Cyclical effect: the larger fluctuations around the long term variation. Typically over longer periods than seasonality and without a fixed frequency.
Seasonality: the variations that occur and repeat over fixed time periods (every year, every Sunday, etc). One time series can have multiple frequencies of seasonality.
Residual effect (also referred to as noise). Unpredictable variations without a pattern that cannot be linked to the previous components.

Storing and processing Time Series in Azure

Several possibilities to store time series in Azure are listed below. Just know that this list is not exhaustive.

Azure Data Explorer

Azure Data Explorer (ADX, aka Kusto) is a fast and highly scalable data analytics service optimized for analyzing large volumes of structured, semi-structured, and unstructured data in near real-time. It is particularly well-suited for time series data, where high ingestion rates and quick querying over large datasets are critical. ADX supports time series-specific capabilities like automatic aggregation, downsampling, and time-based joins, making it ideal for monitoring trends, detecting anomalies, and visualizing data over time.
Its powerful Kusto Query Language (KQL) enables users to extract insights efficiently, even from billions of records. With native support for high-throughput ingestion pipelines and seamless integration with other Azure services, Azure Data Explorer provides a robust and scalable solution for managing and analyzing time series data.

Azure Fabric Realtime Analytics

Azure Fabric Real-Time Analytics is a service within Microsoft Fabric, which is an all-in-one analytics platform that combines data engineering, data warehousing, real-time analytics, and B.I. It is built on top of Kusto, the engine that powers ADX, so it inherits ADX’s strengths—fast ingestion, time series support, and the Kusto Query Language (KQL). However, it adds deeper integration with the broader Fabric ecosystem, like OneLake (a unified data lake), Power BI, and other collaborative and governance tools in Microsoft 365.
This also comes with a much different pricing model, which mostly means it's more expensive.

Azure Database for PostgreSQL with TimescaleDB

PostgreSQL is an open-source relational database known for its robustness, extensibility, and support for complex queries, making it a solid foundation for time series data management. When combined with TimescaleDB, a PostgreSQL extension specifically designed for time series workloads, its capabilities are significantly enhanced. TimescaleDB adds features like automatic partitioning (hypertables), time-based compression, and continuous aggregates, enabling PostgreSQL to efficiently store, query, and analyse massive volumes of time-stamped data.

Azure Database for PostgreSQL provides a fully managed database service, in which TimescaleDB can also be provided.

Azure managed instance for Appache Cassandra

Apache Cassandra is a highly scalable, distributed NoSQL database designed for handling large volumes of data across multiple nodes with high availability and no single point of failure. It is particularly well-suited for time series data due to its write-optimized architecture, horizontal scalability, and support for high-throughput operations. Cassandra's data model allows for efficient storage and retrieval of time-stamped records using techniques like wide rows and composite keys, making it a strong choice for time series applications where speed, scalability, and fault tolerance are critical.

Microsoft Azure allows to set up a managed instance of Appache Cassandra in your Azure subscription, so the actual management and setup of the cluster goes much faster, compared to setting up your own cluster in the environment.

Azure Timeseries Insights

This was a very easy to use service, but the service has been deprecated, in favour for Azure Fabric and Azure Data Explorer. But especially the Time Series Explorer was a very intuitive and interesting tool to explore and visualize time series data. You can see this in the screen shot below.

Consuming an Azure ML service from .NET

Sam Vanhoutte — Mon, 24 Mar 2025 10:40:03 +0000

For a project in the cycling community, I had to predict how long pro-riders would take to complete a certain race on the calendar. Different options, such as the parcours type, the distance and elevation obviously play a role in this.

So I used Azure Machine Learning to create an inference service that got deployed on Azure Compute Instance and that exposes an API for this.

In this post, I will explain how you can easily call the inference services of AzureML from dotnet, by passing strong typed objects to the inference method.

All of the code is available in the Open Sourced library: Aerozure.

Calling the scoring service from Postman

You can call the service that is hosted on the following url : https://..inference.ml.azure.com/score.
To authenticate, you have to pass in a Bearer token that you can retrieve from the Azure ML portal.

Calling the scoring endpoint can be done by posting a JSON that looks like the following. As you can see, it's a list of the column names, and their given values.

{
  "input_data": {
    "columns": [
      "month",
      "year",
      "distance",
      "elevation",
      "PointsScale",
      "UciScale",
      "ParcoursType",
      "ProfileScore",
      "RaceRanking",
      "StartlistQuality",
      "Classification",
      "Category"
    ],
    "index": [1],
    "data": [
        [2, 2025, 192, 1523, "2.PRO.Stage", "UCI.WR.Pro.Stage", 1, 22, null, 641, "2.Pro", "ME - Men Elite"]
    ]
  }
}

Streamline this call from csharp

The following code converts a strong typed dotnet class to the required input for the API.

Defining the request in csharp

The following class represents the actual data that is being sent to the API endpoint.

Inputdata.cs

using System.Text.Json.Serialization;
namespace Aerozure.Azureml;

public class InputData
{
    [JsonPropertyName("columns")]
    public string[] Columns { get; set; }

    [JsonPropertyName("index")]
    public int[] Index { get; set; }

    [JsonPropertyName("data")]
    public object[][] Data { get; set; }
}

The AzureML request

The AzuremlRequest will be used to serialize payload that is posted to the API and most importantly will convert the strong typed (PoCo) class to this request. For this, some basic Reflection is used to loop through all the properties of the object and take these properties and their values to the actual payload.

AzuremlRequest.cs

using System.Reflection;
using System.Text.Json.Serialization;

namespace Aerozure.Azureml;

public class AzuremlRequest
{
    [JsonPropertyName("input_data")] public InputData InputData { get; set; }

    public static AzuremlRequest Create(object payload)
    {
        var columns = new List<string>();
        var data = new List<object>();
        foreach (PropertyInfo property in payload.GetType().GetProperties())
        {
            columns.Add(property.Name);
            data.Add(property.GetValue(payload, null));
        }

        return new AzuremlRequest
        {
            InputData = new InputData
            {
                Columns = columns.ToArray(),
                Index = [1],
                Data = [data.ToArray()]
            }
        };
    }
}

The AzureML Inference client

The AzuremlClient class can be injected and expects the AzuremlOptions to be available on startup. Two properties are required there to be set (BearerToken and InferenceEndpoint).

AzuremlClient.cs

using System.Net.Http.Json;
using Aerozure.Configuration;
using Flurl.Http;
using Microsoft.Extensions.Options;

namespace Aerozure.Azureml;

public class AzuremlClient
{
    private readonly AzuremlOptions mlOptions;

    public AzuremlClient(IOptions<AzuremlOptions> mlOptions)
    {
        this.mlOptions = mlOptions.Value;
    }
    public async Task<T?> CallInferenceAsync<T>(object request)
    {
        var mlRequest = AzuremlRequest.Create(request);
        var response = await mlOptions.InferenceEndpoint
            .WithHeader("Authorization", $"Bearer {mlOptions.BearerToken}")
            .PostJsonAsync(mlRequest);
        return await response.ResponseMessage.Content.ReadFromJsonAsync<T>();
    }
}

Using the above code in your project

If you are using Aerozure, you can just enable the integration on startup in your Program.cs, by executing the following lines of code.

builder.Services
    .AddAerozure()
    .Configure<AzuremlOptions>(options => configuration.GetSection("azureml").Bind(options));

This will make the AzuremlClient available, configured for your endpoint with the right BearerToken.

Calling the inference endpoint, can be done by executing the following lines (here using the information on a given Race object).

var raceData = new RaceData
{
    month = race.Date!.Value.Month,
    year = race.Date!.Value.Year,
    distance = race.Distance,
    elevation = race.Elevation,
    race.PointsScale,
    race.UciScale,
    race.ParcoursType,
    race.ProfileScore,
    race.RaceRanking,
    race.StartlistQuality,
    race.Classification,
    race.Category
};
var result = await azuremlClient.CallInferenceAsync<double[]>(dataObject);
if (result != null)
{
    results.Add(race.Id, new RaceDurationPrediction
    {
        Distance = (int)race.Distance,
        Duration = result.First()
    });
}

Expose your Open API specs with Azure API management

Sam Vanhoutte — Mon, 25 Mar 2024 11:44:40 +0000

When deploying your API's to Azure API Management, you can have different logical API's that you want to have integrated by external applications or partners.

For this, the API Developer portal can be deployed, but this could be somewhat tedious. Another common approach is to expose the API's (only the ones you want to document publically!) specifications. The Open API endpoint (or the Swagger endpoint as it used to be called).

As documented in a previous post Deploy multiple APIs in Azure API management, hosted in the same App service, you can easily have multiple API's deployed to Azure API management.

This post explains how you can expose the Open API spec endpoint for a logical API in Azure API Management.

Enable the Service Reader Role

The Azure API management service instance should be able to read its own definitions, in order to build the API spec. For this, it is required we provide the Managed Identity of the Azure API management service with the API Management Service Reader Role.

This can be achieved with the following steps.

Enable managed identity

Navigate to Security > Managed Identities in the configuration of your API Management instance. Make sure the status is set to On.

Assign the required role

After that , click the Azure role assignments button.
Click Add role assignment (Preview) button
Select the resource group as scope, and search for the API Management Service Reader role`

Create the actual OpenAPI API definition

Create the operation

Create a new HTTP API (name: Swagger API) in Azure API management
Add an operation manually that will download the API specification, by using the path parameter api-id: /docs/{api-id}/openapi.

Retrieve the OpenAPI spec from the management API

The following snippet is needed (see explanation below)

<policies> <inbound> <base />  <send-request mode="new" response-variable-name="result" timeout="60" ignore-error="true"> <set-url>@("https://management.azure.com/subscriptions/#subscriptionid#/resourceGroups/#resource-group#/providers/Microsoft.ApiManagement/service/#resourceid#" + "/apis/" + context.Request.MatchedParameters.GetValueOrDefault("api-id","") + "?export=true&format=openapi&api-version=2021-01-01-preview")</set-url> <set-method>GET</set-method> <authentication-managed-identity resource="https://management.azure.com/" /> </send-request>  <return-response> <set-status code="200" reason="OK" /> <set-header name="Content-Type" exists-action="override"> <value>application/yaml</value> </set-header> <set-body>@((string)(((IResponse)context.Variables["result"]).Body.As<JObject>()["value"]))</set-body> </return-response> </inbound> <backend> <base /> </backend> <outbound> <base /> </outbound> <on-error> <base /> </on-error> </policies>

Warning! The pretty print of dev.to seems to be unable to cope with the complex instructions, so the structure seems to be messed up.

This is the policy you can set on the operation. With three replacements to make:

#subscriptionid#: the subscription id of the API management instance
#resource-group#: the resource group name of the API management instance
#resourceid#: the name of the API management instance.

Testing the solution

Just calling the API endpoint will now return the actual Open API spec as yaml. For this you need to provide the api-id value. This is the system name of the API in your instance. The field that is greyed out in the following screenshot:

Deploy multiple APIs in Azure API management, hosted in the same App service.

Sam Vanhoutte — Mon, 04 Mar 2024 19:00:40 +0000

We are building an API that contains several controllers with many operations. This API has to be consumed by different client applications.

Our own management portal
External integration companies
A mobile application

While we prefer to keep the code in the same ASP.NET Core Web API project (this is easy for many reasons, of which simplicity may be the biggest one), we don't want to expose every part of functionality to every client.

And this post is describing how we declare our API in such a way that we have multiple logical API specs that we then deploy in Azure API Management as different API's.

The WebAPI project

Enabling nswag in the build action

After creating the new ASP.NET Web API project, we can add the following NSwag packages to our project.

<PackageReference Include="NSwag.AspNetCore" Version="14.0.3" />
<PackageReference Include="NSwag.MSBuild" Version="14.0.3">

These packages will be used to decorate our operations and to generate the OpenAPI spec at build/deploy time.

We also add a build action to generate the open api spec in our deployment/api folder.

    <Target Name="NSwag" AfterTargets="PostBuildEvent" Condition=" '$(Docker)' != 'yes' ">
        <Exec WorkingDirectory="$(ProjectDir)" EnvironmentVariables="ASPNETCORE_ENVIRONMENT=Development;IS_NSWAG_BUILD=true;API_TITLE=Events_Backend_Api;INCLUDE_ALL_OPERATIONS=true" Command="$(NSwagExe_Net80) run nswag-client.json /variables:Configuration=$(Configuration),Output=backend-openapi.json" />
        <Exec WorkingDirectory="$(ProjectDir)" EnvironmentVariables="ASPNETCORE_ENVIRONMENT=Development;IS_NSWAG_BUILD=true;API_TITLE=Events_Public_Api;API_TYPE=Public" Command="$(NSwagExe_Net80) run nswag-spec.json /variables:Configuration=$(Configuration),Output=backend-public-openapi.json" />
    </Target>

When we build our project, the PostBuildEvent actions will be executed and the nswag will be used to use the nswag-spec.json configuration file to output the open-api as json to the configured output file. (/deployment/api in our case).

In the above configuration, we are generating two different api specs:

backend-openapi.json: we are passing INCLUDE_ALL_OPERATIONS=true as the argument to the nswag command.
backend-public-openapi.json: we are passing API_TYPE=Public as the argument to the nswag command.

In the next steps, I will show how these arguments are being used to filter out the correct operations in the open API spec generation.

Decorating the operations

In order to filter out the correct operations, I have created a custom Attribute that I can use on controllers and operations to indicate in which API output spec they should be included or not.

The custom attribute looks like this:

[AttributeUsage(AttributeTargets.All)]
public class ApiTypeAttribute : Attribute
{
    private readonly string? apiType;
    private readonly bool alwaysInclude;

    public ApiTypeAttribute(string? apiType = null, bool alwaysInclude = false)
    {
        this.apiType = apiType;
        this.alwaysInclude = alwaysInclude;
    }

    public string? ApiType => apiType;
    public bool AlwaysInclude => alwaysInclude;
}

This attribute can then be used and applied to operations and controllers, like in the following example:

using Events.WebAPI.Models;
using Events.WebAPI.Responses;
using Events.WebAPI.Runtime;
using Events.WebAPI.Services;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Options;
using NSwag.Annotations;

namespace Events.WebAPI.Controllers;

/// <summary>
/// API endpoint that exposes Events functionality
/// </summary>
[ApiController]
[Route("events")]
[ApiType(apiType: ApiTypes.Admin)]
public class EventController(EventsService eventsService): ControllerBase
{
    /// <summary>
    /// Get all events
    /// </summary>
    [HttpGet()]
    [ApiType(apiType: ApiTypes.Public)]
    [SwaggerResponse(StatusCodes.Status200OK, typeof(EventsResponse), Description = "The available events.")]
    public async Task<IActionResult> ListEvents()
    {
        var events = await eventsService.GetEventsAsync();
        return Ok(new EventsResponse(events.ToArray()));
    }

    /// <summary>
    /// Get all events
    /// </summary>
    [HttpPost()]
    [SwaggerResponse(StatusCodes.Status200OK, typeof(void), Description = "The event was created.")]
    public async Task<IActionResult> CreateEvent(Event @event)
    {
        await eventsService.CreateEventAsync(@event);
        return Ok();
    }
}

In the above controller, you can see that by default, the controller and its operations are considered to be part of the "Admin" API. But the ListEvents operation is decorated with the [ApiType(apiType: ApiTypes.Public)] attribute, indicating it's part of the public API as well.

In order to set this up, the Program.cs file contains the following logic, that is being called at the time of nswag-build.

builder.Services.AddOpenApiDocument(document => { GenerateOpenApiSpec(document, "v1"); });

void GenerateOpenApiSpec(AspNetCoreOpenApiDocumentGeneratorSettings nswagSettings, string documentName)
{
    string apiTitle = "Savanh Events API";

    bool includeAllOperations = false;
    string? apiType = null;

    if (!string.IsNullOrEmpty(builder.Configuration["API_TYPE"]))
    {
        apiType = builder.Configuration["API_TYPE"];
    }

    if (!string.IsNullOrEmpty(builder.Configuration["INCLUDE_ALL_OPERATIONS"]))
    {
        _ = bool.TryParse(builder.Configuration["INCLUDE_ALL_OPERATIONS"], out includeAllOperations);
    }

    if (!string.IsNullOrEmpty(builder.Configuration["API_TITLE"]))
    {
        apiTitle = builder.Configuration["API_TITLE"];
        apiTitle = apiTitle.Replace("_", " ");
    }

    Console.WriteLine($"Generating api doc : AllOperations: {includeAllOperations} // ApiType: {apiType}");
    nswagSettings.OperationProcessors.Add(new OpenApiSpecOperationProcessor(includeAllOperations, apiType));
    nswagSettings.DocumentName = documentName;
    nswagSettings.Title = apiTitle;
    nswagSettings.Version = Assembly.GetExecutingAssembly().GetName().Version?.ToString();
}

In the above code snippet, you can see that the input variables (API_TYPE, INCLUDE_ALL_OPERATIONS, API_TITLE) that are passed in the PostBuild action are being used to apply the behavior for the open API spec generation.

And there is an important line (nswagSettings.OperationProcessors.Add(new OpenApiSpecOperationProcessor(includeAllOperations, apiType));) that passed those configuration values to an OperationProcessor that will then filter out the operation or not. And that Processor is seen in the following snippet.

public class OpenApiSpecOperationProcessor : IOperationProcessor
{
    private readonly bool includeAllOperations;
    private readonly string? apiType;

    public OpenApiSpecOperationProcessor(bool includeAllOperations = false, string? apiType = null)
    {
        this.includeAllOperations = includeAllOperations;
        this.apiType = apiType;
    }

    // This method return a boolean, indicating to include the operation or not in the output
    public bool Process(OperationProcessorContext context)
    {
        if (includeAllOperations)
        {
            return true;
        }

        // Looking for the method or controller to have the ApiType attribute defined

        ApiTypeAttribute? attribute = null;
        if (context.MethodInfo.IsDefined(typeof(ApiTypeAttribute), true))
        {
            // First we check the method (deepest level), as that can override the controller
            attribute = (ApiTypeAttribute?)context.MethodInfo.GetCustomAttribute(typeof(ApiTypeAttribute));
        }
        else
        {
            // If no attribute on the method, we check the controller
            if (context.ControllerType.IsDefined(typeof(ApiTypeAttribute), true))
            {
                attribute = (ApiTypeAttribute?)context.ControllerType.GetCustomAttribute(typeof(ApiTypeAttribute));
            }
        }

        // Neither the method, nor the controller have the attribute
        // So we return false as it should not be included
        if (attribute == null)
        {
            return false;
        }

        // Since we found an attribute, we are now applying the logic where the method
        // will be included in the open api spec, when AlwaysInclude is on,
        // or when the ApiType matches the requested api type
        if (!string.IsNullOrEmpty(apiType))
        {
            var include = attribute.AlwaysInclude || apiType.Equals(attribute.ApiType, StringComparison.CurrentCultureIgnoreCase); 
            return include;
        }

        return attribute.AlwaysInclude;
    }
}

The result is now that, on every build of the WebAPI project, we will have the generated OpenAPI specs (swagger) stored in the corresponding output folder. (which is configured in nswag-spec.json)

Deploying the WebAPI to Azure API Management

This article leaves out the deployment logic to deploy the actual API as a Docker container and host it in an App Service. That would lead us too far and can be found in the github repo of this article.

We now just focus on importing the OpenAPI specs in Azure API Management as different API's.

This happens by leveraging the following bicep code.

Bicep modules

The following bicep modules can just be reused and then called from within your own project specific bicep file.

api-management-api.bicep

//Parameters
param environmentAcronym string
param locationAcronym string
param apiManagementName string
param serviceUrl string
param apiSpec string
param format string
param displayName string
param description string
param apiRevision string = '1'
param subscriptionRequired bool = true
param path string
param name string
param policy string
param policyFormat string = 'rawxml'
param namedValues array

// Apply naming conventions
var apiName = '${locationAcronym}-${environmentAcronym}-api-${name}'

// Get the existing APIM instance
resource apiManagement 'Microsoft.ApiManagement/service@2021-08-01' existing = {
  name: apiManagementName
}

// Define API resource
resource apiManagementApi 'Microsoft.ApiManagement/service/apis@2021-12-01-preview' = {
  parent: apiManagement
  name: apiName
  properties: {
    displayName: displayName
    description: description
    apiRevision: apiRevision
    subscriptionRequired: subscriptionRequired
    serviceUrl: serviceUrl
    path: path
    format: format
    value: apiSpec
    protocols: [
      'https'
    ]
    // Changing the subscription header name
    subscriptionKeyParameterNames: {
      header: 'x-subscription-key'
      query: 'x-subscription-key'
    }
    isCurrent: true
  }
  dependsOn: apiManagementNamedValues
}

// Specifying the policy on the API level
resource apiManagementapiPolicy 'Microsoft.ApiManagement/service/apis/policies@2021-12-01-preview' = {
  parent: apiManagementApi
  name: 'policy'
  properties: {
    value: policy
    format: policyFormat
  }
}

// Add named values
resource apiManagementNamedValues 'Microsoft.ApiManagement/service/namedValues@2021-08-01' = [for namedValue in namedValues: {
  parent: apiManagement
  name: '${namedValue.name}'
  properties: {
    displayName: namedValue.displayName
    value: namedValue.value
    secret: namedValue.isSecret
  }
}]

output apiName string = apiManagementApi.name
output basePath string = path

We can also deploy an API product for every seperate API. That module can be found below.

api-management-product.bicep

param name string
param apimName string
param displayName string
param description string
param subscriptionRequired bool = true
param apiNames array


resource product 'Microsoft.ApiManagement/service/products@2021-01-01-preview' = {
  name: '${apimName}/${name}'
  properties: {
    displayName: displayName
    description: description
    subscriptionRequired: subscriptionRequired
    state: 'published'
  }
  resource api 'apis@2021-01-01-preview' = [for apiName in apiNames: {
    name: apiName
  }]
}

And then we can call these modules from our main .bicep file, as can be seen in the following snippet:

// Deploy actual API
var apiManagementName = '${locationAcronym}-${environmentAcronym}-${companyName}-apim'

// deploy APIs to the API management instance
var backend_api_policy = '''
<policies>
    <inbound>
        <authentication-managed-identity resource="{0}" />
        <base />
    </inbound>
</policies>
'''

module backendApi 'modules/api-management-api.bicep' = {
  name: 'backendApi'
  scope: backendResourceGroup
  params: {
    locationAcronym: locationAcronym
    environmentAcronym: environmentAcronym
    apiManagementName: apiManagementName
    apiSpec: string(loadJsonContent('../api/backend-openapi.json'))
    format: 'openapi+json'
    path: 'backend/api/v1'
    // The following should typically be taken from output of the actual bicep module for App Service
    // But this sample is focusing on the API Management side of things
    serviceUrl: 'https://weu-dev-samvhintx-app-backend-api.azurewebsites.net/'
    displayName: 'SVH IntX API (${environmentAcronym})'
    description: 'The API that provides all required functionality on the ${environmentAcronym} environment.'
    name: '${environmentAcronym}-api-backend'
    policy: format(backend_api_policy, appServiceClientId)
    namedValues: [ ]
  }
}

module publicApi 'modules/api-management-api.bicep' = {
  name: 'publicApi'
  scope: backendResourceGroup
  params: {
    locationAcronym: locationAcronym
    environmentAcronym: environmentAcronym
    apiManagementName: apiManagementName
    apiSpec: string(loadJsonContent('../api/backend-public-openapi.json'))
    format: 'openapi+json'
    path: 'public/api/v1'
    // The following should typically be taken from output of the actual bicep module for App Service
    // But this sample is focusing on the API Management side of things
    serviceUrl: 'https://weu-dev-samvhintx-app-backend-api.azurewebsites.net/'
    displayName: 'SVH IntX Public API (${environmentAcronym})'
    description: 'The API that provides all required functionality on the ${environmentAcronym} environment.'
    name: '${environmentAcronym}-api-public'
    policy: format(backend_api_policy, appServiceClientId)
    namedValues: [ ]
  }
}

The result

After our successful deployment, this is the result in the API Management instance, where we have two different API products, each showing a different set of Operations.

This can be seen in the following screenshots.

*The "backend" API exposing two operations. *

The "public" API exposing just one operation.

As always, all code can be found online. Here.

Logic Apps deployment from Github with Powershell

Sam Vanhoutte — Wed, 28 Feb 2024 06:45:36 +0000

Context

I was working with a startup that is building software to predict time series in a specific industry. One of the big challenges for them is to integrate with systems of their customers.

While they offer an API that can be called by customers to ingest data into their tenant, some of those customers, require that startup to go and fetch the data from one of their systems. And yes, that smells like customer specific integration.

For that, we have set up several Logic Apps, that we isolate from the central part of the runtime. And this post describes how we have structured those Logic Apps, and how we automatically deploy them from our automated Github workflow.

Structure

As written above, the structure of the repo is in such a way that we have put all Logic Apps in a folder, called Integrations. And at deployment time, we automatically take those workflows from the folder, leveraging the names of the sub folders, to build the right resource name (ensuring our naming conventions). And those Logic Apps get deployed to a consumption Logic App.

Code

All code is available on https://github.com/SamVanhoutte/azure-logic-apps-deployment

Azure authentication

As with any other Github action, it is important to leverage the right credentials to authenticate against your Azure Subscription. For that, the following script has to be executed in the Azure CLI, and the resulting lines should be kept as a secret in your Github environment.

az ad sp create-for-rbac --name "github-deploy-dev" --role contributor --scopes /subscriptions/b73995e3-caad-4882-8644-f2175789c3ff --sdk-auth

The output looks like the following (which should be handled as a secret!).

{
  "clientId": "a8fa378b....",
  "clientSecret": "cOF8....",
  "subscriptionId": "b73995e3-caad-4882-8644-f2175789c3ff",
  "tenantId": "37e57300...."
}

Note: you can leave out the urls and just keep the first for relevant parts.

The output has been saved in my Github repo secret (with name AZURE_CREDENTIALS in the Development environment on my repo.

Github pipeline

To deploy our infrastructure, we default to Github workflows.

The result of our deployment pipeline is shown in the next screenshot:

The definition of the Github workflow can be easily found in the Github repo. But the most relevant sections have been copied here:

name: Deploy the Backend environment

on:
  workflow_call:
    inputs: 
    # Removed for brevity
jobs:
  Deploy-Azure-Backend-Resources:
    runs-on: ubuntu-latest
    if: always()
    environment: ${{ inputs.environment }}
    steps:
    # Log in to Azure
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: '${{ secrets.AZURE_CREDENTIALS }}'
        enable-AzPSSession: true
    # Removed for brevity
  Deploy-Integrations:
    runs-on: ubuntu-latest
    if: always()
    needs : [ Deploy-Azure-Backend-Resources ]
    environment: ${{ inputs.environment }}
    steps:
    - name: Azure Login
      uses: azure/login@v1
      with:
        creds: '${{ secrets.AZURE_CREDENTIALS }}'
        enable-AzPSSession: true
    - name: Download powershell files from pipeline artifact
      uses: actions/download-artifact@v3
      with:
        name: powershell
        path: ./artifacts/powershell
    - name: Download integration files
      uses: actions/download-artifact@v3
      with:
        name: integrations
        path: ./artifacts/integrations
    - name: Deploy integrations
      uses: azure/powershell@v1
      with:
        inlineScript: ./artifacts/powershell/deploy-logicapp-folder.ps1 -environmentAcronym ${{ inputs.environmentAcronym }} -location ${{ inputs.region }} -rootFolder './artifacts/integrations/'
        azPSVersion: "latest"

Some remarks about the above script:

enable-AzPSSession: true ensures our Powershell script will be running authenticated against our Azure Subscription.
We download the artifacts that we initially uploaded to the runtime storage. We do this for our powershell folder & our integrations folder that contains our Logic Apps definitions.
And in the last step, we are calling our Powershell script (that is explained in the next step) that will receive a reference to our integrations folder from our repo.

Powershell script

The following script takes the folder reference, walks the tree iteratively and deploys every Logic App definition to the corresponding resource group, applying the naming conventions, based on the folder structure.

param ($rootFolder, $location, $environmentAcronym)


Function Deploy-LogicAppDefinition($logicAppDefinitionFile, $location, $environmentAcronym, $locationAcronym)
{
    # This function takes a given workflow definition file 
    # and deploys it to the resource group 
    # (based on the folder, location & environment)
    # It will create or update the Logic App

    ### SET UP LOGIC APP NAME
    # Taking the file name and remove the folder
    $logicAppName = Split-Path $logicAppDefinitionFile -leaf

    # and remove the suffix to keep the logical name
    $logicAppName = $logicAppName.Replace('.definition.json', '')

    # and apply naming conventions
    $logicAppName = "$locationAcronym-$environmentAcronym-int-la-$logicAppName"

    ### SET UP RESOURCE GROUP NAME
    # Taking the directory name to which the json file belongs
    $logicAppType = Split-Path (Split-Path $logicAppDefinitionFile -Parent) -Leaf
    # and construct the resource group name
    $resourceGroupName = "$environmentAcronym-$locationAcronym-logapp-rg-int-$logicAppType"

    # Check if the resource group exists and create if not
    $existingRG = Get-AzResourceGroup -Name $resourceGroupName -ErrorAction SilentlyContinue
    if(-Not $existingRG)
    {
        Write-Host "Creating resource group $resourceGroupName"   
        New-AzResourceGroup -Name $resourceGroupName -Location 'West Europe' -Force
    }

    ### CRUD OF LOGIC APP DEFINITION
    # Check if logic app exists
    $existingLogicApp = Get-AzLogicApp -ResourceGroupName $resourceGroupName -Name $logicAppName -ErrorAction SilentlyContinue
    if($existingLogicApp)
    {
        Write-Host "Update logic app $logicAppName to resource group $resourceGroupName"   
        Set-AzLogicApp -ResourceGroupName $resourceGroupName -Name $logicAppName -DefinitionFilePath $logicAppDefinitionFile -Force
    }
    else 
    {
        Write-Host "Create logic app $logicAppName to resource group $resourceGroupName"
        New-AzLogicApp -ResourceGroupName $resourceGroupName -Name $logicAppName -Location $location -DefinitionFilePath $logicAppDefinitionFile
    }
}

# Apply location acronym, based on location
switch ($location)
{
    'westeurope' { $locationAcronym = 'weu'}
    'northeurope' { $locationAcronym = 'neu'}
    'westus' { $locationAcronym = 'wus'}
    default { $locationAcronym = 'weu'}
}

# Start of logic
# Search through all folders for files ending with definition.json
Get-ChildItem -Path $rootFolder -Recurse -Filter *.definition.json |
    ForEach-Object {
        Deploy-LogicAppDefinition $_.FullName $location $locationAcronym $environmentAcronym
    }

Conclusion

I believe it's crucial to apply naming conventions in every step of your deployment logic. So, here we have a way to structure our logic apps in our repo and have them deployed, just because the appear in our repo (we don't have to update the pipeline or script for every new workflow).

In another post, I will describe how a custom connector can be deployed and used in another Logic App.