DEV Community: Daniel Jonathan

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Daniel Jonathan — Sun, 03 May 2026 22:35:02 +0000

I spent the long weekend pushing Logic Apps MCP server capabilities further than I had before — and hit two bugs worth documenting. Both are filed. If you're building in this space, save yourself the debugging time.

Context

If you've been following along, the MCP server and BODMAS Agent are covered in the previous posts. This post is just about what broke when I wired them together.

Bug 1 — Intermittent duplicate key error at tool registration

What happens

The Agent Loop fails with a BadRequest before making a single MCP call:

HTTP request failed: 'An item with the same key has already been added. Key: {tool_name}'.

Both the tool names and the MCP server names are unique in the workflow definition — no duplicates anywhere in the JSON.

What makes it particularly frustrating to diagnose

It is intermittent. Some runs fail, others succeed with identical configuration and identical input. No changes between a failing and a succeeding run — same workflow, same expression, same everything.

Load test

I ran three test patterns across 60 total requests — all using expressions covering power, square root, and division.

Test	Requests	Succeeded	Failed	Failure Rate
Fully parallel	30	17	13	~43%
Pairs of 2 (10s gap)	20	14	6	~30%
Sequential (15s gap)	10	7	3	~30%
Total	60	38	22	~37%

Failure rate drops when concurrency is reduced but never goes away — even fully sequential calls at 15-second spacing still hit ~30%.

View from Dev Tools:

Resubmitting the failed runs from the portal confirms the intermittent nature — the same expression that failed goes through successfully after one or more resubmits, with no changes to the workflow or inputs.

What you can't do

The Agent action has a default retry policy, but it does not help here. A BadRequest (400) is not treated as a transient error — the retry policy targets server-side failures (5xx), not client errors. So even with retries configured, the duplicate key error causes an immediate terminal failure. There is no clean in-workflow workaround.

Bug 2 — MCP Connector does not support OAuth

What happens

Both the MCP server and the MCP client are Logic Apps Standard. When OAuth is configured on the MCP server side, the workflow doesn't trigger at all — it never reaches the Logic App. The connection gets corrupted at design time with the OAuth setup, and no run is created.

Tools don't load but you can save the workflow.

You get a 502 bad gateway error when you push a request.

The same endpoint called directly from Postman with a valid bearer token works fine.

Why it matters

To get the Agent Loop working, the MCP server has to run with either anonymous authentication or key-based authentication. OAuth simply does not work with the built-in MCP client connector.

Current state

Both issues are filed on the Logic Apps GitHub repo:

Agent Loop: "An item with the same key has already been added" when using McpClientTool

The issue covers both bugs with full workflow JSON, reproduction steps, and screenshots. If you've hit either of these, add a reaction or comment — the more signal on the issue, the better.

What works in the meantime

Set "type": "anonymous" in the McpServerEndpoints authentication block in host.json — removes the OAuth blocker for dev and demo use
Accept the intermittent failure rate on the Agent Loop and re-trigger manually when it hits — not a fix, but the success rate is high enough to keep building and testing

Both issues are filed. If you hit either of them, the GitHub issue is the right place to add signal.

Running Multiple MCP Servers with Azure Logic Apps

Daniel Jonathan — Fri, 01 May 2026 23:31:46 +0000

Model Context Protocol (MCP) has become the standard way to expose tools to AI agents.

With Azure Logic Apps, you can create and run multiple MCP servers and let an agent consume them together — cleanly and modularly.

In this post, we'll build:

A Basic Arithmetic MCP server
An Extended Arithmetic MCP server
And connect an agent to both

The Scenario

We'll create two MCP servers using Logic App workflows and expose them to an agent.
Both servers share Anonymous authentication.

Step 1 — Create and Group MCP Workflows in Logic Apps

Each operation is implemented as a Logic App workflow and exposed as an MCP tool.

Each workflow:

Accepts inputs (typically two numbers and an operation)
Executes the required logic
Returns a structured response

You then group these workflows into MCP servers:

Basic Arithmetic Server

Add
Subtract
Multiply
Divide

Extended Arithmetic Server

Power
Square Root
Modulo

How This Is Stored (mcpservers.json)

Once workflows are grouped into MCP servers, the configuration is automatically persisted in the mcpservers.json file.

This file contains:

MCP server definitions
Workflow (tool) mappings

💡 Key idea: What you define as MCP servers (grouped workflows) is what gets written to mcpservers.json — automatically.

MCP Server Endpoints

Once registered, each MCP server is reachable at a predictable URL following this pattern:

https://<your-logic-app>.azurewebsites.net/api/mcpservers/<ServerName>/mcp

For example:

Basic server → /api/mcpservers/BasicArithmetic/mcp
Extended server → /api/mcpservers/ExtendedArithmetic/mcp

💡 The server name in the URL matches exactly what you defined when grouping your workflows — no extra configuration needed.

Step 2 — Connect the Agent to Both Servers

The agent connects to both MCP servers using separate MCP client connections.

This allows the agent to:

Use basic operations from one server
Use advanced operations from another

👉 Clean separation — no need for a single large service.

Step 3 — Execution Result

When the agent runs, it invokes operations across both MCP servers.

The result:

Multiple MCP servers used seamlessly
Operations resolved correctly
Agent behaves as if using a unified toolset

Why This Matters

Running multiple MCP servers from a single Logic Apps instance gives you separation of concerns, modular extensibility, and independent scalability — without changing your agent design.

Key Takeaway

Workflows group into MCP servers, each exposed via a predictable endpoint
Configuration is automatically managed in mcpservers.json
Agents can connect to multiple MCP servers simultaneously — no extra wiring required

This pattern enables a modular, composable tool ecosystem for AI agents using Azure Logic Apps.

Logic Apps Local Dev Tools — Now with ACA and Azure Sign-in Support

Daniel Jonathan — Thu, 30 Apr 2026 08:16:14 +0000

The Logic Apps Local Dev Tools VS Code extension started as a local dev tool — connect to a Logic Apps container running via Docker and browse run history without leaving the editor.

This update adds two new connection types: ACA support via direct FQDN and Azure Sign-in for cloud-hosted Logic Apps Standard. If you used the original version for local Docker, everything still works — you just have more options now.

One dashboard, three connection types

The extension now supports three types of Logic Apps instances in a single panel:

Runtime — direct HTTP endpoint, works for local Docker (localhost:7074) or an ACA FQDN
AZ-LA — Azure Sign-in, connects to Logic Apps Standard via your subscription
EasyAuth — ACA endpoint secured with Azure AD ingress auth; the extension handles the Bearer token using a Service Principal

All instances appear side by side in the Logic Apps Instances view:

Managing connections

Click Connections to add, edit, or remove any instance. Each connection has a label, type, and endpoint or Azure resource identifier:

Runtime connections take a plain URL — ACA FQDN or localhost for Docker
AZ-LA connections use Azure Sign-in: select subscription, resource group, and Logic App — no endpoint URL needed
EasyAuth connections take the ACA FQDN plus a Service Principal (client ID + secret) — the extension acquires a Bearer token automatically on each request

EasyAuth — connecting to a protected ACA endpoint

If your Logic Apps container on ACA has Azure AD ingress auth enabled (unauthenticatedClientAction: Return401), the Runtime type won't work — requests without a Bearer token get a 401 before reaching the container.

