DEV Community

Daniel Jonathan
Daniel Jonathan

Posted on

Debugging Logic Apps Data Mapper XSLT Locally

#xsl #logicapps #datamapper #vscode

If you're working with Azure Logic Apps Data Mapper, you know the pain: you design a beautiful mapping in the visual editor, save it, test it… and then realize the transformation doesn’t work as expected. Debugging inside the designer? Not ideal.

Here's how to debug your Logic Apps Data Mapper XSLT locally using the XSLT Debugger extension for VS Code.

The Problem

Logic Apps Data Mapper generates XSLT behind the scenes. While it has a “Test Map” feature that lets you run transformations with sample data, it doesn’t provide any real debugging tools. When something goes wrong:

  • You can’t set breakpoints in your current XSLT file.
  • You can’t inspect variables during transformation.
  • You’re debugging by trial and error: modify → save → test → repeat.

There’s a better way.

What You Need

  • VS Code with your Logic Apps project open
  • XSLT Debugger extension installed from VS Code Marketplace
  • Sample XML files for testing your transformations

[Screenshot: XSLT Debugger extension installed in VS Code]

The Workflow

1. One-Time Setup: Add Debug Configuration

In your Logic App workspace, update .vscode/launch.json:

{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "xslt",
      "request": "launch",
      "name": "Debug Data Mapper XSLT",
      "program": "${workspaceFolder}/Artifacts/Maps/YourMap.xslt",
      "input": "${workspaceFolder}/Artifacts/Maps/sample-input.xml",
      "output": "${workspaceFolder}/Artifacts/Maps/out/output.xml"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

Important: This doesn't affect your existing mappings or Logic App configuration at all. It's purely for local debugging.

[Screenshot: launch.json configuration]

2. Edit Your Data Mapper (As Usual)

  • Open your existing data mapper (.lml file) or create a new one
  • Make changes in the visual mapper interface
  • Save — this automatically generates/updates the XSLT file

You don't change your workflow. The mapper still generates XSLT like it always does.

[Screenshot: Logic Apps Data Mapper visual editor]

3. Debug the Generated XSLT

  • Open the generated XSLT file (usually in Artifacts/Maps/)
  • Set breakpoints on any xsl:template, xsl:variable, or transformation logic
  • Press F5 or go to Debug panel → Start Debugging

[Screenshot: XSLT file with breakpoints set]

4. Step Through and Inspect

Once debugging starts, you get full visibility into your transformation:

Auto-Captured Variables:

  • All XSLT variables appear automatically in the Variables panel
  • See exactly what values your mapper is producing at each step
  • Understand why a field mapping isn't working
  • Inspect complex nested structures

Watch Panel:

  • Add custom XPath expressions to the Watch panel (similar to .NET debugging)
  • Select any XPath during debugging and add it to watch
  • Enter expressions like /ns0:Order/Items/Item[1]/Price or node references
  • Evaluate expressions against your current context in real-time

Step through your transformation:

  • Step over / Step into / Continue through templates
  • See exactly how data flows through your mappings

[Screenshot: Debugging session showing Variables and Watch panels]

5. View Transformation Output

As your transformation runs, you can see:

  • Debug console showing variable captures and execution flow
  • Output file being generated with transformed XML
  • Debug logs showing exactly what the XSLT engine is doing

[Screenshot: Debug console and transformation output]

Key Features for Logic Apps Developers

.NET-Based XSLT Engine

The debugger uses a .NET XSLT engine, which provides high compatibility with Azure Logic Apps' transformation runtime. While not identical to Logic Apps' managed environment, it gives you reliable local debugging that closely mirrors production behavior.

Important: Local debugging uses your local .NET runtime, while Logic Apps runs in Azure's managed environment. Most transformations will behave identically, but there may be edge cases where runtime differences occur.

Current Limitations

The debugger is designed to stay simple and stable, focusing on practical debugging scenarios:

  • No step-back support — Debugging is forward-only; you cannot step backwards or rewind to previous execution states.
  • Step debugging scope — Step-into works for basic template calls (xsl:call-template). More complex scenarios like xsl:apply-templates with dynamic matching may have limited step-through support.
  • Variable inspection — Covers @select-based variables and parameters; variables defined with content bodies (e.g., <xsl:variable>...</xsl:variable>) are not yet fully inspected.
  • XSLT engine support — XSLT 1.0 via compiled engine with inline C# extensions; XSLT 2.0/3.0 via Saxon.NET engine.

These design choices prioritise debugging reliability and ease of use over attempting to instrument every edge case in the XSLT specification.

Why This Matters

Before:

  • Edit mapper → Save → Test → Repeat
  • No visibility into transformation steps
  • Hard to pinpoint where mappings go wrong

After:

  • Edit mapper → Save → Debug locally with breakpoints
  • See every variable and transformation step
  • Fix issues before deployment

Result: Faster development, fewer bugs, less guesswork.

Conclusion

Debugging Logic Apps data mappers doesn't have to be a black box. With local XSLT debugging, you get the same iterative development experience you have with regular code — breakpoints, variable inspection, and step-through debugging.

Try it out:
👉 XSLT Debugger - Windows
👉 XSLT Debugger - macOS

Debug smarter, deploy faster.

Top comments (0)