Trigger Orchestration from External Client App

[marcd123]

@cgillum This is not exactly a SQL Service Durable Task Hub issue, but I would like to know what is the recommend approach for solving the issue below while using SQL Service Durable Task Hubs. You can refer to this public repo to reproduce this on AKS:

https://github.com/marcd123/durabletasktest

When we deploy our Durable Function app to AKS, HTTP (HTTP-Starter) and Non-HTTP (Orchestrator/Activity) functions are separated into two deployments.

Because both deployments have the same host.json and local.settings.json, and are thus pointing to the same SQL task hub - I would think having separate deployments would be fine.

However, when we trigger our HTTP-Starter (OrchClient) which is supposed to trigger the Orchestrator (HelloOrchestrator) in a separate deployment, we get this exception from HTTP-Starter saying the orchestrator function could not be found....

Exception: Exception: The function 'HelloOrchestrator' doesn't exist, is disabled, or is not an orchestrator function. Additional info: No orchestrator functions are currently registered!

From what I've read elsewhere, this is because my HTTP function app is checking for the Orchestrator functions locally, which have actually been separated out to another deployment.

I have also read that it may be possible to bypass this local check for the function by using some ExternalClient binding ((Azure/azure-functions-core-tools#2345 (comment))), but I've only seen C# project examples and am unsure how/if this ExternalClient binding can be used within host.json or individual function.json bindings.

Is it possible to bypass this local check with ExternalClient binding in a Python Function app, and if so could you please provide an example of the host.json/function.json configuration?

[cgillum]

Hey @marcd123, try adding a "externalClient": true setting to the function.json file for your HTTP trigger functions that use the durableClient binding. That should disable the validation that is causing the exception you are seeing.

Here's an example function.json for an HTTP trigger function:

function.json

{
  "bindings": [
    {
      "authLevel": "anonymous",
      "name": "req",
      "type": "httpTrigger",
      "direction": "in",
      "route": "orchestrators/{functionName}",
      "methods": ["post"]
    },
    {
      "name": "$return",
      "type": "http",
      "direction": "out"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in",
      "externalClient": true
    }
  ]
}

Your function.json might be a little different depending on how you set up your HTTP trigger function, but this is an example based on a same HTTP-triggered function that uses the durable client binding to start an orchestration. You shouldn't need any changes to host.json or to the app code.

[marcd123]

I modified my HTTP-starter's function.json as you described. I have tested this deployed to AKS and my HTTP-Starter can now trigger my Orchestrator in a separate deployment!

Thank you very much for providing this function.json example! I've actually been searching for this answer for days and am so happy this is resolved.

I didn't see any specific documentation about this function splitting and how to handle it using external client settings. I think it would be a very important thing to include in official documentation.

IMO this would be a great place to mention the HTTP/Non-HTTP function splitting and provide examples of using the externalClient setting for both C# and non C# projects:

https://docs.microsoft.com/en-us/azure/azure-functions/functions-kubernetes-keda

There is already a Github issue for adding this documentation on the Azure Functions Durable Extension repo:

https://github.com/Azure/azure-functions-durable-extension/issues/1600

[cgillum]

Thanks @marcd123 for linking to the documentation issue in the Durable Functions repo. I'll go ahead and close this issue now since there isn't anything to track for the MSSQL backend specifically.