Use EasyAuth instead: provide the ACA FQDN and a Service Principal with access to the app registration. The extension acquires a token via client credentials flow and attaches it to every request. SAS payload fetches (run history inputs/outputs) pass through the ACA platform exemption for /runtime/webhooks/* without needing a token.

When to use each type:

Scenario	Connection type
Local Docker (`localhost`)	Runtime
ACA container, no auth	Runtime
ACA container, ACA Easy Auth enabled	EasyAuth
Cloud Logic Apps Standard (App Service)	AZ-LA

ACA workflow view

Clicking View Workflows on an ACA instance shows the full workflow list with kind, status, health, and trigger. From here you can get the callback URL or jump straight into run history:

The run history panel works the same as local — full input/output per action, no Azure Portal needed.

Install from the VS Code Marketplace:
Logic Apps Local Dev Tools

For the original local dev walkthrough — Docker setup, Azurite, and the design → test loop:
Logic Apps Local Dev Tools — Visual Walkthrough

Host LogicApps as an MCP Server on Azure Container Apps

Daniel Jonathan — Thu, 30 Apr 2026 07:43:25 +0000

Run Logic Apps Standard as an MCP server in a Docker container on Azure Container Apps — then call it from another Logic App using the built-in MCP client connector inside an agent loop.

This post connects two earlier pieces:

MCP server setup: Logic Apps ❤️ MCP — Expose Arithmetic Tools — enabling the /api/mcp endpoint and testing the tools
Running on ACA: Logic Apps Standard on ACA — we take the same MCP server principles and host it as a Docker container on Azure Container Apps

If you haven't read those, here's what's already running before this post starts.

What's already deployed

Seven arithmetic workflows — add, sub, mul, div, mod, pow, sqrt — each an HTTP trigger workflow that takes inputs and returns a result. They're baked into a Docker image and running as a single container on ACA.

Running locally first

Before pushing to ACA you can run the same image locally. docker-compose up starts the Logic Apps runtime on port 7074 backed by Azurite for blob and queue storage. The MCP endpoint is immediately available at:

http://localhost:7074/api/mcp

No auth is needed locally — the "type": "anonymous" setting in host.json covers both local dev and the ACA demo deployment. This is the right place to verify tool schemas, test workflow logic, and confirm the runtime discovers all seven tools before you deploy anything to the cloud.

One block in host.json enables the MCP endpoint:

"workflow": {
  "McpServerEndpoints": {
    "enable": true,
    "authentication": { "type": "anonymous" }
  }
}

The runtime exposes each workflow as an MCP tool automatically. No extra code, no separate service — the container itself is the MCP server, reachable at:

https://la-arithmeticmcp.<env>.westeurope.azurecontainerapps.io/api/mcp

All seven tools are immediately discoverable:

Consuming it from another Logic App

A second Logic App — BODMASAgent — receives a math expression via HTTP and uses an Agent action (Azure OpenAI) to solve it. The agent has one tool available: the MCP server connector pointing at the endpoint above.

When you add the MCP server action inside the Agent loop and connect it to the endpoint, the designer auto-discovers all tools and lets you pick which ones the agent can call:

POST (2 + 3) * 4^2 / 2 and the agent works through BODMAS order on its own, calling one tool per step:

✅ Step 1: (2 + 3) = 5   → wf_arithmetic_add
✅ Step 2: 4² = 16        → wf_arithmetic_pow
✅ Step 3: 5 × 16 = 80    → wf_arithmetic_mul
✅ Step 4: 80 ÷ 2 = 40    → wf_arithmetic_div
✅ Final Answer: 40

No orchestration code in the consuming Logic App. The agent decides the order and arguments; each tool call triggers a real workflow run on the server container and returns the result.

Securing the MCP endpoint on ACA

The host.json above sets "type": "anonymous" — fine for local dev and demos, but for production you want the endpoint protected.

ACA doesn't have App Service Easy Auth built in, but it has its own ingress-level authentication that works the same way: the ACA runtime validates the Azure AD Bearer token before the request reaches the container. The Logic App MCP endpoint stays anonymous internally; ACA acts as the auth gateway.

Setup — two steps:

Create an Azure AD app registration (la-arithmeticmcp-auth) and create a service principal for it in the tenant:

az ad sp create --id <app-id>

Enable ACA auth via ARM REST — do not use az containerapp auth update, it has a known CLI bug that silently strips the first and last character of excludedPaths values, producing invalid config:

az rest --method PUT \
  --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/containerApps/la-arithmeticmcp/authConfigs/current?api-version=2024-03-01" \
  --body '{
    "properties": {
      "globalValidation": {
        "unauthenticatedClientAction": "Return401",
        "excludedPaths": ["/runtime/webhooks/workflow/scaleUnits/*"]
      },
      "platform": { "enabled": true },
      "identityProviders": {
        "azureActiveDirectory": {
          "registration": {
            "clientId": "<app-id>",
            "openIdIssuer": "https://sts.windows.net/<tenant-id>/"
          },
          "validation": {
            "allowedAudiences": ["api://<app-id>"]
          }
        }
      }
    }
  }'

The excludedPaths entry for scaleUnits/* is required. ACA enforces Bearer token validation on all paths by default — including /runtime/webhooks/*. The scaleUnits subtree hosts SAS-authenticated payload fetch URLs (run inputs/outputs) that the Logic Apps runtime generates per run action. Excluding it lets those requests pass through on SAS params alone.

Do not set WORKFLOWAPP_AAD_CLIENTID or WORKFLOWAPP_AAD_TENANTID on the container. These env vars activate DirectApi Azure AD token validation inside the Logic Apps runtime. Any client in EasyAuth mode sends a Bearer token on every request — including to the SAS-authenticated scaleUnits URLs. When both a Bearer token and SAS params are present on the same request, the runtime rejects with DirectApiRequestHasMoreThanOneAuthorization. ACA validates the Bearer token; the runtime validates the SAS params. They operate independently — don't configure them to overlap.

Getting a token (client credentials):

curl -X POST "https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=<app-id>" \
  --data-urlencode "client_secret=<secret>" \
  --data-urlencode "scope=api://<app-id>/.default"

Result:

# No token
HTTP 401  ← blocked by ACA ingress

# Valid Bearer token → initialize session
HTTP 200  {"protocolVersion":"2025-06-18","serverInfo":{"name":"Logic Apps Remote MCP Server",...}}

# Session established → tools/list
HTTP 200  {"tools":[{"name":"wf_arithmetic_div",...},{"name":"wf_arithmetic_add",...}]}

What ACA auth actually protects:

Path	Auth
`/api/mcp`	✅ Bearer token required
`/runtime/webhooks/workflow/api/management/*`	✅ Bearer token required
`/runtime/webhooks/workflow/scaleUnits/*`	❌ Excluded — SAS params only

The MCP client (Postman, Logic App connector, or any client) just needs to include Authorization: Bearer <token> on every request.

Validating with VS Code Copilot

VS Code Copilot can talk to any HTTP MCP server directly from the IDE. Add the secured endpoint to .vscode/mcp.json in your workspace:

{
  "servers": {
    "la-arithmeticmcp": {
      "type": "http",
      "url": "https://la-arithmeticmcp.<env>.westeurope.azurecontainerapps.io/api/mcp",
      "headers": {
        "Authorization": "Bearer <token>"
      }
    }
  }
}

On workspace open, Copilot sends initialize → tools/list and populates its tool list from the response. The screenshot below shows the result — all 7 arithmetic tools returned from the live ACA endpoint, confirming that the Bearer token clears ACA ingress and the MCP session handshake completes successfully end to end.

Running Azure Logic Apps Standard on Azure Container Apps

Daniel Jonathan — Wed, 29 Apr 2026 14:16:18 +0000

Should you use Logic Apps Standard on ACA instead of n8n?

n8n is popular for workflow automation — Docker-native, visual editor, hundreds of integrations. But if you're already in Azure, it means running and paying for another self-hosted service on top of your existing infrastructure.

Logic Apps Standard on ACA is a cost-effective alternative if your workflows stay within the built-in connector set: Azure Blob, Queue, Service Bus, Event Hubs, HTTP, OpenAI, AI Search. No extra services, no OAuth setup. Durable run history, GitOps-friendly JSON definitions, and event-driven triggers — all included at container economics instead of an always-on App Service plan.

Hard limits — know them before you start:

Not a supported scenario. This is not an officially supported deployment model. Microsoft support will not cover issues in this configuration — scaling and observability features are unavailable. Use for dev/test and experimentation only — production use is at your own risk.
No managed connectors. Gallery connectors (O365, SharePoint, SQL, etc.) require an App Service MSI endpoint that ACA doesn't provide.
No XSLT maps. The Transform XML action uses NetFxWorker.exe — a Windows-only .NET Framework binary that won't run on Linux. Liquid/JSON transforms work fine (they run in-process).
Rebuild to deploy. Workflows are baked into the image. Any change = Docker build + push + ACA update.
Visual designer needs local Docker. Design and test locally, then deploy.
Cold starts. Scale-to-zero means latency after idle — matters for synchronous HTTP workflows.

If any of those are blockers, use App Service Standard instead. If they're not — keep reading.

One thing that doesn't change moving to ACA: workflow state and run history are still backed by Azure Table Storage, the same as App Service. Durability is unchanged — the container is just the runtime host.

What we're building

Six workflows deployed as a single Docker container on ACA:

Workflow	Trigger	Purpose
wf1	HTTP GET	Stateful HTTP request/response
wf2	Azure Blob Storage	Fires on blob upload, reads metadata
wf3	Azure Queue Storage	Processes queue messages
wf4	Azure Service Bus	Processes messages from wf4queue
wf5	Azure Service Bus	Receives SB message, calls external HTTP endpoint
wf6	HTTP POST	JSON-to-JSON transform via Liquid map

The Docker image

No official pre-built image exists for Logic Apps Standard — you build your own with the Functions Core Tools and your workflow files baked in:

FROM mcr.microsoft.com/dotnet/sdk:8.0

ENV DEBIAN_FRONTEND=noninteractive
WORKDIR /home/site/wwwroot

RUN apt-get update && \
    apt-get install -y curl gnupg unzip coreutils && \
    curl -fsSL https://deb.nodesource.com/setup_18.x | bash - && \
    apt-get install -y nodejs && \
    npm install -g azure-functions-core-tools@4 --unsafe-perm=true && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

COPY . .

ENV FUNCTIONS_WORKER_RUNTIME="node"
ENV FUNCTIONS_WORKER_RUNTIME_VERSION="~4"
ENV AzureWebJobsFeatureFlags="EnableMultiLanguageWorker"
ENV AzureWebJobsSecretStorageType="Files"
ENV APP_KIND="workflowapp"

EXPOSE 7074
ENTRYPOINT ["func", "start", "--verbose", "--port", "7074"]

Workflow JSON files are baked in at COPY . .. The runtime reads and executes them — no compilation step.

Project structure

LABasicDemo/
├── host.json                  # Extension bundle declaration
├── connections.json           # Service provider connections
├── Dockerfile
├── Artifacts/Maps/            # Liquid maps (wf6)
├── wf1/workflow.json ... wf6/workflow.json

connections.json maps each connection name (e.g. servicebus) to a serviceProviderId and a connection string via @appsetting(...). The runtime resolves these at startup — no ARM roundtrip.

Bicep infrastructure

The sections below highlight the non-obvious parts. ACR, Log Analytics, and ACA Environment are standard boilerplate.

Service Bus — Basic SKU is enough

Basic SKU covers queues. Standard is only needed for topics or managed API connections — which don't work in ACA anyway.

The critical env vars — stability fixes

The Logic Apps runtime generates a 15-character LAIdentifier hash to namespace all Azure Table Storage tables for run history. By default the hash is derived from the host ID — if that changes on restart, run history appears lost.

Three env vars pin the identity across pod restarts:

{ name: 'AzureFunctionsWebHost__hostid', value: appName }
{ name: 'WEBSITE_HOSTNAME',              value: '${appName}.${acaEnv.properties.defaultDomain}' }
{ name: 'WEBSITE_CONTENTSHARE',          value: contentShareName }

Without AzureFunctionsWebHost__hostid, every restart generates a new host ID, a new LAIdentifier, new storage tables — and prior run history is effectively orphaned.

Azure Files mount — critical path

Mount at .azure-webjobs-hosts, not at /home/site/wwwroot. Mounting at the root wipes all workflow files baked into the image.

volumeMounts: [{ volumeName: 'content-share', mountPath: '/home/site/wwwroot/.azure-webjobs-hosts' }]

This directory holds blob trigger checkpoints and distributed locks — persisting it prevents replaying already-processed blobs after a restart.

Full env var list

env: [
  { name: 'AzureWebJobsStorage',                      secretRef: 'storage-connection-string' }
  { name: 'WORKFLOWS_STORAGE_CONNECTION_STRING',      secretRef: 'storage-connection-string' }
  { name: 'AzureBlob_connectionString',               secretRef: 'storage-connection-string' }
  { name: 'azurequeues_connectionString',              secretRef: 'storage-connection-string' }
  { name: 'servicebus_connectionString',              secretRef: 'servicebus-connection-string' }
  { name: 'FUNCTIONS_WORKER_RUNTIME',                 value: 'node' }
  { name: 'FUNCTIONS_WORKER_RUNTIME_VERSION',         value: '~4' }
  { name: 'AzureWebJobsFeatureFlags',                 value: 'EnableMultiLanguageWorker' }
  { name: 'APP_KIND',                                 value: 'workflowapp' }
  { name: 'WEBSITE_SITE_NAME',                        value: appName }
  { name: 'APPINSIGHTS_INSTRUMENTATIONKEY',           value: appInsightsKey }
  { name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', secretRef: 'storage-connection-string' }
  { name: 'WEBSITE_CONTENTSHARE',                     value: contentShareName }
  { name: 'WEBSITE_HOSTNAME',                         value: '${appName}.${acaEnv.properties.defaultDomain}' }
  { name: 'AzureFunctionsWebHost__hostid',            value: appName }
  { name: 'WEBSITE_RESOURCE_GROUP',                   value: resourceGroup().name }
  { name: 'WEBSITE_OWNER_NAME',                       value: '${subscription().subscriptionId}+${resourceGroup().name}-WestEuropewebspace' }
]

Deployment

deploy.sh — provision infrastructure

az deployment group create \
  --resource-group LogicAppHubRG \
  --template-file infra/main.bicep \
  --parameters infra/main.bicepparam \
  --output table

build-push.sh — build and deploy the image

ACA caches the image digest at revision creation time — deploying with :latest may leave the container on a stale image. Always pin the exact digest:

az acr build --registry labasicdemoacr --image logicapp-basicdemo:latest \
  --file ../LABasicDemo/Dockerfile ../LABasicDemo

DIGEST=$(az acr repository show-manifests --name labasicdemoacr \
  --repository logicapp-basicdemo --orderby time_desc --query "[0].digest" -o tsv)

az containerapp update --name la-basicdemo --resource-group LogicAppHubRG \
  --image "labasicdemoacr.azurecr.io/logicapp-basicdemo@$DIGEST"

az acr build runs the Docker build in the cloud — no local Docker daemon needed.

What lands in Azure

The Service Bus namespace and storage account live in a separate shared resource group.

Notable workflows

wf5 — Service Bus → HTTP action

wf5 originally used a managed API connection for Service Bus. It was redesigned to use the service provider connector (connection string auth) + a built-in HTTP action after managed connections proved unworkable. The service provider trigger polls wf5queue; on receipt it fires a GET to an external endpoint.

wf6 — Liquid JSON transform

Liquid maps work in Linux containers — processed in-process with no external binary. Map stored in Artifacts/Maps/PersonToContact.liquid:

{
  "fullName": "{{content.firstName}} {{content.lastName}}",
  "email": "{{content.email}}"
}

Action in workflow.json:

{
  "type": "Liquid",
  "kind": "JsonToJson",
  "inputs": {
    "content": "@triggerBody()",
    "map": { "source": "LogicApp", "name": "PersonToContact.liquid" }
  }
}

Test: POST {"firstName":"John","lastName":"Doe","email":"john@example.com"} → {"fullName":"John Doe","email":"john@example.com"}

Agentic flows work out of the box

One capability worth calling out explicitly: AI agent workflows are fully supported in ACA containers. Azure OpenAI and Azure AI Search are both built-in service provider connectors — they authenticate via API key in app settings, no ARM token required. This means you can build agentic patterns (LLM calls, RAG pipelines, tool-use loops) directly in Logic Apps Standard and deploy them to ACA with no additional setup.

This is a meaningful advantage over n8n, which relies on community nodes for OpenAI integration. Logic Apps gives you native stateful orchestration, durable run history per step, and retry policies — all built into the agent workflow without extra infrastructure.

The connector boundary

Logic Apps connectors come in two families:

Service provider connectors (built-in) — authenticate via connection strings, no ARM roundtrip. Work in containers:
Azure Blob, Azure Queue, Azure Service Bus, Azure Event Hubs, HTTP/HTTPS, Azure OpenAI, Azure AI Search.

Managed API connections (Microsoft.Web/connections) — the 400+ gallery connectors. Require an ARM token acquired via the App Service MSI endpoint (IDENTITY_ENDPOINT + IDENTITY_HEADER). App Service injects this automatically; ACA does not.

We tried two approaches: service principal via WORKFLOWAPP_AAD_CLIENTID / TENANTID / CLIENTSECRET, and user-assigned managed identity via AZURE_CLIENT_ID. Neither worked — the WORKFLOWAPP_AAD_* variables are only active in the Hybrid Deployment Model (Arc-enabled AKS + ACA Logic Apps extension), not the custom image approach.

XSLT maps also don't work: the Transform XML action delegates to NetFxWorker.exe — a Windows PE32 binary that the Linux kernel refuses to execute.

Feature	ACA (Linux)
Service provider connectors	✅
Liquid / JSON transforms	✅
Managed API connections	❌ No MSI endpoint
XSLT maps	❌ Windows-only binary

Verifying stability across restarts

The key test: trigger each workflow, stop and restart the container, then check that the same run IDs are still visible in history.

The easiest way to inspect run history is the Logic Apps Run History View Tool VS Code extension — connect it to the deployed ACA endpoint and browse runs per workflow directly in the editor, with full input/output per action visible.

Before the AzureFunctionsWebHost__hostid fix, run history was orphaned on every restart. After the fix it survives indefinitely.

Cost comparison vs n8n

	n8n (self-hosted)	Logic Apps Standard on ACA
Compute	Fixed VM/container cost	Serverless, scale to 0
State storage	SQLite / Postgres	Azure Table Storage (~pennies)
Built-in connectors	400+ community nodes	Service providers + HTTP
Managed connectors (O365 etc.)	✅	❌ App Service only
XSLT maps	✅	❌ Windows only
Liquid transforms	✅	✅
Run history	Basic	Full input/output per action
Visual designer	✅	✅ VS Code (local)
GitOps / IaC	Manual	Native JSON + Bicep

Sweet spot: Azure-native event-driven pipelines — blob, queue, Service Bus, outbound HTTP — where you want durable run history and GitOps deployment without an always-on App Service plan.

What's next

For local development — running the same container with Docker, Azurite, and the Logic Apps VS Code extension — see:

Logic Apps Local Dev Tools — Visual Walkthrough

That post covers the full design → test → deploy loop without repeating what's here.

Event Debouncing with Logic Apps and Azure Table Storage

Daniel Jonathan — Mon, 20 Apr 2026 17:58:35 +0000

Forwarding every webhook event directly to a downstream API is a recipe for throttling and duplicate processing. This post walks through how to fix that with three Logic Apps and one Azure Table Storage table.

Debouncing is a term from frontend development — wait for the noise to stop, then act once.

In integration, this pattern is better described as event buffering with deduplication: absorb bursts, collapse repeated updates per entity, and process only the final state.

In this implementation, Azure Table Storage is not the source of truth — it acts as a deduplication index. We store only the entity ID, and at processing time we re-fetch the authoritative state from the source system before calling downstream APIs.

The Problem

Source systems fire event bursts — hundreds of events at once during bulk imports, and multiple rapid updates for the same entity. You don't need to process every intermediate state — only the final one per entity.

A burst of 200 events may touch 50 entities, each updated multiple times. Every entity should be processed once, with its latest state — and the downstream API called once per entity.

The Pattern

Source System Webhook
        │
        ▼
  rcv-events  (HTTP trigger)
        │  upsert each event → EventBuffer table
        ▼
  Azure Table Storage: EventBuffer
        │  PartitionKey: "relation-events"  RowKey: entityId  Status: "Pending"
        ▼
  prc-events  (Timer: every 5 min)
        │  query Pending rows older than X min → dispatch each
        ▼
  prc-process-single-event
        │  mark Processing → fetch fresh from source → call downstream
        │  delete on success  /  reset to Pending on failure
        ▼
  Downstream API

Step 1 — Receive

rcv-events accepts a batch of events via HTTP and upserts each one into the buffer table. No queue, no broker — the HTTP trigger is the ingress.

Each row looks like this:

{
  "PartitionKey": "relation-events",
  "RowKey": "<entityId>",
  "Event": "updated",
  "EntityType": "Record",
  "Status": "Pending",
  "ReceivedAt": "2026-04-20T14:30:00Z"
}

RowKey = entityId is the key insight. No matter how many events arrive for the same entity, there is always exactly one row. The tenth update overwrites the ninth. Deduplication is a schema decision, not code.

Step 2 — Wait

prc-events runs on a timer (every 5 minutes) and queries rows where Status eq 'Pending' and LastUpdated <= utcNow() - X minutes. The time window is your debounce threshold — nothing gets processed until the burst settles.

Step 3 — Process

For each pending row, prc-process-single-event:

Marks the row Processing — prevents double-processing if the timer fires again mid-run
Fetches the current state from the source system — never trusts the buffered payload, which may already be stale
Calls the downstream API with fresh data
Deletes the row on success / resets to Pending on failure

This gives at-least-once delivery with automatic retry — no custom infrastructure needed.

Status Lifecycle

Pending  →  Processing  →  [deleted]
                 │
                 └──(on failure)──→  Pending

Three states, one field. Fully visible in Azure Storage Explorer during an incident.

Why It Works

Deduplication for free — one row per entity, always the latest
No ordering concerns — you fetch fresh data at processing time, so intermediate states are irrelevant
Respects downstream rate limits — 20 updates in 30 minutes still results in one API call to the downstream system
Parallel processing — prc-events fans out each pending row as an independent call, so entities are processed concurrently with isolated retry state
Operationally transparent — query the table, see exactly what's pending or stuck
No broker needed at low-to-moderate scale — if your HTTP trigger can handle the inbound burst and your timer cadence keeps up with the queue depth, you don't need Service Bus

Consider adding Service Bus only if you need strict ordering, dead-lettering, or multiple consumers on the same stream.

When Not to Use This Pattern

Avoid it when you need strict event ordering, every event preserved independently, near-real-time latency, multiple consumers, or very high throughput. In those cases, reach for Service Bus or Event Hubs instead.

No Service Bus. No custom retry logic. No ordering guarantees needed. Just a table, a timer, and one row per entity.

Debugging XSLT vs Liquid in VS Code

Daniel Jonathan — Fri, 03 Apr 2026 09:39:35 +0000

Both the XSLT Debugger and DotLiquid Debugger let you step through a template and inspect variables. But they work differently under the hood — and those differences affect what you can do while debugging.

The Fundamental Difference

XSLT debugging is live. The XSLT Debugger supports two engines, each with its own instrumentation strategy:

Saxon (XSLT 2.0/3.0) — exposes a TraceListener interface with Enter and Leave callbacks that fire as each instruction executes. The engine cooperates natively.
.NET XslCompiledTransform (XSLT 1.0) — has no TraceListener, so the debugger rewrites the stylesheet at load time, injecting <dbg:probe> extension calls into every template, if, for-each, and when block. A registered extension object handles each probe and pauses execution on a TaskCompletionSource until you click Step.

Both approaches genuinely pause execution. You're inspecting a running process.

Liquid debugging is replay. DotLiquid has no such API — Template.Render() runs the whole template and returns. The extension records a trace during that render, then lets you step through the recording. By the time you click Step, the template has already finished.

Capability Comparison

	XSLT Debugger	DotLiquid Debugger
Step model	Live pause/resume	Trace replay
Breakpoints	Yes — set and hit mid-execution	No
Backward stepping	No	Always — it's just a recording
Variable state	Live, from the running engine	Recorded snapshot at each step
Modify and continue	No	No — edit and re-render
Conditional breakpoints	No	No
Filter chain tracing	N/A	Yes — each filter is a step
Branch visibility	Taken branch only	Taken branch only
Re-render cost	Steps are free (engine is paused)	One render upfront, steps are free after

What This Looks Like in Practice

Setting a breakpoint:
In the XSLT debugger you can set a breakpoint on a specific <xsl:template> or <xsl:for-each>, hit F5, and the debugger stops there — even if that template fires 50 iterations in. You never see the first 49.

In the DotLiquid debugger there are no breakpoints. You start at step 1 and click forward. For a template with many iterations you can drag the step slider to jump ahead quickly, but you can't say "stop when item.qty > 10".

Backward stepping:
The DotLiquid debugger supports backward stepping — you're just moving a cursor through a recording. The XSLT Debugger does not support step back.

Modifying state:
Neither debugger supports modify-and-continue. In both cases you edit the template or input and re-render from scratch.

Filter chain tracing:
This is where the DotLiquid debugger has an advantage. Because every filter application is recorded as a separate step, you can step through name | Upcase | Truncate: 10 | Append: "…" and see the value after each filter. XSLT doesn't have filter chains — XPath functions are composed inline and there's no equivalent granularity.

Why the Difference Exists

Both XSLT engines provide a path to genuine pause/resume — either through a native TraceListener (Saxon) or through stylesheet rewriting at load time (.NET XSLT 1.0). The key is that XSLT execution is structured: templates fire, instructions execute in sequence, and there are clear entry/exit points to hook into.

DotLiquid was designed as a simple, safe rendering library. It has no extension points for interrupting execution, and its render loop is a single synchronous call with no observable mid-execution state. The replay approach is the only option available without forking the engine.

Which Should You Use?

If you're debugging XSLT maps — especially complex structural transformations, apply-templates logic, or recursive templates — the live debugger is significantly more powerful. Breakpoints and live state make it practical to debug templates that are hundreds of lines long. Use the compiled engine for XSLT 1.0 (including inline C#); use Saxon for XSLT 2.0/3.0. The full series is covered in XSLT Debugging in Logic Apps.

If you're debugging Liquid maps — filter results, conditional branches, loop variable values — the replay model covers the common cases well. The main limitation is the absence of breakpoints; for most Liquid templates this is a minor inconvenience rather than a real blocker. For a deeper look at Liquid templates and the debugger extension, see DotLiquid Debugging in Logic Apps.

Debug DotLiquid Templates Locally with the VS Code DotLiquid Debugger

Daniel Jonathan — Fri, 03 Apr 2026 09:38:12 +0000

The Problem We Are Solving

Shopify’s Liquid preview is useful, but Logic Apps Standard runs DotLiquid, not Shopify Liquid.
That means behavior can differ, so a template that looks correct in Shopify preview can still fail in Logic Apps.

The default Logic App testing loop is slow: update template, execute, wait, inspect run history, repeat.
For real B2B transforms, that guesswork is costly.

This post shows how to debug DotLiquid locally in VS Code with fast feedback and runtime-accurate results.

The Core Idea: Local Preview with the Exact Same Engine

The DotLiquid Debugger VS Code extension runs your templates locally, using the exact same DotLiquid 2.0.361 engine that Azure Logic Apps Standard uses in production.

This is the critical part: it uses the exact same engine — not a simulation.

Not a compatible implementation. The same NuGet package, the same version, the same sentence-cased filters, the same content wrapping behaviour, the same integer division quirks.

If it works here, your DotLiquid behavior should match Logic Apps closely, with far fewer deployment surprises.

How It Works Under the Hood

At a high level, the extension is a thin VS Code UI over a real .NET renderer.

VS Code Extension (TypeScript)
  ├─ WebView panel (preview UI)
  ├─ Auto-refresh on save / keystroke
  └─ LiquidBackend ──► DotLiquidRenderer.dll (.NET 8)
                             NDJSON over stdin/stdout

The .NET renderer is a long-running subprocess (kept alive for performance). It is compiled from source on first use and then kept alive for the session — so after the first warm-up, renders are nearly instant.

Communication uses NDJSON (one JSON request per line, one response per line) with id-paired responses, so the TypeScript side can handle concurrent requests without blocking.

What You Actually Get

1. Live Preview

Open any .liquid file and press Ctrl+Shift+L (or Cmd+Shift+L on macOS). A preview panel opens beside the editor showing the rendered output in real time.

The extension auto-refreshes on every save (or on every keystroke, debounced). The round-trip from editing to seeing the output is under 100ms for most templates. You still run after each change, but it happens locally and near-instantly instead of waiting on a Logic App execution.

This alone removes the biggest bottleneck in Liquid development.

Input data comes from a paired .liquid.json file in the same folder:

sales-order-transform.liquid
sales-order-transform.liquid.json   ← edit this with your test data

If the input file doesn't exist, a banner offers to create a sample file for you.

2. Step Debugger

This is where everything changes.

Click the Debug button in the preview toolbar. The template replays step by step — every assign, loop iteration, if/elsif/else, and output chunk gets its own step.

At each step:

The source line is highlighted in the editor
The Variables panel shows every variable and its current value
Variables not yet assigned are dimmed, so you see exactly what exists at this point in execution

Use the slider or Prev/Next buttons to navigate. Jump to the first or last step with |◀ and ▶|.

You can finally see why a value is wrong — not just that it is wrong.

This turns "why is this variable wrong?" from a guessing game into a one-minute diagnosis.

3. Filter Chain Tracing

Every assign step that uses filters shows the full chain below the debug bar:

499.9 | Times:5 → 2499.5 | DividedBy:100 → 24.995 | Round:2 → 25.0

31 filters are covered: all the math filters (Times, DividedBy, Plus, Minus, Modulo, Round, Ceil, Floor, Abs, AtLeast, AtMost), string filters (Upcase, Downcase, Capitalize, Append, Prepend, Strip, Replace, Truncate, etc.), and array filters (Split, Join, First, Last, Sort, Map, Reverse, Size).

This is something you simply cannot do in Azure Logic Apps.

Most calculation bugs live in filter chains — this feature isolates them instantly.

This is especially useful when a chain of four or five filters produces an unexpected result — you can see exactly where the value diverged.

4. Condition Evaluation

if, elsif, else, unless, and when steps show the condition that was evaluated and a ✓ taken indicator if the branch was taken:

? if: content.priority == "HIGH"   ✓ taken

Un-taken branches produce no step at all — which matches DotLiquid's execution model exactly.

This makes it obvious why a branch did or did not execute.

5. Variable Panel and Line Map

The Variables panel lists every assign value with the line number where it was last set. Click any row to jump to that line in the source.

The Line Map links every output chunk back to the template line that produced it. Click any output region to jump to the source line. This is especially useful for templates that produce XML or JSON — you can click "grandTotal": 336.20 in the output and jump straight to the line that calculated it.

Both panels collapse independently. When one collapses, the other expands to fill the full sidebar height.

Together, these eliminate the need for "temporary debug output" hacks.

6. Output Formats: JSON, XML, HTML, Plain Text

Because the extension renders raw text output, it works equally well for all four output formats Logic Apps supports:

Template	Output
`invoice-flat.liquid`	Flat JSON for downstream API
`sales-order-transform.liquid`	Complex JSON with B2B calculations
`order-to-xml.liquid`	XML for EDI / ERP integration
`customer-to-xml.liquid`	XML ERP customer import
`email-notification.liquid`	HTML order confirmation email
`shipping-label.liquid`	Plain text packing slip

Getting Started

Setup takes under 2 minutes.

Requirements

VS Code 1.85 or later
.NET 8 SDK (download)

Verify .NET:

dotnet --version   # should print 8.x.x or later

Install

Install from the VS Code Marketplace:

code --install-extension danieljonathan.dotliquid-template-debugger

Or download the latest .vsix from github.com/imdj360/VSCodeDotLiquidDebugger and install it:

code --install-extension ./dotliquid-template-debugger-0.5.0.vsix

You can also search DotLiquid Template Debugger for Logic Apps in the VS Code Extensions panel.

Your First Preview

Create a file hello.liquid:

{%- assign name = content.name -%}
{%- assign items = content.items -%}
{%- assign total = 0 -%}
{%- for item in items -%}
  {%- assign total = total | Plus: item.price -%}
{%- endfor -%}
{
  "greeting": "Hello, {{ name }}!",
  "itemCount": {{ items | Size }},
  "total": {{ total | Round: 2 }}
}

Create hello.liquid.json in the same folder:

{
  "name": "World",
  "items": [
    { "price": 9.99 },
    { "price": 14.50 },
    { "price": 4.00 }
  ]
}

Press Ctrl+Shift+L to open the preview. You should see:

{
  "greeting": "Hello, World!",
  "itemCount": 3,
  "total": 28.49
}

At this point, each change can be validated with a quick local run instead of rerunning the Logic App each iteration.

Press Debug and step through to watch total accumulate across the loop.

The F5 Launch Config Workflow

For a proper development workflow — especially when working with multiple templates — add a type: "dotliquid" launch configuration to your .vscode/launch.json:

{
  "type": "dotliquid",
  "request": "launch",
  "name": "My: sales-order-transform",
  "template": "${workspaceFolder}/templates/sales-order-transform.liquid"
}

Now press F5 from the Run and Debug panel. The extension:

Opens the template in the editor
Auto-detects the paired .liquid.json input
Opens the preview panel

No manual reload. No "Developer: Reload Window". Just F5.

This is the closest thing to a real development experience for Liquid templates.

The input field can be provided in launch config, but current preview execution reads the paired <template>.liquid.json file.

Sample Templates

Seven ready-to-use sample templates covering all output formats are available in a companion repository. Clone it and open it in VS Code:

GitHub: Xslt-Liquid-DebuggerTestFiles

Each template has a paired .liquid.json input file. Pick any Liquid: config from the Run and Debug dropdown and press F5.

A Typical Debugging Session

Here is a real example: grandTotal shows 0 instead of 336.20.

Without local debugging, you update the template, run the Logic App, wait, check output, and repeat.

With the extension:

Press Debug.
Go to assign grandTotal and check the filter chain.
See couponAmt is 0.
Step back to couponDiscount and confirm it is 0.
Step back again and see if content.couponCode == "WINTER20" was not taken.
Check input JSON: couponCode is "winter20" (lowercase).

Done in minutes, with local runs between changes.

Where Local Debugging Fits

Use local runs for fast iteration.
Use Logic App execution for final validation.

Recommended Workflow

Write your template in VS Code.
Run locally with .liquid.json input.
Debug until correct.
Deploy and validate in Logic Apps.

Local inner loop: update → run locally → inspect → repeat.

Liquid works best when you can see what it is doing.

Liquid Templates in Azure Logic Apps: What They Are and Why They Matter

Daniel Jonathan — Fri, 03 Apr 2026 09:37:56 +0000

The Problem Every Logic Apps Developer Hits

You are building an integration on Azure Logic Apps Standard. The upstream system sends you a rich, nested JSON payload — a sales order with line items, discount codes, shipping methods, and state-specific tax rates. The downstream system expects a flat, transformed structure with calculated totals, a carrier label, and an SLA timestamp.

The built-in expression language gets you partway there. But the moment you need a loop, a conditional lookup table, or a running subtotal across items, you hit a wall.

That is the moment you reach for Liquid templates.

What Is Liquid?

Liquid is an open-source template language originally created by Shopify. It is designed to be safe, sandboxed, and easy to read — output is produced by mixing static text with template tags that reference data.

There are two kinds of tags:

{{ customer.firstName }}          /* output tag — renders a value */
{% if order.total > 1000 %}       /* logic tag — controls flow */

