DEV Community: Daniel Jonathan

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.

Skip the Designer — Editing Logic Apps Data Mapper LML Files Directly

Daniel Jonathan — Fri, 27 Mar 2026 20:15:23 +0000

The Azure Logic Apps Data Mapper has a visual designer in VS Code. You drag lines between schemas, drop in functions, and it generates an .lml file (YAML) that compiles to XSLT 3.0.

In theory, you never touch the YAML. In practice, the designer has reliability problems that make direct LML editing the better workflow.

Why skip the designer?

The designer doesn't always persist changes correctly:

Changes revert on reopen — save, close, reopen, and the .lml on disk has the old value
String literals lose inner quotes — xpath("'kg'") becomes xpath("kg"), changing a literal to an element reference
Expressions get corrupted — conditions like xpath("if (...) then 'Y' else 'N'") lose quote characters
Function arguments get rewritten — argument order or paths change silently
No undo across sessions — you need git diff to catch silent corruption

These happen with normal operations, not edge cases.

What LML looks like

LML is YAML. Here's a complete map:

$version: 1
$input: XML
$output: XML
$sourceSchema: OrderSchema.xsd
$targetSchema: ShipmentOutput.xsd
$sourceNamespaces:
  ns0: http://schemas.contoso.com/Order
$targetNamespaces:
  xs: http://www.w3.org/2001/XMLSchema
Shipments:
  Shipment:
    ShipmentRef: prefixShipRef(/ns0:Order/ns0:OrderID)
    ShipDate: reformatDate(/ns0:Order/ns0:OrderDate)
    Recipient: /ns0:Order/ns0:Customer/ns0:CustomerName
    Lines:
      $for(/ns0:Order/ns0:Items/ns0:Item):
        $if(xpath("ns0:Quantity >= 1")):
          Line:
            Product: ns0:ProductName
            Quantity: ns0:Quantity

Header declares schemas and namespaces. Body maps target elements (left) to source expressions (right).

LML syntax cheat sheet

# Direct mapping
Recipient: /ns0:Order/ns0:Customer/ns0:CustomerName

# Attribute on parent element
$@shipId: /ns0:Order/ns0:OrderID

# Loop over repeating elements (paths inside are relative)
$for(/ns0:Order/ns0:Items/ns0:Item):
  Line:
    Product: ns0:ProductName

# Conditional
$if(xpath("ns0:Quantity >= 1")):
  Line:
    Product: ns0:ProductName

# Custom function (defined in Functions/*.xml)
ShipDate: reformatDate(/ns0:Order/ns0:OrderDate)

# Raw XPath escape hatch
Priority: xpath("upper-case(@priority)")
WeightUnit: xpath("'kg'")   # inner quotes = string literal

Custom extension functions

