Support for Logic App (Standard)

[ronaldbosma]

Hi.

I'm considering contributing to azd to add support for Logic App (Standard), which would address #812. Before I get started, I wanted to check whether the approach I have in mind makes sense.

Currently, when deploying to a Logic App (Standard), you need to configure js as the language. This ensures the assets are zipped and deployed to the Logic App by configuring function as the host. However, this introduces an unnecessary dependency on Node.

A Logic App can also include a custom code project with custom functions. The project can target either .NET Framework or .NET 8 and needs to be built before it is packaged into the Logic App zip file. I’m currently using a prepackage hook for this. For example:

services:
  logicApp:
    project: ./src/logicApp
    dist: Workflows
    host: function
    language: js
    hooks:
      prepackage:
        shell: pwsh
        run: ../../hooks/prepackage-logicapp-build-functions-project.ps1
        interactive: true

It would be great to have native support for Logic App (Standard) projects so that the dependency on Node can be removed, as well as the need for a prepackage hook when a custom code project is included.

Using function as the host makes sense to me, since Logic Apps use the Azure Functions runtime under the hood. Therefore, introducing a new language option seems like the appropriate approach.

For example, consider the following project structure where the Logic App includes a custom code project:

└── src
    └── logicApp
        ├── Functions
        │   ├── MyFunctions.cs
        │   ├── Functions.csproj
        │   └── ...
        └── Workflows
            ├── my-workflow-1
            │   └── workflow.json
            ├── my-workflow-2
            │   └── workflow.json
            └── ...

You could then specify the following in azure.yaml:

services:
  logicApp:
    project: ./src/logicApp
    dist: Workflows
    host: function
    language: workflow
    customCodeProject: Functions

The workflow language (or another suitable name) would indicate that this is a Logic App project containing workflows.

The customCodeProject property would be optional and would indicate that a custom code project is included and needs to be built first.

[vhvb1989]

@rajeshkamal5050 @kristenwomack

[ronaldbosma]

Hi @rajeshkamal5050. In #812 (comment) you suggest that the extension framework might be a good fit to add Logic App Support. Is it possible to introduce a new language through an extension as I suggest above (since we only need packaging) or would we have to build a 'full' service target provider that not only implements packaging but also publish/deploy (which would be the same as when the host is function)? If it's the latter, then I think adding the logic to azd directly might make more sense. Do you agree?

[wbreza]

Thanks for the detailed proposal! You've identified a real gap in azd's support for Logic App (Standard), and your approach is sound. The good news is that our extension framework is designed precisely for this use case, and it can address your goal without requiring extensive core changes.

The Path Forward: Extension Framework + Framework Service Provider

Your proposal to add language: workflow aligns perfectly with azd's Framework Service Provider capability. Here's how this works:

What an Extension Can Do

An extension can register a custom Framework Service Provider for the workflow language that:

1. Validates project structure - Ensures Workflows/ directory exists and workflows.json files are present
2. Handles the build phase - Builds the optional .NET custom code project
3. Creates the deployment package - Zips workflows and compiled functions into the format Logic App expects
4. Eliminates the Node.js dependency - No need for language: js anymore

Architecture

# azure.yaml
services:
  logicApp:
    project: ./src/logicApp
    dist: Workflows
    host: function
    language: workflow        # Handled by extension's FrameworkServiceProvider
    customCodeProject: Functions  # Custom property - read by the extension

Your extension would implement lifecycle methods like:

 // Initialize - Validate project structure
 func (p *WorkflowFrameworkService) Initialize(ctx context.Context, serviceConfig *ServiceConfig) error {
     // Verify Workflows/ directory exists, validate workflow.json files
 }
 
 // Build - Compile custom code project if configured
 func (p *WorkflowFrameworkService) Build(ctx context.Context, serviceConfig *ServiceConfig, ...) (*ServiceBuildResult, error) {
     // Read custom property from serviceConfig
     customCodeProject := serviceConfig.GetProperty("customCodeProject")
     
     if customCodeProject != "" {
         // Build the .NET project: dotnet build ./Functions/Functions.csproj
         // Copy compiled DLLs to staging directory
     }
 }
 
 // Package - Create deployment zip
 func (p *WorkflowFrameworkService) Package(ctx context.Context, serviceConfig *ServiceConfig, ...) (*ServicePackageResult, error) {
     // Create Logic App zip containing:
     // - All workflow.json files
     // - host.json, connections.json, local.settings.json
     // - Compiled functions (if customCodeProject was built)
 }

Key Capability: Custom Service Properties

The Framework Service Provider receives a ServiceConfig object that allows the extension to:

• Read custom properties - Access customCodeProject: Functions from azure.yaml
• Write/set properties - Modify or add properties as needed
• Access built-in properties - Get standard service config like project, dist, host, language

This means no core changes needed - the extension reads whatever custom properties you define in azure.yaml.

Implementation Path

1. Create the extension azd x init
   • Select Go language, enable "framework-service-provider" capability
2. Implement FrameworkServiceProvider
   • Skeleton is provided in SDK; you fill in the validation/build/package logic
   • Reference: Extension Framework Services
3. Register with ExtensionHost host := azdext.NewExtensionHost(azdClient).
   WithFrameworkService("workflow", NewWorkflowFrameworkProvider())
4. Test with your project structure services:
   logicApp:
   project: ./src/logicApp
   dist: Workflows
   host: function
   language: workflow
   customCodeProject: Functions # Extension reads this property

Why This is Better Than Modifying Core

• Faster iteration - Your extension can evolve independently of azd releases
• Isolated testing - You control the deployment matrix and test scenarios
• Extensibility - Other workflow engines (Durable Functions, Dapr, etc.) can use their own extensions
• Opt-in - Users who need it install; others aren't affected
• No schema changes - Custom properties don't require core ServiceConfig modifications

Potential Gaps & Support

While the extension framework is built to handle this scenario, there may be unknown gaps or edge cases specific to Logic App deployment (e.g., special handling for connections.json, runtime requirements, Function App runtime compatibility). If you encounter any blockers or find that the extension APIs don't quite support what you need, please let us know. We're happy to work with you to identify and close any gaps in the framework or APIs—this kind of real-world usage helps us improve the extension platform for everyone.

[kristenwomack]

Please tag me on any gaps you discover in the framework as you're working with it @ronaldbosma.

[ronaldbosma]

I've opened PR #8005 with a first version of the extension.