Note: The /* ... */ markers above are code annotations for readability only — they are not valid Liquid syntax. DotLiquid comments use {% comment %}...{% endcomment %}.

Variables, loops, conditionals, and filters cover most transformation needs without requiring you to write C# or JavaScript.

DotLiquid: The .NET Flavour Used by Logic Apps

Azure Logic Apps Standard does not use the original Ruby Liquid gem. It uses DotLiquid, a .NET port. This extension targets DotLiquid 2.0.361, which matches the version used by Logic Apps Standard at the time of writing.

This is not a minor implementation detail. There are several behavioural differences that will catch you off guard if you are used to standard Liquid or testing with an online Liquid playground.

Difference 1 — Filter names are sentence-cased

Standard Liquid uses lowercase filter names. DotLiquid uses sentence case.

Standard Liquid	DotLiquid (Logic Apps)
`upcase`	`Upcase`
`downcase`	`Downcase`
`divided_by`	`DividedBy`
`times`	`Times`
`round`	`Round`
`split`	`Split`
`join`	`Join`
`sort`	`Sort`
`map`	`Map`
`replace_first`	`ReplaceFirst`
`truncate`	`Truncate`
`strip_html`	`StripHtml`
`url_encode`	`UrlEncode`

If you use the wrong casing, the filter is silently ignored — the value passes through unchanged with no error.