Defined in Artifacts/DataMapper/Extensions/Functions/*.xml:

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

Gotchas

Zero-parameter functions crash the compiler. The SDK throws a NullReferenceException and silently skips the entire XML file. Workaround: add a dummy parameter.

Function arguments must be single-step element names. Multi-step paths cause compile errors — wrap them in xpath():

# INVALID
Address: formatAddress(ns0:Customer/ns0:Street, ns0:Customer/ns0:City)

# FIX
Address: formatAddress(xpath("ns0:Customer/ns0:Street"), xpath("ns0:Customer/ns0:City"))

The workflow: edit, compile, verify

1. Edit the YAML

Open the .lml file in any text editor and make your change.

2. Compile to XSLT

Install lml-compile, a dotnet global tool that wraps the Logic Apps SDK:

dotnet tool install -g lml-compile

Compile:

lml-compile Artifacts/MapDefinitions/MyMap-lml.lml Artifacts/Maps/MyMap-lml.xslt
# OK: MyMap-lml.xslt

3. Verify

Run dotnet test or press F5 with the XSLT Debugger extension.

Auto-compile on save

Install the Run on Save extension and add this to your workspace settings (for multi-root workspaces, add it in the .code-workspace file — Run on Save doesn't read folder-level settings):

"emeraldwalk.runonsave": {
  "commands": [
    {
      "match": "\\.lml$",
      "cmd": "lml-compile ${file} ${fileDirname}/../Maps/${fileBasenameNoExt}.xslt"
    }
  ]
}

Note: Run on Save uses its own variables — not VS Code task variables. ${fileBasenameNoExt} and ${fileDirname} work; ${fileBasenameNoExtension} and ${workspaceFolder} do not. Reload the window after adding the config.

Now the cycle is just: edit .lml → save → F5 or dotnet test. The compile happens automatically.

What the compiler catches

Malformed YAML / missing $version header
Missing schemas in Artifacts/Schemas/
Unrecognized function calls
Invalid XPath syntax

Errors surface on save instead of at deploy time.

Naming convention

Name hand-authored LML files with a -lml suffix:

Artifacts/MapDefinitions/OrderToShipment-lml.lml  →  Artifacts/Maps/OrderToShipment-lml.xslt

This avoids colliding with hand-authored XSLT files and makes it clear which files are compiled output.

Summary

Use the designer to scaffold the initial map. Then switch to direct LML editing for all subsequent changes.

Edit .lml → save → auto-compile → verify

No designer round-trip. No silent rewrites. No surprises.

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

Workaround: Testing Logic Apps Data Mapper Maps on macOS

Daniel Jonathan — Fri, 27 Mar 2026 19:50:25 +0000

The Logic Apps Data Mapper in VS Code lets you create XML transformation maps on macOS. You can drag connections between source and target schemas, add functions, save — the visual designer works. The .lml file gets written to disk. You can even compile it to XSLT 3.0.

But you can't test it.

When you click Test Map on macOS, you get this:

400 – BadRequest: The .NET framework worker could not be found.

The Test Map feature depends on the Azure Functions .NET Framework worker — a Windows-only component. The button is there, the backend isn't. You can create maps all day — you just can't verify they produce correct output without deploying to Azure or switching to a Windows machine.

This post shows how to compile and run Data Mapper maps locally on any platform using the Logic Apps testing SDK and standard .NET unit tests.

The options

When you can't use Test Map, you have three paths:

Deploy to Azure and test there — works, but slow and requires infrastructure for every iteration
Start func host start locally with Azurite, call the REST compile endpoint — heavyweight, requires Azurite and a warm Azure Functions host, flaky on macOS
Use DataMapTestExecutor from the testing SDK — no host, no Azurite, no Azure, just dotnet test

Option 3 is what this post covers.

DataMapTestExecutor

The Logic Apps testing SDK (Microsoft.Azure.Workflows.WebJobs.Tests.Extension v1.0.1) includes a class called DataMapTestExecutor. It does two things:

Compiles LML to XSLT — GenerateXslt(mapName) reads the .lml from Artifacts/MapDefinitions/, resolves schemas, custom functions, and inline XSLT snippets, and returns the compiled XSLT 3.0 as bytes.
Runs the transform — RunMapAsync(xslt, input) takes the compiled XSLT and input XML bytes, executes the transform via SaxonCS, and returns the result.

This is the same compilation and execution pipeline that the designer's Test Map button and the func host runtime use — you're running the same code path, just without the Azure Functions host scaffolding.

Setting up the test project

Project structure

The test project lives alongside the Logic App project:

MyWorkspace/
├── MyLogicApp/                     # Logic App project (Standard)
│   ├── Artifacts/
│   │   ├── MapDefinitions/         # .lml source files
│   │   ├── Maps/                   # compiled .xslt (generated)
│   │   ├── Schemas/                # XSD / JSON schemas
│   │   ├── SampleData/             # sample input XML
│   │   └── DataMapper/
│   │       └── Extensions/
│   │           ├── Functions/      # custom function XML files
│   │           └── InlineXslt/     # inline XSLT snippets
│   └── .vscode/
└── Tests/
    └── MyLogicApp.Tests/           # test project
        ├── MyLogicApp.Tests.csproj
        └── OrderToShipment/
            ├── OrderToShipmentTest.cs
            └── Order-input.xml     # test-specific input data

The `.csproj`

The critical dependency is Microsoft.Azure.Workflows.WebJobs.Tests.Extension v1.0.1 — not v1.0.0. The DataMapTestExecutor class doesn't exist in v1.0.0.

Setup: project root, compilation, and result parsing

DataMapTestExecutor needs the Logic App project root — the directory that contains Artifacts/. It scans from there to find schemas, custom functions, and map definitions. [TestInitialize] runs before each test method — it compiles the LML to XSLT so every test starts from a freshly compiled stylesheet.

The ProjectRoot path is relative from the test's output directory — the number of .. segments depends on your folder structure. Count from bin/Debug/net8.0/ up to wherever the Logic App project lives.

GenerateXslt takes the map name without path or extension. It finds the matching .lml in Artifacts/MapDefinitions/, reads the schemas from the LML header, loads custom functions, and compiles to XSLT 3.0.

RunMapAsync returns a JToken with the transform output encoded as base64:

{ "$content-type": "application/xml", "$content": "PFNoaXBtZW50cy4uLg==" }

A helper to decode it:

private static XDocument ParseResult(JToken result)
{
    var base64 = result["$content"]!.Value<string>()!;
    var xml = Encoding.UTF8.GetString(Convert.FromBase64String(base64));
    return XDocument.Parse(xml);
}

Map 1: Order to Shipment — simple field mappings and filtering

This map transforms a single Order into a Shipment. It tests custom extension functions (prefixShipRef, reformatDate, executionDateTime), direct field mappings, a $for loop over line items, and a $if filter that excludes items with Quantity < 1.

Testing individual fields

Each mapping requirement gets its own test for clear failure diagnostics:

Validating the entire output

One test that checks everything — structure, values, element order, and the filter:

Map 2: PurchaseOrders to ShippingManifest — attributes, nested loops, computed values

This is a more complex map. It transforms multiple PurchaseOrders into a ShippingManifest with XML attributes, nested $for loops (Orders → Items), computed aggregates (totalWeight, totalValue), and custom functions (shipId, formatAddress, hazardousFlag, parcelSubtotal).

The test class follows the same pattern as Map 1 — same setup, different map name and input file.

Testing attributes and computed values

Testing nested loop output with hazmat flag

The inner $for loops over each Order's Items. The hazardousFlag custom function maps @hazardous="true" to "Y":

Running the tests

What DataMapTestExecutor does under the hood

DataMapTestExecutor(projectRoot)
  → scans Artifacts/Schemas/ for XSD and JSON schemas
  → scans Artifacts/DataMapper/Extensions/Functions/*.xml for custom functions
  → scans Artifacts/DataMapper/Extensions/InlineXslt/*.xml for XSLT snippets

GenerateXslt(mapName)
  → reads Artifacts/MapDefinitions/{mapName}.lml
  → resolves schema references from the LML header
  → compiles LML → XSLT 3.0 via DataMapperUtility
  → returns byte[] of the compiled stylesheet

RunMapAsync(xslt, input)
  → loads the XSLT via SaxonCS (bundled in the SDK)
  → runs the transform against the input bytes
  → returns JToken with base64-encoded XML result

Known gotchas

v1.0.0 vs v1.0.1. DataMapTestExecutor doesn't exist in v1.0.0 of the SDK. If dotnet test fails with a missing type, check your Microsoft.Azure.Workflows.WebJobs.Tests.Extension version.

ProjectRoot must point to the Logic App root. The path must resolve to the directory containing Artifacts/ — not the test project, not the solution root. If GenerateXslt throws "map not found", your path is wrong.

Zero-parameter custom functions. If any <function> in Functions/*.xml has no <param> elements, the SDK hits a NullReferenceException on function.parameters.Length. The entire XML file is silently skipped, making all functions in it "unrecognized". Workaround: add a dummy parameter <param name="_unused" as="xs:string"/>.

Custom function namespace scoping. Function files are parsed in isolation. Namespace prefixes declared in the main stylesheet (like xmlns:tns="...") are not available inside function XML files. Using tns:ElementName in a function's XPath will throw a NullReferenceException at init time.

Base64 response format. RunMapAsync does not return raw XML. The result is a JToken with $content containing base64-encoded output. You must decode it before asserting.

Beyond testing: the designer's save problem

And even if Test Map worked, the visual designer has its own problems — changes that revert on reopen, string literals that lose quotes, expressions that get silently rewritten. I wrote a separate post about editing LML files directly as a more reliable alternative to the designer.

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

Cut Logic Apps Standard Costs by 70% in Dev & POC Azure Environments

Daniel Jonathan — Sun, 15 Feb 2026 22:06:32 +0000

TL;DR

Logic Apps Standard runs on an App Service Plan --- which means you pay 24/7.

In dev and POC environments, that's unnecessary.

Deploy when you need it.
Tear down compute when you don't.
Keep storage. Keep run history.

Typical result: ~70% cost reduction.

The Core Idea

Logic Apps Standard runs on an App Service Plan (WS1).

That means compute is billed continuously --- even if no workflows are
running.

For non-production environments, that rarely makes sense.

Better approach:

Deploy in the morning
Work normally
Tear down compute in the evening
Keep the Storage Account intact

Run history is preserved because it lives in storage --- not in the App Service Plan.

The Problem

A typical Azure Pricing Calculator estimate shows:

App Service Plan (WS1 × 730 hours): ~€152/month\
Storage (example 1 TB, Hot LRS): ~€18/month\
Total: ~€170/month

That models a 24/7 production setup.

But dev environments often run:

8 hours per day\
~20 business days per month

That's about 160 hours, not 730.

The Insight

Run history and workflow state are stored in the Storage Account.

So if you:

Delete the Logic App
Delete the App Service Plan
Keep the Storage Account

All historical runs remain intact.

When you redeploy, the Logic App reconnects to the same storage.

Cost Impact Example

Instead of: €170/month (always-on)

If you run: 160 hours/month

Compute becomes approximately: €152 × (160 / 730) ≈ €33/month

Add storage (~€18 example):

≈ €51/month total. That's roughly 70% savings.

⚠ Storage costs vary by actual GB used and transaction volume.
The €18 example assumes 1 TB Hot LRS. Most dev environments use significantly less.

Daily Flow

Morning

Deploy infrastructure and workflows:

./deploy.sh <rg> <region> <mode>
./deploy-workflows.sh <rg> <logicapp-name> <path>

What the deploy script does:

# Switch to correct tenant/subscription
az login --tenant "$TENANT_ID"
az account set --subscription "$SUBSCRIPTION_ID"

# Create resource group
az group create --name "$RESOURCE_GROUP" --location "$LOCATION"

# Deploy Bicep template (creates App Service Plan, Logic App, Storage, App Insights)
az deployment group create \
  --name "$DEPLOYMENT_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --template-file "$TEMPLATE_FILE" \
  --parameters "@${PARAM_FILE}"

What the workflow deployment does:

# Package workflows into ZIP
cd "$WORKFLOWS_PATH"
zip -r "$TEMP_ZIP" . -x "*.git*" -x "local.settings.json"

# Deploy ZIP to Logic App
az functionapp deployment source config-zip \
  --resource-group "$RESOURCE_GROUP" \
  --name "$LOGIC_APP_NAME" \
  --src "$TEMP_ZIP"

During the Day

Run workflows
Debug runs
Inspect history
Use monitoring

No functional difference from always-on.

Evening

Tear down compute:

./teardown.sh <rg> <logicapp-name> <asp-name> --force

What the teardown script does:

# Delete Logic App (keeps storage intact)
az webapp delete \
  --name "$LOGIC_APP_NAME" \
  --resource-group "$RESOURCE_GROUP"

# Delete App Service Plan (the expensive part)
az appservice plan delete \
  --name "$ASP_NAME" \
  --resource-group "$RESOURCE_GROUP" \
  --yes

# Storage Accounts are NOT deleted
# Application Insights is NOT deleted
# Run history remains in storage

Removes:

Logic App
App Service Plan

Keeps:

Storage
Run history
Monitoring data

When To Use This

✅ Development environments
✅ Test environments
✅ POC and demo setups
✅ Low-frequency scheduled workloads

❌ Not for production

Production workloads should remain always-on to meet SLA and reliability
requirements.

Important Notes

App Service is billed per hour (partial hours count as full).
Do not tear down while workflows are running.
Recurrence triggers do not "catch up" when offline.
Storage cost scales with run history retention and transaction volume.
Non-decryptable secrets warning (AZFD0007): During repeated teardown/redeploy cycles, you may see a diagnostic warning about "non-decryptable secrets backups." This is cosmetic and doesn't affect functionality. To clean it up, run:

  az rest --method POST \
    --uri "https://management.azure.com/subscriptions/{subId}/resourceGroups/{rg}/providers/Microsoft.Web/sites/{logicAppName}/syncfunctiontriggers?api-version=2022-03-01"

See Microsoft AZFD0007 Docs for details.

Standard vs Consumption

Why not just use Consumption?

Consumption is pay-per-execution and ideal for low-volume workloads.

Standard is preferred when you need:

VNET integration
Dedicated compute
High throughput
Advanced networking scenarios

This optimization applies specifically to Logic Apps Standard.

Bottom Line

If your Logic App isn't needed 24/7, you shouldn't pay for it 24/7.

Deploy when needed.
Tear down compute when idle.
Keep storage. Keep history.
Same workflows.
Same performance.
Lower cost.

References

Local Development:

Building Logic Apps Locally with VS Code (HTTP, Blob, Queue & More)

Azure Documentation:

Inside Logic Apps Standard: Understanding Compute Units (CU) for Storage Scaling

Daniel Jonathan — Wed, 14 Jan 2026 23:54:54 +0000

Introduction

When your Logic App Standard workflows grow in volume and complexity, Azure provides a powerful horizontal scaling mechanism through Compute Units (CU). This post explains how CU architecture enables Logic Apps to distribute storage load across multiple storage accounts while maintaining data consistency and routing integrity.

Why Storage Scaling Matters

A single Azure Storage account has inherent limits:

~2,000 requests per partition
~20,000 requests per second at account level

Beyond these thresholds, request throttling occurs. For high-volume Logic Apps processing thousands of runs with dozens of actions each, a single storage account quickly becomes a bottleneck.

Microsoft's guidance suggests approximately 100K action executions per minute per storage account as a threshold for considering additional storage. Compute-heavy workflow actions may lower this threshold significantly.

What Are Compute Units?

Compute Units (also called Scale Units) are Azure Logic Apps' approach to horizontal storage scaling. Rather than overloading a single storage account with all workflow execution data, Logic Apps can distribute the load across up to 32 storage accounts (CU00 through CU31).

You configure this via host.json using the Runtime.ScaleUnitsCount parameter.

Single Storage Architecture

In the simplest deployment, all workflows use a single storage account:

Logic App → CU00 (Master) → Single Storage Account

With single storage:

All workflow definitions, runs, and actions live in one storage account
The storage account uses the CU00 suffix
This works well for low-to-moderate workloads

Scale-Out Storage Architecture

When a Logic App needs to handle high-volume workflows, it can scale out to multiple storage accounts:

Logic App → CU00 (Master)  → Storage Account 1
         → CU01            → Storage Account 2
         → CU02            → Storage Account 3
         → ...             → ...
         → CU31            → Storage Account 32

Each Compute Unit maps to its own dedicated storage account, allowing parallel writes and reads across multiple storage endpoints.

How CU Routing Works

The key to this architecture is the Run ID. Every workflow run includes a CU suffix that identifies which storage account contains its action data:

08584345852018133305811297792-CU00
08584345852018133305811297793-CU01
08584345852018133305711297794-CU02

Routing Steps

Extract CU suffix from the RunId (e.g., -CU01)
Lookup storage account mapping for the Logic App + CU combination
Query the correct storage account for action data

This ensures that when you request run details, the system knows exactly which storage account to query.

Table Distribution Across CUs

Not all tables are distributed the same way. Here's the key distinction:

Table Type	Location Determined By
Base Tables (`flows`, `jobdefinitions`, etc.)	Always CU00 (Master)
Workflow `flows`, `runs`, `histories`	`ScaleUnit` field in base flows metadata table
Date-stamped `actions` tables	`RunId-CUXX` suffix (per-run routing)

Two Different Assignment Mechanisms

1. Workflow Tables (ScaleUnit field)

When you deploy a new workflow, Logic Apps assigns it to a CU. This assignment is:

Non-deterministic from developer perspective - you can't specify "put this workflow on CU02"
Decided at deployment time - when a new workflow is added, Logic Apps picks a CU
Stored in the workflow's metadata - the ScaleUnit field in the flows table records the assignment

The workflow's flows, runs, and histories tables live in this assigned CU storage account.

2. Action Tables (RunId-CUXX suffix)

Here's the critical difference: action tables are distributed per-run, not per-workflow.

Each run execution gets assigned to a CU, indicated by the suffix in the RunId:

08584345852018133305811297792CU01
08584345852115148130432249577CU00

This means:

A single workflow's actions can be spread across multiple CU storage accounts
On any given date, you might have action tables for the same workflow in CU00, CU01, CU02, etc.
Each storage account has its own date-stamped action table: {WFIdentifier}20250114T000000Zactions

Example: Distributed Actions

For a workflow with ScaleUnit = CU00, runs might execute across different CUs:

Workflow metadata (flows, runs, histories) → CU00 storage

Run 1: 08584345852018133305811297792-CU00 → actions in CU00 storage
Run 2: 08584345852018133305811297793-CU01 → actions in CU01 storage
Run 3: 08584345852018133305811297794-CU00 → actions in CU00 storage
Run 4: 08584345852018133305811297795-CU02 → actions in CU02 storage

On January 14, 2025, this workflow could have action tables in three different storage accounts:

CU00: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
CU01: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions
CU02: flow{LAIdentifier}{WFIdentifier}20250114T000000Zactions

What This Means

App-level metadata stays centralized: Base tables remain in CU00 (Master)
Workflow metadata has a home: flows, runs, histories live in the workflow's assigned CU
Actions are truly distributed: Action data spreads across CUs based on run execution
Query complexity increases: To get all actions for a date range, you may need to query multiple storage accounts

Why This Matters

For High-Volume Workflows

If your Logic App processes thousands of runs daily, each run might execute dozens of actions. Without CU distribution:

A single storage account becomes a bottleneck
Table partition limits could throttle performance
Query latency increases as tables grow

With CU distribution:

Write operations spread across multiple endpoints
Each storage account handles a fraction of the load
Queries route directly to the relevant storage

For Run History Queries

When building tooling that queries run history (like export utilities or monitoring dashboards), you must account for CU routing:

Parse the Run ID to extract the CU suffix
Resolve the correct storage account for that CU
Query the CU-specific storage for action data

Ignoring CU routing means you'll miss action data entirely.

Configuring Scale Units

To enable multiple storage accounts, configure host.json:

{
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.ScaleUnitsCount": 4
      }
    }
  }
}

This tells Logic Apps to use 4 storage accounts (CU00-CU03). You'll need to provision the additional storage accounts and configure their connection strings or managed identity access.

Authentication options:

Connection strings in app settings
Managed identity (recommended for production)

Summary

Compute Units enable Logic Apps Standard to scale storage horizontally:

CU00 is the master, holding app-level base tables
Workflow tables (flows, runs, histories) live in the CU specified by the ScaleUnit field
Action tables are distributed per-run based on the RunId-CUXX suffix
Same workflow, multiple CUs: A workflow's actions can span multiple storage accounts
Configure via Runtime.ScaleUnitsCount in host.json (max 32)
Threshold guidance: ~100K action executions per minute per storage account

Understanding this architecture is essential when building tooling around Logic Apps, querying run histories programmatically, or troubleshooting high-volume workflow performance.

References

Scaling Logic App Standard for high-throughput scenarios - Microsoft Tech Community

This is part of the "Inside Logic Apps Standard" series, exploring the internals of Azure Logic Apps Standard architecture.

Inside Logic Apps Standard: How Azure Tables Store Your Workflows

Daniel Jonathan — Wed, 14 Jan 2026 23:28:43 +0000

Overview

Azure Logic Apps Standard uses Azure Table Storage as its primary persistence layer for workflow state, execution history, and runtime metadata. This document provides a comprehensive reference to the table architecture, naming conventions, and schema patterns.

Table Categories

Logic Apps Standard organizes data into two distinct table categories:

Category	Scope	Purpose
Base Tables	Logic App Resource	Shared runtime metadata across all workflows
Flow Tables	Individual Workflow	Isolated execution data per workflow

This separation enables workflow isolation, horizontal scaling, and independent lifecycle management.

Base Tables (App-Level)

Base Tables store metadata that applies to the entire Logic App resource. All workflows within a Logic App share these tables.

Table Naming Pattern

flow{LAIdentifier}{suffix}

Where:

LAIdentifier = First 15 characters of MurmurHash64(LogicAppName)
suffix = Table type identifier

Base Table Types

Table Suffix	Purpose	Key Data
`flows`	Master workflow registry	Workflow definitions, state, CU assignment
`flowruntimecontext`	Runtime execution context	Flow state, execution cluster type, runtime config
`flowaccesskeys`	Workflow access keys	Primary/secondary keys for workflow API access
`flowsubscriptions`	Subscription registration	Tenant registration, subscription state
`flowsubscriptionsummary`	Workflow counts & summaries	Flow counts by state (enabled/disabled)
`jobdefinitions`	Job scheduler metadata	Execution state, retry config, repeat schedules

Example

For a Logic App named OrderProcessing:

LAIdentifier = flow7365adc025615f3

Base Tables:
├── flow7365adc025615f3flows
├── flow7365adc025615f3flowruntimecontext
├── flow7365adc025615f3flowaccesskeys
├── flow7365adc025615f3flowsubscriptions
└── flow7365adc025615f3jobdefinitions

Flow Tables (Workflow-Level)

Flow Tables store execution data specific to each workflow. Each workflow gets its own isolated set of tables.

Table Naming Pattern

flow{LAIdentifier}{WFIdentifier}{suffix}

Where:

LAIdentifier = First 15 characters of MurmurHash64(LogicAppName)
WFIdentifier = First 15 characters of MurmurHash64(WorkflowId)
suffix = Table type identifier

Flow Table Types

Table Suffix	Purpose	Key Data
`flows`	Workflow definition cache	Latest definition, parameters, runtime context, CU
`runs`	Run metadata	Run status, timing, trigger info, correlation IDs
`histories`	Trigger history	Trigger fires, evaluation results, input/output links
`actions`	Action executions	Action status, timing, input/output blob links
`variables`	Workflow variables	Variable name, data type, value links
`concurrentruns`	Concurrency tracking	Active run coordination (when concurrency is enabled)

Date-Stamped Tables

Action-related tables use date partitioning for scalability:

{WFIdentifier}yyyyMMddT000000Z{suffix}

Example: 1c859134ef297b720250114T000000Zactions

Example

For workflow ProcessOrder in OrderProcessing Logic App:

LAIdentifier = flow7365adc025615f3
WFIdentifier = 1c859134ef297b7

Flow Tables:
├── flow7365adc025615f31c859134ef297b7flows
├── flow7365adc025615f31c859134ef297b7runs
├── flow7365adc025615f31c859134ef297b7histories
├── flow7365adc025615f31c859134ef297b720250114T000000Zactions
└── flow7365adc025615f31c859134ef297b720250114T000000Zvariables

Table Key Fields

Base Flows Table (Master Registry)

Field	Description
FlowId	Unique workflow identifier (GUID)
FlowName	Workflow name
Kind	Workflow type (`Stateful` / `Stateless`)
State	`Enabled` or `Disabled`
ScaleUnit	CU assignment (`CU00`, `CU01`, etc.)
DefinitionCompressed	Compressed workflow JSON definition
ParametersCompressed	Compressed workflow parameters
RuntimeConfiguration	Retention settings, operation options
CreatedTime / ChangedTime	Lifecycle timestamps

FlowRuntimeContext Table

Field	Description
FlowId	Workflow identifier
FlowState	Current workflow state
FlowExecutionClusterType	Execution cluster (`Classic`)
Kind	Workflow type
RuntimeConfiguration	Runtime settings JSON
FlowSequenceId	Sequence identifier

FlowAccessKeys Table

Field	Description
FlowId	Workflow identifier
FlowAccessKeyName	Key name (e.g., `default`)
PrimaryKey	Primary access key
SecondaryKey	Secondary access key

FlowSubscriptions Table

Field	Description
SubscriptionId	Azure subscription identifier
State	Registration state (`Registered`)
Properties	Tenant ID and registered features JSON
RegistrationDate	Subscription registration timestamp

FlowSubscriptionSummary Table

Field	Description
FlowCountsByState	JSON with enabled/disabled workflow counts
FlowId / FlowName	Workflow reference (for per-workflow entries)
State	Workflow state
ScaleUnit	CU assignment
DefinitionCompressed	Compressed definition (cached)

JobDefinitions Table

Field	Description
JobId	Unique job identifier
JobPartition	Job partition key
Callback	Job callback type (e.g., `LinearSequencerJob`)
State	Job state (`Completed`, `Waiting`, etc.)
ExecutionState	Current execution state
StartTime / EndTime	Job scheduling window
NextExecutionTime	Scheduled next execution
RepeatMode / RepeatUnit / RepeatInterval	Recurrence configuration
RetryMode / RetryCount / RetryInterval	Retry configuration
CurrentExecutionCount	Total executions
LastExecutionStatus / LastExecutionTime	Most recent execution info
BinaryMetadata00-15	Compressed job metadata chunks

Runs Table

Field	Description
FlowId / FlowName	Workflow reference
Status	`Succeeded`, `Failed`, `Running`, `Cancelled`
CreatedTime / EndTime	Run timing
TriggerName	Trigger that initiated the run
CorrelationId	Request correlation tracking
ClientTrackingId	Client-provided tracking ID
TriggerCompressed	Compressed trigger payload
OutputsCompressed	Compressed run outputs

Histories Table (Trigger History)

Field	Description
HistoryName	History entry identifier
TriggerName	Trigger reference
Fired	Boolean - whether trigger actually fired
Status	Trigger evaluation result
InputsLinkCompressed	Link to trigger inputs
OutputsLinkCompressed	Link to trigger outputs
TrackingId	Correlation tracking

Actions Table

Field	Description
ActionName	Action identifier
ActionRepetitionName	Loop iteration index (e.g., `000000`)
Status	`Succeeded`, `Skipped`, `Failed`
Code	Result code (`OK`, `ActionSkipped`, etc.)
CreatedTime / CompletedTime	Action timing
InputsLinkCompressed	Link to action inputs blob
OutputsLinkCompressed	Link to action outputs blob
RepeatItemIndex	Loop iteration number
RepeatItemScopeName	Parent loop action name
Error	Error details (if failed)

Variables Table

Field	Description
VariableName	Variable identifier
DataType	Variable type (`Integer`, `String`, `Boolean`, etc.)
FlowId / FlowName	Workflow reference
FlowRunSequenceId	Run sequence identifier
OperationId	Operation that modified the variable
OperationSequenceId	Operation sequence
InputsLinkCompressed	Link to variable input
ValueLinkCompressed	Link to current variable value
CreatedTime / ChangedTime	Variable lifecycle timestamps

Workflow Flows Table (Per-Workflow Cache)

Field	Description
FlowId / FlowName	Workflow identifier
Kind	Workflow type (`Stateful`)
State	`Enabled` or `Disabled`
ScaleUnit	CU assignment
DefinitionCompressed	Compressed latest workflow definition
ParametersCompressed	Compressed parameters
RuntimeConfiguration	Runtime settings JSON
RuntimeContext	Compressed runtime context
FlowSequenceId	Definition sequence ID
FlowUpdatedTime	Last definition update time

Identifier Generation

Logic Apps uses MurmurHash64 for deterministic, collision-resistant identifier generation.

Algorithm

// Generate Logic App identifier (LAIdentifier)
string laIdentifier = "flow" + MurmurHash64(logicAppName).Substring(0, 15);

// Generate Workflow identifier (WFIdentifier)
string wfIdentifier = MurmurHash64(workflowId).Substring(0, 15);

// Complete table name
string tableName = laIdentifier + wfIdentifier + suffix;

Constraints

Table names: Max 63 characters (Azure Table Storage limit)
Characters: Lowercase alphanumeric only
Hash truncation: 15 characters provides sufficient uniqueness

Quick Reference

Table Name Format

Base:  flow{LAIdentifier}{suffix}
Flow:  flow{LAIdentifier}{WFIdentifier}{suffix}
Dated: flow{LAIdentifier}{WFIdentifier}{yyyyMMddT000000Z}{suffix}

Common Suffixes

Suffix	Level	Purpose
flows	Both	Definitions
runs	Flow	Run history
actions	Flow	Action executions
flowsubscriptions	Base	Trigger subscriptions
jobdefinitions	Base	Scheduled jobs

Update Reference:

Flow Tables in SQL for Hybrid Deployment

Testing Azure Logic Apps: Implementation Guide

Daniel Jonathan — Thu, 18 Dec 2025 16:04:40 +0000

TL;DR

In Part 4 , we learned LogicAppUnit fundamentals. Now we build real test suites using production workflows that mix HTTP actions and ServiceProvider connectors. You'll see project structure, mock data management, happy/sad path testing, and debugging techniques - all from working production code.

What You'll Learn

✅ Structure testable Logic App projects
✅ Mock ServiceProvider connectors (Blob, SAS URLs)
✅ Test happy paths and error handling
✅ Manage mock data with JSON files
✅ Debug test failures efficiently

The Workflows

🔷 Product Creation (Complex)

Flow: Validate → Create Product → Upload Blob → Get SAS URL → Update Metadata → Respond

Tests: Error handling, validation, request inspection

🔷 Blob Search (Simple)

Flow: Build Request → Call Function → Check Result → Respond

Tests: Success, empty results, API errors

Project Structure

AzMCP/
├── src/
│   ├── LABasicDemo/              # Logic App
│   │   ├── wf-product-create/    # HTTP action workflow
│   │   │   └── workflow.json
│   │   ├── wf-builtin-connector/ # Built-in connector (Azure Blob)
│   │   │   └── workflow.json
│   │   ├── wf-mngconnector-pub/  # Managed connector(Service Bus, O365)
│   │   │   └── workflow.json
│   │   ├── wf-mngconnector-sub/       
│   │   │   └── workflow.json
│   │   ├── parameters.json             # @appsetting() refs
│   │   ├── connections.json            # Production connections
│   │   └── local.settings.json
│   │
│   └── CommonComps.UnitTests/          # Tests
│       ├── LogicApp/
│       │   ├── wf-product-create/
│       │   │   ├── WfProductCreateTests.cs
│       │   │   └── MockData/
│       │   │       ├── CreateProductResponse.json
│       │   │       └── UploadBlobResponse.json
│       │   ├── wf-builtin-connector/
│       │   │   ├── WfBuiltInConnectorTests.cs
│       │   │   └── MockData/
│       │   │       ├── UploadBlobResponse.json
│       │   │       └── GetBlobSASUriResponse.json
│       │   ├── wf-mngconnector-pub/
│       │   │   ├── WfMngConnectorPubTests.cs
│       │   │   └── MockData/
│       │   │       ├── Office365SendEmailResponse.json
│       │   │       └── ServiceBusSendMessageResponse.json
│       │   ├── wf-mngconnector-sub/
│       │   │   ├── WfMngConnectorSubTests.cs
│       │   │   └── MockData/
│       │   │       └── ServiceBusTriggerPayload.json
│       │   └── Helpers/
│       │       └── TestConfigHelper.cs
│       └── testConfiguration.json
│       └── parameters.unittest.json
│       └── connection.unittest.json
│       └── local.setting.unittest.json

Configuration Files

parameters.json (Production)

{
  "apiUrl": {
    "value": "@appsetting('apiUrl')"
  },
  "servicebus-ConnectionRuntimeUrl": {
    "value": "@appsetting('servicebus-ConnectionRuntimeUrl')"
  },
  "servicebus-Authentication": {
    "type": "Object",
    "value": {
      "type": "ManagedServiceIdentity"
    }
  },
  "office365-ConnectionRuntimeUrl": {
    "value": "@appsetting('office365-ConnectionRuntimeUrl')"
  },
  "office365-Authentication": {
    "type": "Object",
    "value": {
      "type": "ManagedServiceIdentity"
    }
  }
}

parameters.unittest.json (Test Override)

{
  "apiUrl": {
    "value": "@appsetting('apiUrl')"
  },
  "servicebus-ConnectionRuntimeUrl": {
    "value": "@appsetting('servicebus-ConnectionRuntimeUrl')"
  },
  "servicebus-Authentication": {
    "type": "Object",
    "value": {
      "type": "Raw",
      "scheme": "Key",
      "parameter": "@appsetting('servicebus-connectionKey')"
    }
  },
  "office365-ConnectionRuntimeUrl": {
    "value": "@appsetting('office365-ConnectionRuntimeUrl')"
  },
  "office365-Authentication": {
    "type": "Object",
    "value": {
      "type": "Raw",
      "scheme": "Key",
      "parameter": "@appsetting('office365-connectionKey')"
    }
  }
}

local.settings.json

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "AzureWebJobsFeatureFlags": "EnableWorkerIndexing",
    "apiUrl": "https://your-api.azurewebsites.net/api",
    "AzureBlob_connectionString": "DefaultEndpointsProtocol=https;AccountName=youraccount;AccountKey=dummy;EndpointSuffix=core.windows.net",
    "servicebus-connectionKey": "dummy-key-for-tests",
    "servicebus-ConnectionRuntimeUrl": "https://dummy-servicebus.servicebus.windows.net",
    "office365-connectionKey": "dummy-key-for-tests",
    "office365-ConnectionRuntimeUrl": "https://dummy-office365.office365.com",
    "WORKFLOWS_SUBSCRIPTION_ID": "00000000-0000-0000-0000-000000000000",
    "WORKFLOWS_LOCATION_NAME": "eastus",
    "WORKFLOWS_RESOURCE_GROUP_NAME": "rg-test"
  }
}

connections.json (Production)

{
  "serviceProviderConnections": {
    "AzureBlob": {
      "parameterValues": {
        "connectionString": "@appsetting('AzureBlob_connectionString')"
      },
      "parameterSetName": "connectionString",
      "serviceProvider": {
        "id": "/serviceProviders/AzureBlob"
      }
    }
  },
  "managedApiConnections": {
    "servicebus": {
      "api": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/servicebus"
      },
      "connection": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourceGroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/servicebus"
      },
      "connectionRuntimeUrl": "@parameters('servicebus-ConnectionRuntimeUrl')",
      "authentication": "@parameters('servicebus-Authentication')"
    },
    "office365": {
      "api": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/office365"
      },
      "connection": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourceGroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/office365"
      },
      "connectionRuntimeUrl": "@parameters('office365-ConnectionRuntimeUrl')",
      "authentication": "@parameters('office365-Authentication')"
    }
  }
}

connections.unittest.json (Test Override)

{
  "serviceProviderConnections": {
    "AzureBlob": {
      "parameterValues": {
        "connectionString": "@appsetting('AzureBlob_connectionString')"
      },
      "parameterSetName": "connectionString",
      "serviceProvider": {
        "id": "/serviceProviders/AzureBlob"
      }
    }
  },
  "managedApiConnections": {
    "servicebus": {
      "api": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/servicebus"
      },
      "connection": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourceGroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/servicebus"
      },
      "authentication": {
        "type": "Raw",
        "scheme": "Key",
        "parameter": "@appsetting('servicebus-connectionKey')"
      },
      "connectionRuntimeUrl": "@parameters('servicebus-ConnectionRuntimeUrl')"
    },
    "office365": {
      "api": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/providers/Microsoft.Web/locations/@{appsetting('WORKFLOWS_LOCATION_NAME')}/managedApis/office365"
      },
      "connection": {
        "id": "/subscriptions/@{appsetting('WORKFLOWS_SUBSCRIPTION_ID')}/resourceGroups/@{appsetting('WORKFLOWS_RESOURCE_GROUP_NAME')}/providers/Microsoft.Web/connections/office365"
      },
      "authentication": {
        "type": "Raw",
        "scheme": "Key",
        "parameter": "@appsetting('office365-connectionKey')"
      },
      "connectionRuntimeUrl": "@parameters('office365-ConnectionRuntimeUrl')"
    }
  }
}

testConfiguration.json

{
  "azurite": {
    "enableAzuritePortCheck": true
  },
  "logging": {
    "writeMockRequestMatchingLogs": true
  },
  "workflow": {
    "externalApiUrlsToMock": [
      "https://your-api.azurewebsites.net"
    ],
    "builtInConnectorsToMock": [
      "uploadBlob",
      "getBlobSASUri"
    ]
  }
}

Key Configuration Points

Production vs Test:

parameters.json uses ManagedServiceIdentity → parameters.unittest.json uses Raw auth
connections.json references @parameters() → connections.unittest.json has explicit Raw auth
Test files are swapped in by TestConfigHelper before Initialize()

Critical Settings:

All parameters use @appsetting() - never hardcode values
externalApiUrlsToMock contains base URLs only (no paths)
builtInConnectorsToMock lists operationIds from workflows
Managed connector auth MUST be Raw type for tests

Test Base Class

public class WfProductCreateTests : WorkflowTestBase, IDisposable
{
    private readonly LogicAppTestConfigHelper _configHelper;
    private static readonly string MockDataPath = Path.Combine(
        AppDomain.CurrentDomain.BaseDirectory,
        "../../../LogicApp/wf-product-create/MockData");

    public WfProductCreateTests()
    {
        _configHelper = new LogicAppTestConfigHelper();
        _configHelper.ApplyTestConfig("../LABasicDemo");
        Initialize("../../../../LABasicDemo", "wf-product-create");
    }

    public void Dispose() => _configHelper?.RestoreAll();

    private static JObject LoadMockData(string fileName) =>
        JObject.Parse(File.ReadAllText(Path.Combine(MockDataPath, fileName)));
}

Example 1: Happy Path Test

[Fact]
public void CreateProduct_HappyPath_Success()
{
    using (ITestRunner testRunner = CreateTestRunner())
    {
        // 📂 Load mocks
        var productResp = LoadMockData("CreateProductResponse.json");
        var blobResp = LoadMockData("UploadBlobResponse.json");
        var sasResp = LoadMockData("GetSasUrlResponse.json");

        // 🌐 HTTP action - CreateProduct (INTERCEPTED)
        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPost()
                .WithPath(PathMatchType.Contains, "/Products"))
            .RespondWith(MockResponseBuilder.Create()
                .WithSuccess()
                .WithContentAsJson(productResp));

        // 📦 Built-in - uploadblob (CONVERTED)
        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPost()
                .WithPath(PathMatchType.Exact, "/uploadblob")
                .FromAction("uploadblob"))
            .RespondWith(MockResponseBuilder.Create()
                .WithSuccess()
                .WithContentAsJson(blobResp));

        // 🔗 Built-in - GetSasUrl (CONVERTED)
        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPost()
                .WithPath(PathMatchType.Exact, "/GetSasUrl")
                .FromAction("GetSasUrl"))
            .RespondWith(MockResponseBuilder.Create()
                .WithSuccess()
                .WithContentAsJson(sasResp));

        // 🏷️ HTTP action - updatemetadata (INTERCEPTED)
        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPut()
                .WithPath(PathMatchType.Contains, "uploadproductinfo"))
            .RespondWith(MockResponseBuilder.Create().WithSuccess());

        // 🚀 Trigger
        var response = testRunner.TriggerWorkflow(
            new StringContent(@"{
                ""name"": ""LaptopM4"",
                ""sku"": ""006"",
                ""categoryId"": 1,
                ""price"": 1500
            }", Encoding.UTF8, "application/json"),
            HttpMethod.Post);

        // ✅ Assert
        Assert.Equal(WorkflowRunStatus.Succeeded, testRunner.WorkflowRunStatus);
        Assert.Equal(HttpStatusCode.OK, response.StatusCode);
        Assert.Equal(ActionStatus.Succeeded,
            testRunner.GetWorkflowActionStatus("uploadblob"));
    }
}

Mock Data Files

CreateProductResponse.json (HTTP)

{
  "id": 123,
  "name": "LaptopM4",
  "sku": "006",
  "price": 1500
}

UploadBlobResponse.json (ServiceProvider - Raw!)

{
  "blobUri": "http://localhost:7075/uploadproductinfo/LaptopM4006.json"
}

Critical:

❌ NO statusCode/body wrapper
✅ Points to localhost:7075

Example 2: Validation Error

[Fact]
public void CreateProduct_WithoutCategoryId_Returns400()
{
    using (ITestRunner testRunner = CreateTestRunner())
    {
        // ❌ No mocks - fails before API calls

        var response = testRunner.TriggerWorkflow(
            new StringContent(@"{ ""name"": ""Test"" }",
                Encoding.UTF8, "application/json"),
            HttpMethod.Post);

        // ✅ Assert
        Assert.True(testRunner.WorkflowWasTerminated);
        Assert.Equal(HttpStatusCode.BadRequest, response.StatusCode);
        Assert.Equal(ActionStatus.Skipped,
            testRunner.GetWorkflowActionStatus("CreateProduct"));
    }
}

Example 3: API Error Handling

[Fact]
public void CreateProduct_WhenApiFails_Returns500()
{
    using (ITestRunner testRunner = CreateTestRunner())
    {
        // ❌ Mock API failure
        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPost()
                .WithPath(PathMatchType.Contains, "/Products"))
            .RespondWith(MockResponseBuilder.Create()
                .WithInternalServerError());

        var response = testRunner.TriggerWorkflow(
            new StringContent(@"{
                ""name"": ""Test"",
                ""categoryId"": 1
            }", Encoding.UTF8, "application/json"),
            HttpMethod.Post);

        // ✅ Assert error handling
        Assert.True(testRunner.WorkflowWasTerminated);
        Assert.Equal(HttpStatusCode.InternalServerError, response.StatusCode);
        Assert.Equal(ActionStatus.Failed,
            testRunner.GetWorkflowActionStatus("TryProcessProduct"));
    }
}

Example 4: Request Inspection

[Fact]
public void CreateProduct_SetsCorrectMetadata()
{
    using (ITestRunner testRunner = CreateTestRunner())
    {
        // ... setup all mocks ...

        testRunner.TriggerWorkflow(/* payload */);

        // 🔍 Inspect actual request
        var mockRequests = testRunner.MockRequests;
        var metadataReq = mockRequests.FirstOrDefault(r =>
            r.Method == HttpMethod.Put &&
            r.RequestUri.ToString().Contains("uploadproductinfo"));

        // ✅ Verify header
        metadataReq.Should().NotBeNull();
        metadataReq.Headers.Should().ContainKey("x-ms-meta-productdoc");
        metadataReq.Headers["x-ms-meta-productdoc"].First()
            .Should().Be("LaptopM4006.json");
    }
}