Difference 2 — `DividedBy` truncates when both operands are whole numbers

This is the most common source of silent calculation errors.

Both standard Liquid and DotLiquid produce an integer result when the divisor is a whole number — this is not a DotLiquid-specific quirk, it is how both implementations work:

{{ 7 | divided_by: 2 }}   /* standard Liquid: outputs 3, not 3.5 */
{{ 7 | DividedBy: 2 }}    /* DotLiquid: outputs 3, not 3.5 */

Output: 3

To get decimal output, make the divisor a float:

{{ 7 | DividedBy: 2.0 }}

Output: 3.5

This matters for percentage calculations. total | Times: taxRate | DividedBy: 100 will truncate if the running value is a whole number — use 100.0 instead.

Subtle difference for negative numbers: Standard Liquid (Ruby) uses floor division (-7 / 2 = -4), while DotLiquid (C#) uses truncation (-7 / 2 = -3). For positive numbers the results are identical, but if your data can contain negative values this divergence is worth knowing.

Difference 3 — `Sort` is case-insensitive

Standard Liquid sorts with case-sensitive comparison — uppercase letters sort before lowercase in ASCII/ordinal order (B < a), so ["Banana", "apple"] would sort to ["Banana", "apple"]. DotLiquid sorts case-insensitively (OrdinalIgnoreCase), so the same array becomes ["apple", "Banana"].

If you are sorting strings and the casing matters to the sort order, be aware the result will differ from a Ruby Liquid environment.

Difference 4 — Date format uses .NET format strings, not strftime

Standard Liquid uses strftime format codes:

{{ "now" | date: "%Y-%m-%d" }}

DotLiquid uses .NET format strings:

{{ "now" | Date: "yyyy-MM-dd" }}

The filter name is also sentence-cased (Date, not date).

Difference 5 — Some standard filters are missing or renamed

Some standard Liquid filters are not available in DotLiquid 2.0.361 at all; others exist but only under their sentence-cased name:

Standard Liquid filter	DotLiquid equivalent
`compact`	`Compact` (available, sentence-cased)
`uniq`	`Uniq` (available, sentence-cased)
`sort_natural`	Not available
`where`	Not available
`find`	Not available
`sum`	Not available

If your template relies on these, you will need to work around them with loops and assign statements.

Difference 6 — The `content` wrapper

When Logic Apps Standard invokes a Liquid transform, the input JSON is wrapped in a content object:

{ "content": { ...your actual payload... } }

So if your input is:

{ "orderNumber": "ORD-001", "total": 149.99 }

Inside your template you access it as:

{{ content.orderNumber }}
{{ content.total }}

Miss this and every variable renders blank with no error message.

Quick reference

Behaviour	Standard Liquid	DotLiquid 2.0.361
Filter casing	`upcase`, `downcase`	`Upcase`, `Downcase`
Integer division	Truncates when divisor is integer (same behaviour)	Truncates when both operands are whole numbers; floor vs truncation differs for negatives
Sort order	Case-sensitive	Case-insensitive
Date format	`strftime` (`%Y-%m-%d`)	.NET format (`yyyy-MM-dd`)
Input root	Direct access	Wrapped in `content.*`
`compact` / `uniq`	Available (`compact`, `uniq`)	Available (`Compact`, `Uniq`)
`sort_natural` / `where` / `sum`	Available	Not available

The Core Syntax You Will Use Daily

Output

{{ content.customer.firstName }}
{{ content.order.total | Round: 2 }}
{{ content.status | Upcase }}

Assign (variables)

{%- assign subtotal = 0 -%}
{%- assign taxRate = 0.085 -%}
{%- assign tax = subtotal | Times: taxRate | Round: 2 -%}

The - inside {%- and -%} strips the surrounding whitespace — essential for keeping JSON output clean.

Loops

{%- for item in content.items -%}
  {%- assign lineTotal = item.quantity | Times: item.unitPrice -%}
  {%- assign subtotal = subtotal | Plus: lineTotal -%}
{%- endfor -%}

Conditionals

{%- if content.priority == "CRITICAL" -%}
  {%- assign slaHours = 4 -%}
{%- elsif content.priority == "HIGH" -%}
  {%- assign slaHours = 24 -%}
{%- else -%}
  {%- assign slaHours = 72 -%}
{%- endif -%}

Filter chains

Filters are chained left to right. Each filter receives the output of the previous one:

{%- assign grandTotal = subtotal | Minus: discount | Plus: tax | Round: 2 -%}

A Real-World Example: B2B Sales Order Transform

Here is a condensed version of a real Logic Apps transformation. The input is a B2B order with line items, a coupon code, and a shipping method. The output is a flat JSON structure ready for an ERP system.

Input (excerpt):

{
  "couponCode": "WINTER20",
  "header": { "priority": "HIGH" },
  "shipping": { "method": "FEDEX_GROUND" },
  "lines": [
    { "category": "HARDWARE", "quantity": 5, "unitPrice": 24.50, "discountPct": 10 },
    { "category": "SOFTWARE", "quantity": 3, "unitPrice": 99.00, "discountPct": 0  }
  ]
}

Template (excerpt):

{%- assign couponDiscount = 0 -%}
{%- if content.couponCode == "WINTER20" -%}{%- assign couponDiscount = 20 -%}
{%- elsif content.couponCode == "SAVE10" -%}{%- assign couponDiscount = 10 -%}
{%- endif -%}

{%- assign slaHours = 72 -%}
{%- if content.header.priority == "HIGH" -%}{%- assign slaHours = 24 -%}
{%- endif -%}

{%- assign carrier = "FedEx" -%}
{%- assign serviceLevel = "Ground" -%}

{%- assign subtotal = 0 -%}
{%- for line in content.lines -%}
  {%- assign grossLine = line.quantity | Times: line.unitPrice -%}
  {%- assign lineDiscount = grossLine | Times: line.discountPct | DividedBy: 100 -%}
  {%- assign netLine = grossLine | Minus: lineDiscount -%}
  {%- assign subtotal = subtotal | Plus: netLine -%}
{%- endfor -%}

{%- assign couponAmt = subtotal | Times: couponDiscount | DividedBy: 100 -%}
{%- assign grandTotal = subtotal | Minus: couponAmt | Round: 2 -%}

{
  "carrier": "{{ carrier }}",
  "serviceLevel": "{{ serviceLevel }}",
  "slaHours": {{ slaHours }},
  "subtotal": {{ subtotal | Round: 2 }},
  "couponDiscount": {{ couponAmt | Round: 2 }},
  "grandTotal": {{ grandTotal }}
}

Output:

{
  "carrier": "FedEx",
  "serviceLevel": "Ground",
  "slaHours": 24,
  "subtotal": 407.25,
  "couponDiscount": 81.45,
  "grandTotal": 325.8
}

Output Is Not Just JSON

A common misconception is that Logic Apps Liquid transforms only produce JSON. The template engine outputs whatever text the template produces. The three other common output formats:

XML — for B2B, EDI, or ERP integrations:

<?xml version="1.0" encoding="UTF-8"?>
<PurchaseOrder id="{{ content.orderNumber }}">
  <Vendor>{{ content.vendor.name }}</Vendor>
  {%- for item in content.lines -%}
  <LineItem sku="{{ item.sku }}">{{ item.quantity }}</LineItem>
  {%- endfor -%}
</PurchaseOrder>

HTML — for email bodies via SendGrid or similar:

<h1>Order Confirmation</h1>
<p>Hi {{ content.customer.firstName }},</p>
<p>Your order total is ${{ content.total | Round: 2 }}.</p>

Plain text — for warehouse printers, SMS, or legacy systems:

TRACKING: {{ content.trackingNumber }}
SHIP TO:  {{ content.recipient.name }}
          {{ content.recipient.address.line1 }}

The Pain: Flying Blind

Everything described above sounds straightforward — until you actually try to build it inside Logic Apps Studio.

The typical development loop looks like this:

Write the template in the Azure Portal or a text editor
Upload it to your Logic Apps integration account
Deploy or trigger a test run
Wait for the run history to populate
Expand the transform action output
Discover the output is wrong — or blank
Guess which line is the problem
Repeat

There is no syntax highlighting. No inline error messages. No way to inspect what a variable holds mid-template. A misnamed filter (upcase instead of Upcase) is silently ignored — the value passes through unchanged with no warning. A wrong dot-path (content.order.total instead of content.total) does the same.

The round-trip from "edit" to "see output" can take five minutes or more per iteration for a non-trivial template.

What Comes Next

In Part 2, we look at the DotLiquid Debugger VS Code extension — a tool that replaces the Azure Portal round-trip with instant local feedback, a step-by-step debugger, and filter chain tracing, all using the same DotLiquid 2.0.361 engine that Logic Apps Standard runs in production.

Part 2: Debug DotLiquid Templates Locally with the VS Code DotLiquid Debugger

Teaching Coding Agent to Write XSLT — The Hook in Action

Daniel Jonathan — Sat, 28 Mar 2026 07:44:17 +0000

Parts 1 and 2 explained the skill and the hook setup. This part shows it actually running — a real session, real prompts, real hook output. No theory.

We'll build the same Order-to-Shipment transformation three ways — XSLT 1.0 with inline C#, XSLT 2.0 with Saxon, and LML compiled to XSLT 3.0 — and watch the hook verify each one, catch bugs, and drive Claude through a multi-step fix cycle. Everything below is from a single session.

Step 1: XSLT 1.0 with inline C

The prompt

Create an XSLT 1.0 transformation (compatible with .NET XslCompiledTransform)
that maps an Order to a Shipment. Use the existing Order.xml as input reference
and target the ShipmentOutput.xsd schema.

Requirements:
- Map OrderID → ShipmentRef with a "SHP-" prefix (use inline C# via msxsl:script)
- Map OrderDate → ShipDate, reformatted from yyyy-MM-dd to dd/MM/yyyy (inline C#)
- Map CustomerName → Recipient
- Generate an ExecutionDate using inline C# that returns DateTime.UtcNow
- Loop over each Item → Line, mapping ProductName → Product and Quantity → Quantity
- Filter out items where Quantity < 1

Use the Order namespace `http://schemas.contoso.com/Order`.

What Claude reads first

Before writing anything, Claude reads the source and target schemas to understand both structures. This is the skill's Generate mode — it requires understanding the data shapes before choosing XPath expressions.

Source — Order.xml with namespace http://schemas.contoso.com/Order

Target — ShipmentOutput.xsd, no namespace:

Claude also reads the existing .vscode/launch.json to know where to append the new debug configuration. Now it writes.

The write sequence

The skill enforces a specific write order: launch config first, stylesheet last. This ensures the debug configuration is in place before the hook fires on the .xslt write.

File 1: .vscode/launch.json — appends a new configuration:

{
  "type": "xslt",
  "request": "launch",
  "name": "Debug Order2Shipment_20260327",
  "engine": "compiled",
  "stylesheet": "${workspaceFolder}/Artifacts/Maps/Order2Shipment_20260327.xslt",
  "xml": "${workspaceFolder}/Artifacts/SampleData/Order.xml",
  "output": "${workspaceFolder}/Artifacts/Maps/out/Order2Shipment_20260327-out.xml",
  "stopOnEntry": true,
  "debug": true,
  "logLevel": "log"
}

Engine is compiled — the .NET XslCompiledTransform engine that supports msxsl:script inline C#. No hook fires on this file.

File 2: Artifacts/Maps/Order2Shipment_20260327.xslt — the stylesheet with three C# helpers in a msxsl:script block:

PrefixShipmentRef(string orderId) — prepends "SHP-"
ReformatDate(string isoDate) — parses yyyy-MM-dd, returns dd/MM/yyyy
ExecutionDate() — returns DateTime.UtcNow as yyyy-MM-ddTHH:mm:ssZ

The hook fires. While Claude is still in the same response turn, the XSLT Debugger API compiles the inline C# via Roslyn, runs the transform against Order.xml, and returns the result:

That's the clean path. Before moving to XSLT 2.0, let's see what happens when this same map has bugs.

What the hook catches: two classes of failure

Silent data loss — the namespace bug

XSLT's most dangerous bugs produce structurally correct output with silently missing data. No error, no warning — just empty elements.

Claude drops the ord: namespace prefix from one XPath:

<!-- Bug: missing namespace prefix -->
<Recipient>
  <xsl:value-of select="Customer/CustomerName"/>
</Recipient>

The hook fires:

<Recipient></Recipient>

Exit code 0. The transform "succeeded". But <Recipient> is empty. Without the hook, this ships to production and nobody notices until a downstream system complains.

Claude sees the empty element, identifies the namespace mismatch (the skill's #1 debug pattern), and edits the file. The hook fires again on the Edit — not just on the initial Write. Every change to an .xslt file triggers a fresh transform:

<Recipient>John Doe</Recipient>

Fixed. Two hook invocations, one fix.

Hard compile failure — the C# syntax error

Exit code 1. No XML output at all — Roslyn rejects the C# before the XSLT engine even starts. Claude sees the error with exact line and column, adds the semicolon, hook fires again, clean output.

These are two fundamentally different failure modes:

Failure	What happens	Exit code	Catchable without hook?
Namespace mismatch	Valid XML, empty values	0	No — CI pipelines see "success"
C# compile error	No output, error message	1	Yes — but only if you run it

The namespace bug is why the hook matters most. It catches the failures that look like success.

Step 2: XSLT 2.0 with Saxon

Next prompt:

Now create the same map as XSLT 2.0 for Saxon. Create a new file.

Same write sequence: launch config first (engine saxonnet), then the stylesheet. No msxsl:script this time — XSLT 2.0 has native functions for everything the C# was doing:

XSLT 1.0 + C#	XSLT 2.0 native
`fn:PrefixShipmentRef(string(ord:OrderID))`	`concat('SHP-', ord:OrderID)`
`fn:ReformatDate(string(ord:OrderDate))`	`format-date(xs:date(ord:OrderDate), '[D01]/[M01]/[Y0001]')`
`fn:ExecutionDate()`	`format-dateTime(current-dateTime(), '[Y0001]-[M01]-[D01]T[H01]:[m01]:[s01]Z')`

The hook fires on the .xslt write:

Same output structure, same values. Two engines, two versions, same result — both verified by the hook automatically.

Step 3: LML compiled to XSLT 3.0

Now the same map authored in the Data Mapper's LML format — the visual designer's YAML source that compiles to XSLT 3.0. This is the most complex path because it has dependencies that must be created in the right order.

The prompt

Now create an LML for the same Order-to-Shipment mapping and test it.

The dependency chain

Claude reads the LML file and prepares the next actions

LML maps can reference custom extension functions defined in separate XML files. Before Claude can write the LML, it needs to create these functions. The full write sequence for LML mode is:

Launch config — debug configuration pointing at the compiled .xslt (not the .lml)
Custom functions — Artifacts/DataMapper/Extensions/Functions/ShipmentFunctions.xml
LML file — Artifacts/MapDefinitions/Order2Shipment_20260327-lml.lml (written last — the compile hook fires on this, using lml-compile)

The launch config points at Artifacts/Maps/Order2Shipment_20260327-lml.xslt — a file that doesn't exist yet. It will be generated when the LML compile hook fires. Engine is saxonnet because LML always compiles to XSLT 3.0.

The custom functions

Claude creates three functions in ShipmentFunctions.xml:

<customfunctions>
  <function name="prefixShipRef" as="xs:string">
    <param name="orderId" as="xs:string"/>
    <value-of select="concat('SHP-', $orderId)"/>
  </function>

  <function name="reformatDate" as="xs:string">
    <param name="dateVal" as="xs:date"/>
    <value-of select="format-date($dateVal, '[D01]/[M01]/[Y0001]')"/>
  </function>

  <function name="executionDateTime" as="xs:string">
    <value-of select="format-dateTime(...)"/>
  </function>
</customfunctions>

No hook fires — this is an .xml file, not .lml or .xslt. But this file has a bug that won't surface until the LML compiles. executionDateTime has zero parameters.

The LML file

$version: 1
$input: XML
$output: XML
$sourceSchema: OrderSchema.xsd
$targetSchema: ShipmentOutput.xsd
$sourceNamespaces:
  ns0: http://schemas.contoso.com/Order
Shipments:
  Shipment:
    ShipmentRef: prefixShipRef(/ns0:Order/ns0:OrderID)
    ShipDate: reformatDate(/ns0:Order/ns0:OrderDate)
    Recipient: /ns0:Order/ns0:Customer/ns0:CustomerName
    ExecutionDate: executionDateTime()
    Lines:
      $for(/ns0:Order/ns0:Items/ns0:Item):
        $if(is-greater-or-equal(ns0:Quantity, 1)):
          Line:
            Product: ns0:ProductName
            Quantity: ns0:Quantity

Claude writes this file. The LML compile hook fires — calling lml-compile, a dotnet global tool that wraps the Logic Apps SDK's DataMapTestExecutor.GenerateXslt(). And now the fixing cycle begins.

The fixing cycle

The executionDateTime function has zero parameters — the SDK's ReadCustomFunctionsDefinitionAsync() hits a NullReferenceException on parameters.Length and silently skips the entire XML file. All three functions become "unrecognized". Claude adds a dummy parameter, edits the LML, and the hook fires again — second error: is-greater-or-equal isn't a real LML pseudofunction. Claude switches to xpath("ns0:Quantity >= 1"), edits the LML one more time, and the hook returns clean output.

Three iterations, two bugs, one prompt. The compile hook drove the entire fix cycle — feeding each error back into Claude's context so it could diagnose and fix without manual intervention.

Iteration	Error	Root cause	Fix
1	`executionDateTime` unrecognized	Zero-param SDK bug — null `parameters` skips entire XML file	Add dummy `<param>`
2	`is-greater-or-equal` unrecognized	Not a real LML pseudofunction — UI label vs compiler syntax	Use `xpath("ns0:Quantity >= 1")`
3	Success	—	—

Three engines, one result

All three implementations now produce matching output from the same input:

Engine	Version	Date logic	String logic	Filter
`compiled`	XSLT 1.0	C# `DateTime.TryParse`	C# `string.Concat`	`xsl:if test="ord:Quantity >= 1"`
`saxonnet`	XSLT 2.0	`format-date(xs:date(...))`	`concat(...)`	`xsl:if test="ord:Quantity >= 1"`
`saxonnet`	XSLT 3.0 (LML)	`ef:reformatDate(...)`	`ef:prefixShipRef(...)`	`xsl:when test="ns0:Quantity >= 1"`

<!-- All three produce: -->
<ShipmentRef>SHP-ORD-1001</ShipmentRef>
<ShipDate>31/10/2025</ShipDate>
<Recipient>John Doe</Recipient>

The hook verified each automatically at write time. This matters for teams migrating between engines — you can write the same map in XSLT 1.0 for BizTalk and XSLT 3.0 for Logic Apps, and verify both produce identical output in the same session.

What you actually see in VS Code

When the hook fires during a Claude response, the output appears inline in Claude's context — a PostToolUse system reminder that Claude reads as part of the same turn. You don't see a separate panel or dialog.

For the XSLT 1.0 clean path:

Claude: [reads Order.xml, ShipmentOutput.xsd, launch.json]
Claude: [writes launch.json entry]
Claude: [writes Order2Shipment_20260327.xslt]
  ← Hook: PostToolUse:Write — Transform result: <Shipments>...</Shipments>
Claude: "Transform ran, output correct."

For the LML fixing cycle:

Claude: [writes launch.json entry]
Claude: [writes ShipmentFunctions.xml]
Claude: [writes Order2Shipment_20260327-lml.lml]
  ← Hook: PostToolUse:Write — ERROR: 'executionDateTime' unrecognized
Claude: [edits ShipmentFunctions.xml — adds dummy param]
Claude: [edits .lml — passes dummy argument]
  ← Hook: PostToolUse:Edit — ERROR: 'is-greater-or-equal' unrecognized
Claude: [edits .lml — switches to xpath()]
  ← Hook: PostToolUse:Edit — LML compiled + Transform result: <Shipments>...</Shipments>
Claude: "Three iterations, all fixed. Output matches."

From your side, you prompted once. Claude read the schemas, created the files, hit three errors, fixed all three, and came back with a verified transform. The iteration happened between Claude and the hook.

The full picture

Three parts, one system:

Skill — gives Claude the rules before it writes a line. Engine classification, version discipline, write order, debug taxonomy, LML syntax, known SDK bugs. Prevents common mistakes and provides the knowledge to diagnose uncommon ones.

Hooks — close the feedback loop after every write and edit. Compile on LML change using lml-compile (a dotnet global tool that wraps the SDK compiler). Run transform on XSLT change via the Debugger HTTP API. Return results — output or error — to Claude's context automatically.

The loop — Claude writes → hook runs → Claude reads result → Claude fixes if needed → hook runs again. One prompt from you; the iteration happens between Claude and the hook.

The skill and the hooks are independent — the skill works without the hooks (slower iteration, manual verification), the hooks work without the skill (no domain rules, more trial and error). Together they make a working environment where the AI can do real XSLT work reliably: catch silent namespace bugs before they reach production, fix C# compile errors in the same turn, iterate through LML compiler quirks without you lifting a finger.

The result isn't "AI-generated XSLT" that you have to review and test manually. It's XSLT that was already tested — by the same system that wrote it, in the same conversation turn, against real input data.

The XSLT Debugger extension is on the VS Code Marketplace for macOS and Windows.

Teaching Coding Agent to Write XSLT — The Hook Chain

Daniel Jonathan — Sat, 28 Mar 2026 07:41:16 +0000

Part 1 covered the XSLT skill — domain knowledge that prevents mistakes upfront. This part covers the runtime side: two PostToolUse hooks that automate compile-and-run so Claude sees the result of its own edits immediately.

Claude writes a file → hooks fire → output (or error) appears in context → Claude fixes and repeats. When the debugger is running and a matching launch config exists, no manual runs are needed. Otherwise the hook reports what's missing and Claude can guide you.

PostToolUse hooks

Claude Code hooks are shell commands that fire after tool events. PostToolUse fires after every Write or Edit — meaning iterative fixes get immediate feedback on every change.

Configure in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/generate-xslt-from-lml.sh",
            "timeout": 45,
            "statusMessage": "Compiling LML + running transform..."
          },
          {
            "type": "command",
            "command": "bash .claude/hooks/run-xslt-after-edit.sh",
            "timeout": 30,
            "statusMessage": "Running XSLT transform..."
          }
        ]
      }
    ]
  }
}

Both hooks filter on file extension internally — the first acts only on .lml, the second only on .xslt.

Hook 1: LML compile

When Claude edits a .lml file, the designer isn't involved — the compiled .xslt would be stale. This hook compiles it and runs the transform in one step.

The compiler: `lml-compile`

The Logic Apps testing SDK includes DataMapTestExecutor with a GenerateXslt() method. I wrapped it as a .NET global tool:

dotnet tool install -g lml-compile

No running Logic Apps host. No Azurite. Just:

lml-compile input.lml output.xslt

The hook

#!/usr/bin/env bash
set -euo pipefail

INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

# Only act on .lml files
case "$FILE_PATH" in *.lml) ;; *) exit 0 ;; esac

# Derive output path
BASENAME=$(basename "$FILE_PATH" .lml)
MAPS_DIR="$(cd "$(dirname "$FILE_PATH")/.." && pwd)/Maps"
OUT_XSLT="${MAPS_DIR}/${BASENAME}.xslt"
mkdir -p "$MAPS_DIR"

# Compile
set +e
COMPILE_OUTPUT=$(lml-compile "$FILE_PATH" "$OUT_XSLT" 2>&1)
COMPILE_EXIT=$?
set -e

if [ $COMPILE_EXIT -ne 0 ]; then
  jq -n --arg err "$COMPILE_OUTPUT" '{
    "hookSpecificOutput": {
      "hookEventName": "PostToolUse",
      "additionalContext": ("LML compile failed: " + $err)
    }
  }'
  exit 0