Example 5: Simple HTTP Workflow

[Fact]
public void BlobSearch_ReturnsResults()
{
    using (ITestRunner testRunner = CreateTestRunner())
    {
        var searchResp = LoadMockData("BlobSearchResponse.json");

        testRunner.AddMockResponse(
            MockRequestMatcher.Create()
                .UsingPost()
                .WithPath(PathMatchType.Contains, "/BlobMetadataSearch"))
            .RespondWith(MockResponseBuilder.Create()
                .WithSuccess()
                .WithContentAsJson(searchResp));

        var response = testRunner.TriggerWorkflow(
            new StringContent(@"{
                ""container"": ""products"",
                ""metadataKey"": ""productdoc"",
                ""metadataValue"": ""LaptopM4""
            }", Encoding.UTF8, "application/json"),
            HttpMethod.Post);

        Assert.Equal(WorkflowRunStatus.Succeeded, testRunner.WorkflowRunStatus);

        var json = JObject.Parse(response.Content.ReadAsStringAsync().Result);
        Assert.Equal("success", json["status"]?.ToString());
        Assert.Equal(2, json["count"]?.Value<int>());
    }
}

Testing Strategy Matrix

Scenario	Test	Verifies
Happy Path	All actions succeed	Status, actions, response
Validation	Missing field	Terminate, 400, skipped actions
API Error	External fail	Error handling, 500
Empty Results	No data	Success, count=0
Request	Payload check	Headers, content correct