fi

# Find workspace and run transform via debugger HTTP API
# (walks up from file to find .vscode/launch.json)
# ... matches launch config, calls POST /run-transform ...

jq -n --arg ctx "$OUTPUT" '{
  "hookSpecificOutput": {
    "hookEventName": "PostToolUse",
    "additionalContext": ("LML compiled + transform result:\n" + $ctx)
  }
}'

If compile fails, Claude sees the error. If it succeeds and the debugger is running with a matching launch config, Claude sees the transform output in the same turn. If the debugger isn't running or no config matches, the hook reports the compile success and what's missing.

Hook 2: Transform runner

Fires when Claude writes or edits a .xslt file directly (Generate mode).

The key challenge: workspace derivation. In hook context, $(pwd) doesn't point to the project — it can resolve to /private/tmp. The fix: walk up from the edited file's path to find .vscode/launch.json:

DIR="$(cd "$(dirname "$EDITED_FILE")" && pwd)"
WORKSPACE=""
while [[ "$DIR" != "/" ]]; do
  if [[ -f "$DIR/.vscode/launch.json" ]]; then
    WORKSPACE="$DIR"; break
  fi
  DIR="$(dirname "$DIR")"
done

The hook then reads the matching launch config (resolving ${workspaceFolder}), extracts the input XML and engine, and calls the XSLT Debugger's HTTP API:

RESULT=$(curl -s -X POST "http://127.0.0.1:$PORT/run-transform" \
  -H "Content-Type: application/json" \
  -d "{\"stylesheet\": \"$STYLESHEET\", \"xml\": \"$XML\", \
\"engine\": \"$ENGINE\"}")

The result is returned via hookSpecificOutput so Claude sees the transform output in context.

How the hooks interact

Claude writes .xslt (Generate mode):

Claude → Write .xslt → Hook 1 ignores (not .lml) → Hook 2 runs transform → result to Claude

Claude writes .lml (LML mode):

Claude → Write .lml → Hook 1 compiles + runs transform → result to Claude → Hook 2 ignores (not .xslt)

The .xslt file written by lml-compile does not trigger Hook 2 — only files Claude writes directly via Write or Edit trigger hooks.

The feedback loop

Claude writes XSLT → hook runs transform → output in context → error? → Claude edits → hook runs again → correct output

No human in the loop for the fix cycle. Claude writes, sees the result, fixes if needed, sees the result again.

Shell bugs worth knowing

set -e with || true: Using OUTPUT=$(cmd) || true resets $? to 0 — the failure branch is unreachable. Fix: set +e, capture $?, then set -e.

grep -v returns exit 1 when no lines match: Under set -euo pipefail, this kills the hook. Append || true to the grep specifically.