Running Tests

# Start Azurite
npx azurite --silent --location ./.azurite

# Run tests
dotnet test --filter "FullyQualifiedName~LogicApp"

# Single test with logging
LOGICAPPUNIT_TESTLOGGER_VERBOSITY=Trace \
  dotnet test --filter "FullyQualifiedName~LogicApps"

Expected Output:

Debugging Quick Reference

🐛 Mock Requests Count = 0

grep "@appsetting" parameters.json
cat testConfiguration.json | grep "externalApiUrlsToMock"

🐛 Built-In Connector Null

// ❌ WRONG
{ "statusCode": "OK", "body": { "blobUri": "..." } }

// ✅ CORRECT
{ "blobUri": "http://localhost:7075/..." }

🐛 Action Skipped

// Find which action failed first
Console.WriteLine($"CreateProduct: {testRunner.GetWorkflowActionStatus("CreateProduct")}");
Console.WriteLine($"uploadblob: {testRunner.GetWorkflowActionStatus("uploadblob")}");

Key Takeaways

Structure

✅ One test class per workflow
✅ MockData in JSON files
✅ Helper for config management

Patterns

✅ HTTP actions → endpoint path
✅ Built-in connectors → action name + .FromAction()
✅ Dynamic URLs → PathMatchType.Contains

Testing

✅ Test happy AND sad paths
✅ Verify workflow + action statuses
✅ Inspect requests when needed
✅ Keep mock data realistic

Debugging

✅ Check MockRequests count first
✅ Enable writeMockRequestMatchingLogs
✅ Verify response formats
✅ Use focused test filters

DEV Community: Daniel Jonathan

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

3. Filter Chain Tracing

4. Condition Evaluation

5. Variable Panel and Line Map

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

Getting Started

Requirements

Install

Your First Preview

The F5 Launch Config Workflow

Sample Templates

A Typical Debugging Session

Where Local Debugging Fits

Recommended Workflow

Links

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

The Problem Every Logic Apps Developer Hits

What Is Liquid?

DotLiquid: The .NET Flavour Used by Logic Apps

Difference 1 — Filter names are sentence-cased

Difference 2 — DividedBy truncates when both operands are whole numbers

Difference 3 — Sort is case-insensitive

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

Difference 5 — Some standard filters are missing or renamed

Difference 6 — The content wrapper

Quick reference

The Core Syntax You Will Use Daily

Output

Assign (variables)

Loops

Conditionals

Filter chains

A Real-World Example: B2B Sales Order Transform

Output Is Not Just JSON

The Pain: Flying Blind

What Comes Next

Teaching Coding Agent to Write XSLT — The Hook in Action

Step 1: XSLT 1.0 with inline C

The prompt

What Claude reads first

The write sequence

What the hook catches: two classes of failure

Silent data loss — the namespace bug

Hard compile failure — the C# syntax error

Step 2: XSLT 2.0 with Saxon

Step 3: LML compiled to XSLT 3.0

The prompt

The dependency chain

The custom functions

The LML file

The fixing cycle

Three engines, one result

What you actually see in VS Code

The full picture

Teaching Coding Agent to Write XSLT — The Hook Chain

PostToolUse hooks

Hook 1: LML compile

The compiler: lml-compile

The hook

Hook 2: Transform runner

How the hooks interact

The feedback loop

Shell bugs worth knowing

The pattern generalises

Teaching Coding Agent to Write XSLT — Building a Domain Skill

What is a Claude Code skill?

Mode detection

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`

The `.csproj`