$(pwd) in hook context: Doesn't inherit the project directory. Always derive workspace from the edited file's path.

The pattern generalises

The pattern is: skill (domain rules) + hook (verify after every write) = self-correcting AI. Nothing here is XSLT-specific except the domain knowledge and the tools the hooks call.

The same approach works for Terraform (terraform validate + terraform plan after .tf edits), SQL migrations, OpenAPI specs — anything where a write can be verified automatically.

The XSLT Debugger extension is on the VS Code Marketplace for macOS and Windows.

Teaching Coding Agent to Write XSLT — Building a Domain Skill

Daniel Jonathan — Sat, 28 Mar 2026 07:18:22 +0000

XSLT is unforgiving. Small mistakes — a wrong namespace, a version mismatch, an engine-specific function — produce silent failures. AI assistants make the same mistakes without explicit guidance.

The fix isn't a smarter model. It's giving the model a playbook.

Claude Code supports custom skills — markdown files that load into context when a task matches. I built one that encodes real XSLT expertise: five work modes, engine detection, version discipline, and structured output you can debug immediately.

What is a Claude Code skill?

A skill is a markdown file in .claude/skills/<name>/SKILL.md. When Claude detects a matching task, it reads the skill and follows its instructions. Reference files alongside it provide deeper detail on demand.

.claude/skills/xslt/
├── SKILL.md                        # modes, rules, output spec
└── references/
    ├── lml.md                      # Logic Apps Mapping Language
    ├── logicapps-xslt.md           # Logic Apps deployment and artifacts
    ├── saxoncs-quirks.md           # SaxonCS / XSLT 3.0 gotchas
    ├── biztalk-xslt.md             # BizTalk map authoring
    └── migration.md                # version migration guide

The skill built in this post is available at imdj360/dev-skills.

Mode detection

The skill first classifies the task into one of five modes:

Mode	Trigger
Generate	XML samples, schemas, "write me an XSLT"
Debug	Broken XSLT, error message, wrong output
Migrate	"Convert to 3.0", "rewrite as 1.0"
Compatibility	"Will this run in BizTalk?"
LML	`.lml` file, Data Mapper, "compile to XSLT"

Generate and LML produce an output bundle. Generate writes up to three artifacts (debug config, sample input, stylesheet). LML writes up to four core artifacts (debug config, sample input, LML source, compiled XSLT) — plus schemas and custom functions if the map needs them. The other modes produce artifacts only when needed.

Engine classification

This is where most AI-generated XSLT fails. The skill forces engine classification before any code is written:

BizTalk / XslCompiledTransform / msxsl:script → XSLT 1.0, compiled engine
Logic Apps (Transform XML action) → XSLT 1.0 by default
Saxon / SaxonCS → XSLT 2.0 or 3.0, saxonnet engine

If ambiguous, Claude must ask. It never assumes. This single rule prevents the most common failure: writing XSLT 2.0 features in a file that .NET XslCompiledTransform will choke on.

Version discipline

Never auto-upgrade. If the stylesheet says version="1.0", output stays 1.0. No sneaking in xsl:function, matches(), or xsl:sequence.

For 1.0, the skill enforces:

xsl:for-each only — no xsl:for-each-group
contains(), substring(), translate() — not matches(), replace()
Named templates, not xsl:function

Inline C# for XSLT 1.0

Pure XSLT 1.0 has gaps — no regex, no date formatting. The msxsl:script extension fills them with inline C#:

<msxsl:script language="C#" implements-prefix="fn">
  <![CDATA[
    public string ReformatDate(string isoDate) {
      if (System.DateTime.TryParse(isoDate, out System.DateTime dt))
        return dt.ToString("dd/MM/yyyy");
      return isoDate;
    }
  ]]>
</msxsl:script>

The skill knows the type mappings (XPath numbers → double, node-sets → XPathNodeIterator) and the constraint: msxsl:script runs on .NET XslCompiledTransform only, never Saxon.

Canonical skeletons

The skill provides starting templates so Claude doesn't construct structure from scratch.

XSLT 1.0 + inline C#:

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:msxsl="urn:schemas-microsoft-com:xslt"
  xmlns:fn="urn:my-functions"
  exclude-result-prefixes="msxsl fn">
  <xsl:output method="xml" indent="yes"/>
  <!-- msxsl:script block, then templates -->
</xsl:stylesheet>

XSLT 3.0 / SaxonCS:

<xsl:stylesheet version="3.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="#all"
  expand-text="yes">
  <xsl:output method="xml" indent="yes"/>
  <xsl:mode on-no-match="shallow-skip"/>
  <!-- templates -->
</xsl:stylesheet>

LML-generated XSLT 3.0 uses different conventions (mode="azure.workflow.datamapper", explicit namespace exclusions). The skill tracks both so Claude doesn't confuse them.

Debug taxonomy

For Debug mode, Claude classifies the bug before attempting a fix:

Class	Danger
Namespace mismatch — empty output, XPath returns nothing	High — exit code 0, looks like success
C# compile error — Roslyn error in `msxsl:script`	Obvious — exit code 1
Template priority conflict — wrong template fires	Medium
Version mismatch — works in Saxon, fails in .NET	Medium

Namespace mismatch is the most dangerous: the transform succeeds with valid XML structure but every value is empty.

The output bundle

For Generate and LML modes, the skill requires a complete output bundle.

Generate mode writes:

Launch config — appended to .vscode/launch.json
Sample input XML — if none exists for the source schema
Stylesheet — the .xslt file

LML mode writes (order matters):

Source and target schemas — XSD files in Artifacts/Schemas/, if not already present
Launch config — points at the compiled .xslt
Custom extension functions — if the map uses them (must be written before LML compiles)
Sample input XML — if none exists for the source schema
LML file — written last (compile hook fires on this)
Compiled XSLT — generated automatically by the compile hook

A launch config:

{
  "name": "Debug Order2Shipment",
  "type": "xslt",
  "request": "launch",
  "engine": "saxonnet",
  "stylesheet": "${workspaceFolder}/Artifacts/Maps/Order2Shipment.xslt",
  "xml": "${workspaceFolder}/Artifacts/SampleData/Order.xml",
  "output": "${workspaceFolder}/Artifacts/Maps/out/Order2Shipment-out.xml",
  "stopOnEntry": true
}

output is optional — omit it to see results in the Debug Console only. Press F5 and debug with breakpoints — no manual setup.

LML mode: custom functions and gotchas

LML maps can call custom functions in Artifacts/DataMapper/Extensions/Functions/*.xml:

<customfunctions>
  <function name="reformatDate" as="xs:string">
    <param name="dateVal" as="xs:date"/>
    <value-of select="format-date($dateVal, '[D01]/[M01]/[Y0001]')"/>
  </function>
</customfunctions>

The skill documents SDK bugs Claude needs to work around:

Zero-parameter functions crash the compiler — NullReferenceException, entire XML file silently skipped. Workaround: add a dummy <param>.
Multi-step paths in function arguments fail — wrap in xpath().
Bare @attr is invalid YAML — use xpath("@lineNum").

What the skill doesn't do

The skill is domain knowledge and rules. It doesn't run anything — that's the job of hooks (Part 2). It doesn't validate XSLT at runtime — that's the debugger.

Its value is preventing mistakes before they happen. Part 2 covers the hooks that catch errors at write time.

The XSLT Debugger extension is on the VS Code Marketplace for macOS and Windows.

DEV Community: Daniel Jonathan

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Context

Bug 1 — Intermittent duplicate key error at tool registration

What happens

What makes it particularly frustrating to diagnose

Load test

What you can't do

Bug 2 — MCP Connector does not support OAuth

What happens

Why it matters

Current state

What works in the meantime

Running Multiple MCP Servers with Azure Logic Apps

The Scenario

Step 1 — Create and Group MCP Workflows in Logic Apps

Basic Arithmetic Server

Extended Arithmetic Server

How This Is Stored (mcpservers.json)

MCP Server Endpoints

Step 2 — Connect the Agent to Both Servers

Step 3 — Execution Result

Why This Matters

Key Takeaway

Logic Apps Local Dev Tools — Now with ACA and Azure Sign-in Support

One dashboard, three connection types

Managing connections

EasyAuth — connecting to a protected ACA endpoint

ACA workflow view

Host LogicApps as an MCP Server on Azure Container Apps

What's already deployed

Running locally first

Consuming it from another Logic App

Securing the MCP endpoint on ACA

Validating with VS Code Copilot

Further reading — how MCP session handling works under the hood

Running Azure Logic Apps Standard on Azure Container Apps

Should you use Logic Apps Standard on ACA instead of n8n?

What we're building

The Docker image

Project structure

Bicep infrastructure

Service Bus — Basic SKU is enough

The critical env vars — stability fixes

Azure Files mount — critical path

Full env var list

Deployment

deploy.sh — provision infrastructure

build-push.sh — build and deploy the image

What lands in Azure

Notable workflows

wf5 — Service Bus → HTTP action

wf6 — Liquid JSON transform

Agentic flows work out of the box

The connector boundary

Verifying stability across restarts

Cost comparison vs n8n

What's next

Event Debouncing with Logic Apps and Azure Table Storage

The Problem

The Pattern

Step 1 — Receive

Step 2 — Wait

Step 3 — Process

Status Lifecycle

Why It Works

When Not to Use This Pattern

Debugging XSLT vs Liquid in VS Code

The Fundamental Difference

Capability Comparison

What This Looks Like in Practice

Why the Difference Exists

Which Should You Use?

Debug DotLiquid Templates Locally with the VS Code DotLiquid Debugger

The Problem We Are Solving

The Core Idea: Local Preview with the Exact Same Engine

How It Works Under the Hood

What You Actually Get

1. Live Preview

2. Step Debugger

Difference 2 — `DividedBy` truncates when both operands are whole numbers

Difference 3 — `Sort` is case-insensitive

Difference 6 — The `content` wrapper

The compiler: `lml-compile`