Partager via

Liaisons pour Fonctions durables (Azure Functions)

  • Article

L'extension Durable Functions introduit trois liaisons de déclencheur qui contrôlent l'exécution des fonctions d'orchestrateur, d'entité et d'activité. Elle introduit également une liaison de sortie qui agit comme un client pour l’exécution de Fonctions durables.

Veillez à choisir votre langage de développement Durable Functions en haut de l’article.

Important

Cet article prend en charge les modèles de programmation Python v1 et Python v2 pour Durable Functions.

Modèle de programmation Python v2

Durable Functions est pris en charge dans le nouveau modèle de programmation Python v2. Pour utiliser le modèle v2, vous devez installer le kit de développement logiciel (SDK) Durable Functions, qui est le package PyPI azure-functions-durable, version 1.2.2 ou une version ultérieure. Vous devez également consulter host.json pour vérifier que votre application référence Extension Bundles version 4.x afin d’utiliser le modèle v2 avec Durable Functions.

Vous pouvez fournir des commentaires et des suggestions dans le dépôt Durable Functions SDK pour Python.

Déclencheur d'orchestration

Le déclencheur d’orchestration vous permet de créer des fonctions d’orchestrateur durables. Ce déclencheur s'exécute lorsqu'une nouvelle instance d'orchestration est planifiée et lorsqu'une instance d'orchestration existante reçoit un événement. Parmi les exemples d'événements susceptibles de déclencher les fonctions d'orchestrateur, citons les expirations du minuteur durable, les réponses aux fonctions d'activité et les événements déclenchés par des clients externes.

Lorsque vous créez des fonctions dans .NET, le déclencheur d'orchestration est configuré à l'aide de l'attribut .NET OrchestrationTriggerAttribute.

Pour Java, l’annotation @DurableOrchestrationTrigger est utilisée pour configurer le déclencheur d’orchestration.

Lorsque vous écrivez des fonctions d’orchestrateur, le déclencheur d’orchestration est défini par l’objet JSON suivant dans le tableau bindings du fichier function.json :

{
    "name": "<Name of input parameter in function signature>",
    "orchestration": "<Optional - name of the orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}
  • orchestration correspond au nom de l’orchestration que les clients doivent utiliser lorsqu’ils souhaitent démarrer de nouvelles instances de cette fonction d’orchestrateur. Cette propriété est facultative. Si cette valeur n’est pas spécifiée, le nom de la fonction est utilisé.

Azure Functions prend en charge deux modèles de programmation pour Python. La façon dont vous définissez un déclencheur d’orchestration dépend du modèle de programmation choisi.

Le modèle de programmation Python v2 vous permet de définir un déclencheur d’orchestration à l’aide de l’élément décoratif orchestration_trigger directement dans votre code de fonction Python.

Dans le modèle v2, les déclencheurs et liaisons Durable Functions sont accessibles à partir d’une instance DFApp, une sous-classe de FunctionApp qui exporte additionnellement des éléments décoratifs spécifiques à Durable Functions.

En interne, cette liaison de déclencheur interroge le magasin durable configuré à la recherche de nouveaux événements d'orchestration, tels que des événements de démarrage d'orchestration, des événements d'expiration du minuteur durable, des événements de réponse aux fonctions d'activité et des événements externes déclenchés par d'autres fonctions.

Comportement du déclencheur

Voici quelques remarques concernant le déclencheur d’orchestration :

  • Thread unique : un thread de répartiteur unique est utilisé pour toutes les exécutions d’une fonction d’orchestrateur sur une même instance d’hôte. C'est pourquoi il est important de s'assurer que le code de la fonction d'orchestrateur est efficace et n'effectue aucune opération E/S. Il est également important de s’assurer que ce thread n’effectue aucun travail asynchrone, sauf lorsqu’il attend des types de tâches Fonctions durables spécifiques.
  • Gestion des messages incohérents : les déclencheurs d'orchestration ne prennent en charge aucun message incohérent.
  • Visibilité des messages : les messages du déclencheur d’orchestration sont supprimés de la file d’attente et restent invisibles pour une durée configurable. La visibilité de ces messages est renouvelée automatiquement tant que l’application de la fonction est en cours d’exécution et saine.
  • Valeurs de retour : les valeurs de retour sont sérialisées au format JSON et conservées dans la table d’historique d’orchestration du stockage Azure Table. Ces valeurs de retour peuvent être interrogées par la liaison du client d’orchestration, décrite plus loin.

Avertissement

Les fonctions d’orchestrateur ne doivent jamais utiliser une liaison d’entrée ou de sortie autre que la liaison du déclencheur d’orchestration. Cela pourrait entraîner des problèmes avec l’extension Tâche durable car ces liaisons risquent de ne pas respecter les règles de thread unique et d’E/S. Si vous souhaitez utiliser d'autres liaisons, ajoutez-les à une fonction d'activité appelée à partir de votre fonction d'orchestrateur. Pour plus d'informations sur les contraintes de codage des fonctions d'orchestrateur, consultez la documentation Contraintes liées au code des fonctions d'orchestrateur.

Avertissement

Les fonctions d’orchestrateur ne doivent jamais être déclarées avec la propriété async.

Utilisation du déclencheur

La liaison du déclencheur d’orchestration prend en charge à la fois les entrées et les sorties. Voici quelques éléments à connaître concernant la gestion des entrées et des sorties :

  • entrées : les déclencheurs d'orchestration peuvent être appelés avec des entrées, accessibles via l'objet d'entrée de contexte. Toutes les entrées doivent être de type JSON sérialisable.
  • sorties : les déclencheurs d’orchestration prennent en charge les valeurs de sortie ainsi que les entrées. La valeur de retour de la fonction sert à affecter la valeur de sortie et doit être de type JSON sérialisable.

Exemple de déclencheur

L'exemple de code suivant illustre une simple fonction d’orchestrateur « Hello World ». Notez que cet exemple d’orchestrateur ne planifie pas réellement de tâches.

L’attribut spécifique utilisé pour définir le déclencheur varie selon que vous exécutez vos fonctions C# dans le processus ou dans un processus de travail isolé.

[FunctionName("HelloWorld")]
public static string Run([OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    return $"Hello {name}!";
}

Notes

Le code précédent correspond à Durable Functions 2.x. Pour Durable Functions 1.x, vous devez utiliser DurableOrchestrationContext au lieu de IDurableOrchestrationContext. Pour en savoir plus sur les différences entre les versions, consultez l’article Versions de Durable Functions.

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    return `Hello ${name}!`;
});

Notes

La bibliothèque durable-functions prend en charge l'appel de la méthode context.done synchrone lorsque la fonction de générateur se termine.

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.orchestration_trigger(context_name="context")
def my_orchestrator(context):
    result = yield context.call_activity("Hello", "Tokyo")
    return result

param($Context)

$InputData = $Context.Input
$InputData

@FunctionName("HelloWorldOrchestration")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    return String.format("Hello %s!", ctx.getInput(String.class));
}

La plupart des fonctions d’orchestrateur appellent des fonctions d’activité. Voici un exemple « Hello World » qui montre comment appeler une fonction d’activité :

[FunctionName("HelloWorld")]
public static async Task<string> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string name = context.GetInput<string>();
    string result = await context.CallActivityAsync<string>("SayHello", name);
    return result;
}

Notes

Le code précédent correspond à Durable Functions 2.x. Pour Durable Functions 1.x, vous devez utiliser DurableOrchestrationContext au lieu de IDurableOrchestrationContext. Pour en savoir plus sur les différences entre les versions, consultez l’article Versions de Durable Functions.

const df = require("durable-functions");

module.exports = df.orchestrator(function*(context) {
    const name = context.df.getInput();
    const result = yield context.df.callActivity("SayHello", name);
    return result;
});

@FunctionName("HelloWorld")
public String helloWorldOrchestration(
        @DurableOrchestrationTrigger(name = "ctx") TaskOrchestrationContext ctx) {
    String input = ctx.getInput(String.class);
    String result = ctx.callActivity("SayHello", input, String.class).await();
    return result;
}

Déclencheur d'activité

Le déclencheur d’activité vous permet de créer des fonctions appelées par des fonctions d’orchestrateur, appelées fonctions d'activité.

Le déclencheur d’activité est configuré à l’aide de l’attribut .NET ActvityTriggerAttribute.

Le déclencheur d’activité est configuré à l’aide de l’annotation @DurableActivityTrigger.

Le déclencheur d’activité est défini par l’objet JSON suivant du tableau bindings de function.json :

{
    "name": "<Name of input parameter in function signature>",
    "activity": "<Optional - name of the activity>",
    "type": "activityTrigger",
    "direction": "in"
}
  • activity est le nom de l’activité. Cette valeur correspond au nom qu’utilisent les fonctions d’orchestrateur pour appeler cette fonction d’activité. Cette propriété est facultative. Si cette valeur n’est pas spécifiée, le nom de la fonction est utilisé.

La façon dont vous définissez un déclencheur d’activité dépend du modèle de programmation choisi.

Utilisation de l’élément décoratif activity_trigger directement dans le code de votre fonction Python.

En interne, cette liaison de déclencheur interroge le magasin durable configuré à la recherche de nouveaux événements d'exécution d'activité.

Comportement du déclencheur

Voici quelques remarques concernant le déclencheur d’activité :

  • Threading : contrairement au déclencheur d’orchestration, les déclencheurs d’activité ne sont soumis à aucune restriction au niveau du thread ou des opérations d’E/S. Ils peuvent être traités comme des fonctions normales.
  • Gestion des messages incohérents : les déclencheurs d'activité ne prennent en charge aucun message incohérent.
  • Visibilité des messages : les messages du déclencheur d’activité sont supprimés de la file d’attente et restent invisibles pour une durée configurable. La visibilité de ces messages est renouvelée automatiquement tant que l’application de la fonction est en cours d’exécution et saine.
  • Valeurs de retour : les valeurs de retour sont sérialisées au format JSON et conservées dans le magasin durable configuré.

Utilisation du déclencheur

La liaison du déclencheur d’activité prend en charge à la fois les entrées et les sorties, exactement comme le déclencheur d’orchestration. Voici quelques éléments à connaître concernant la gestion des entrées et des sorties :

  • entrées : les déclencheurs d'activité peuvent être appelés avec des entrées provenant d'une fonction d'orchestrateur. Toutes les entrées doivent être de type JSON sérialisable.
  • sorties : les fonctions d’activité prennent en charge les valeurs de sortie ainsi que les entrées. La valeur de retour de la fonction sert à affecter la valeur de sortie et doit être de type JSON sérialisable.
  • métadonnées : les fonctions d'activité .NET peuvent être liées à un paramètre string instanceId pour obtenir l'ID d'instance de l'orchestration d'appel.

Exemple de déclencheur

L'exemple de code suivant illustre une simple fonction d'activité SayHello.

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] IDurableActivityContext helloContext)
{
    string name = helloContext.GetInput<string>();
    return $"Hello {name}!";
}

Le type de paramètre par défaut pour la liaison .NET ActivityTriggerAttribute est IDurableActivityContext (ou DurableActivityContext pour Durable Functions v1). Cependant, les déclencheurs d’activité .NET prennent également en charge la liaison directe avec des types sérialisables au format JSON (notamment les types primitifs). La même fonction peut donc être simplifiée comme suit :

[FunctionName("SayHello")]
public static string SayHello([ActivityTrigger] string name)
{
    return $"Hello {name}!";
}

module.exports = async function(context) {
    return `Hello ${context.bindings.name}!`;
};

Les liaisons JavaScript peuvent également être transmises en tant que paramètres supplémentaires. La même fonction peut donc être simplifiée comme suit :

module.exports = async function(context, name) {
    return `Hello ${name}!`;
};

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.activity_trigger(input_name="myInput")
def my_activity(myInput: str):
    return "Hello " + myInput

param($name)

"Hello $name!"

@FunctionName("SayHello")
public String sayHello(@DurableActivityTrigger(name = "name") String name) {
    return String.format("Hello %s!", name);
}

Utilisation des liaisons d’entrée et de sortie

Vous pouvez utiliser des liaisons d’entrée et de sortie standard en plus de la liaison de déclencheur d’activité.

Par exemple, vous pouvez prendre l’entrée de votre liaison d’activité et envoyer un message à un Event Hub à l’aide de la liaison de sortie Event Hubs :

{
  "bindings": [
    {
      "name": "message",
      "type": "activityTrigger",
      "direction": "in"
    },
    {
      "type": "eventHub",
      "name": "outputEventHubMessage",
      "connection": "EventhubConnectionSetting",
      "eventHubName": "eh_messages",
      "direction": "out"
  }
  ]
}

module.exports = async function (context) {
    context.bindings.outputEventHubMessage = context.bindings.message;
};

Client d’orchestration

La liaison du client d’orchestration vous permet d’écrire des fonctions qui interagissent avec les fonctions d’orchestrateur. Ces fonctions sont souvent appelées fonctions clientes. Par exemple, vous pouvez agir sur les instances de l’orchestration de l’une des manières suivantes :

  • Les démarrer.
  • Interroger leur état.
  • Les arrêter.
  • Leur envoyer des événements pendant qu’elles sont exécutées.
  • Purger l’historique d’instance.

Vous pouvez établir une liaison avec le client d'orchestration à l'aide de l'attribut DurableClientAttribute (OrchestrationClientAttribute dans Durable Functions v1.x).

Vous pouvez lier au client d’orchestration à l’aide de l’annotation @DurableClientInput.

Le déclencheur de client durable est défini par l’objet JSON suivant du tableau bindings de function.json :

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "orchestrationClient",
    "direction": "in"
}
  • taskHub : utilisé dans les scénarios où plusieurs applications de fonction partagent le même compte de stockage, mais doivent être isolées les unes des autres. Si ce champ n’est pas spécifié, la valeur host.json sera utilisée par défaut. Cette valeur doit correspondre à la valeur utilisée par les fonctions d’orchestrateur cible.
  • connectionName : nom d’un paramètre d’application contenant une chaîne de connexion du compte de stockage. Le compte de stockage représenté par cette chaîne de connexion doit être le même que celui utilisé par les fonctions d’orchestrateur cible. Si elle n’est pas spécifiée, la chaîne de connexion du compte de stockage par défaut pour l’application de la fonction est utilisée.

Notes

Dans la plupart des cas, nous vous recommandons d’omettre ces propriétés et de vous appuyer sur le comportement par défaut.

La façon dont vous définissez un déclencheur de client durable dépend du modèle de programmation choisi.

Utilisation de l’élément décoratif durable_client_input directement dans le code de votre fonction Python.

Utilisation du client

Vous établissez généralement une liaison avec IDurableClient (DurableOrchestrationClient dans Durable Functions v1.x), ce qui vous donne un accès total à toutes les API clientes d'orchestration prises en charge par Durable Functions.

Vous êtes généralement lié à la classe DurableClientContext.

Vous devez utiliser le kit de développement logiciel (SDK) spécifique au langage pour accéder à un objet client.

Voici un exemple de fonction déclenchée par une file d'attente qui démarre une orchestration « HelloWorld ».

[FunctionName("QueueStart")]
public static Task Run(
    [QueueTrigger("durable-function-trigger")] string input,
    [DurableClient] IDurableOrchestrationClient starter)
{
    // Orchestration input comes from the queue message content.
    return starter.StartNewAsync<string>("HelloWorld", input);
}

Notes

Le code C# précédent correspond à Durable Functions 2.x. Pour Durable Functions 1.x, vous devez utiliser l’attribut OrchestrationClient au lieu de l’attribut DurableClient, et vous devez utiliser le type de paramètre DurableOrchestrationClient au lieu de IDurableOrchestrationClient. Pour en savoir plus sur les différences entre les versions, consultez l’article Versions de Durable Functions.

function.json

{
  "bindings": [
    {
      "name": "input",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

index.js

const df = require("durable-functions");

module.exports = async function (context) {
    const client = df.getClient(context);
    return instanceId = await client.startNew("HelloWorld", undefined, context.bindings.input);
};

run.ps1

param([string] $input, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName $FunctionName -Input $input

import azure.functions as func
import azure.durable_functions as df

myApp = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)

@myApp.route(route="orchestrators/{functionName}")
@myApp.durable_client_input(client_name="client")
async def durable_trigger(req: func.HttpRequest, client):
    function_name = req.route_params.get('functionName')
    instance_id = await client.start_new(function_name)
    response = client.create_check_status_response(req, instance_id)
    return response

function.json

{
  "bindings": [
    {
      "name": "input",
      "type": "queueTrigger",
      "queueName": "durable-function-trigger",
      "direction": "in"
    },
    {
      "name": "starter",
      "type": "durableClient",
      "direction": "in"
    }
  ]
}

run.ps1

param([string]$InputData, $TriggerMetadata)

$InstanceId = Start-DurableOrchestration -FunctionName 'HelloWorld' -Input $InputData

@FunctionName("QueueStart")
public void queueStart(
        @QueueTrigger(name = "input", queueName = "durable-function-trigger", connection = "Storage") String input,
        @DurableClientInput(name = "durableContext") DurableClientContext durableContext) {
    // Orchestration input comes from the queue message content.
    durableContext.getClient().scheduleNewOrchestrationInstance("HelloWorld", input);
}

Vous trouverez plus d’informations sur le démarrage des instances dans la section Gestion d’instance.

Déclencheur d’entité

Les déclencheurs d’entité vous permettent de créer des fonctions d'entité. Ce déclencheur prend en charge le traitement des événements pour une instance d’entité spécifique.

Notes

Les déclencheurs d’entité sont disponibles à partir de la version Durable Functions 2.x.

En interne, cette liaison de déclencheur interroge le magasin durable configuré à la recherche de nouvelles opérations d'entité à exécuter.

Le déclencheur d’entité est configuré à l’aide de l’attribut .NET EntityTriggerAttribute.

Le déclencheur d’entité est défini par l’objet JSON suivant du tableau bindings de function.json :

{
    "name": "<Name of input parameter in function signature>",
    "entityName": "<Optional - name of the entity>",
    "type": "entityTrigger",
    "direction": "in"
}

Par défaut, le nom d’une entité est le nom de la fonction.

Notes

Les déclencheurs d’entité ne sont pas encore pris en charge pour Java.

La façon dont vous définissez un déclencheur d’entité dépend du modèle de programmation choisi.

Utilisation de l’élément décoratif entity_trigger directement dans le code de votre fonction Python.

Comportement du déclencheur

Voici quelques remarques concernant le déclencheur d’entité :

  • Thread unique : un thread de répartiteur unique est utilisé pour traiter les opérations d’une entité donnée. Si plusieurs messages sont envoyés simultanément à une même entité, les opérations sont traitées tour à tour.
  • Gestion des messages incohérents : les déclencheurs d'entité ne prennent en charge aucun message incohérent.
  • Visibilité des messages : les messages du déclencheur d’entité sont supprimés de la file d’attente et restent invisibles pour une durée configurable. La visibilité de ces messages est renouvelée automatiquement tant que l’application de la fonction est en cours d’exécution et saine.
  • Valeurs de retour : les fonctions d'entité ne prennent pas en charge les valeurs de retour. Des API spécifiques peuvent être utilisées pour enregistrer l’état ou transmettre les valeurs aux orchestrations.

Toute modification d’état apportée à une entité lors de son exécution perdure automatiquement au terme de l'exécution.

Pour plus d'informations et d'exemples sur la définition et l'interaction avec les déclencheurs d'entité, consultez la documentation relative aux entités durables.

Client d'entité

La liaison du client d’entité vous permet de déclencher des fonctions d'entité de manière asynchrone. Ces fonctions sont parfois appelées fonctions clientes.

Vous pouvez établir une liaison avec le client d'entité en utilisant l'attribut .NET DurableClientAttribute dans les fonctions de bibliothèque de classes .NET.

Notes

[DurableClientAttribute] permet de créer une liaison avec le client d'orchestration.

Le client d’entité est défini par l’objet JSON suivant du tableau bindings de function.json :

{
    "name": "<Name of input parameter in function signature>",
    "taskHub": "<Optional - name of the task hub>",
    "connectionName": "<Optional - name of the connection string app setting>",
    "type": "durableClient",
    "direction": "in"
}
  • taskHub : utilisé dans les scénarios où plusieurs applications de fonction partagent le même compte de stockage, mais doivent être isolées les unes des autres. Si ce champ n’est pas spécifié, la valeur host.json sera utilisée par défaut. Cette valeur doit correspondre à la valeur utilisée par les fonctions d’entité cible.
  • connectionName : nom d’un paramètre d’application contenant une chaîne de connexion du compte de stockage. Le compte de stockage représenté par cette chaîne de connexion doit être le même que celui utilisé par les fonctions d’entité cible. Si elle n’est pas spécifiée, la chaîne de connexion du compte de stockage par défaut pour l’application de la fonction est utilisée.

Notes

Dans la plupart des cas, nous vous recommandons d’omettre les propriétés facultatives et de vous appuyer sur le comportement par défaut.

La façon dont vous définissez un client d’entité dépend du modèle de programmation choisi.

Utilisation de l’élément décoratif durable_client_input directement dans le code de votre fonction Python.

Notes

Les clients d’entité ne sont pas encore pris en charge pour Java.

Pour plus d'informations et d'exemples sur l'interaction avec les entités en tant que client, consultez la documentation relative aux Entités durables.

Paramètres host.json

Paramètres de configuration de Fonctions durables.

Notes

Toutes les versions principales de Durable Functions sont prises en charge sur toutes les versions du runtime Azure Functions. Toutefois, le schéma de la configuration host.json est légèrement différent selon la version du runtime Azure Functions et la version d’extension Durable Functions que vous utilisez. Les exemples suivants sont destinés à être utilisés avec Azure Functions 2.0 et 3.0. Dans les deux exemples, si vous utilisez Azure Functions 1.0, les paramètres disponibles sont les mêmes, mais la section « durableTask » de host.json doit être dans la racine de la configuration host.json plutôt que sous la forme d’un champ sous « extensions ».

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": true,
      "useTablePartitionManagement": false,
      "workItemQueueVisibilityTimeout": "00:05:00",
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "notifications": {
      "eventGrid": {
        "topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
        "keySettingName": "EventGridKey",
        "publishRetryCount": 3,
        "publishRetryInterval": "00:00:30",
        "publishEventTypes": [
          "Started",
          "Completed",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "storeInputsInOrchestrationHistory": false
  }
 }
}

Les noms de hubs de tâches doivent commencer par une lettre et contenir uniquement des lettres et des chiffres. S’il n’est pas spécifié, le nom du hub de tâches par défaut d’une application de fonction est TestHubName. Pour en savoir plus, consultez la section relative aux hubs de tâches.

Propriété Default Description
hubName TestHubName (DurableFunctionsHub si vous utilisez Durable Functions 1.x) D'autres noms de hub de tâches peuvent être utilisés pour isoler plusieurs applications Durable Functions les unes des autres, même si elles s'appuient sur le même principal de stockage.
controlQueueBatchSize 32 Nombre de messages à extraire de la file d’attente de contrôle en une seule fois.
controlQueueBufferThreshold Plan de consommation pour Python : 32
Plan de consommation pour JavaScript et C# : 128
Plan dédié/Premium : 256		 Nombre de messages de file d’attente de contrôle qui peuvent être mis en mémoire tampon à la fois, auquel cas le répartiteur attend avant de retirer des messages supplémentaires de la file d’attente.
partitionCount 4 Nombre de partitions pour la file d’attente de contrôle. Doit être un entier positif compris entre 1 et 16.
controlQueueVisibilityTimeout 5 minutes Délai d’expiration de la visibilité des messages supprimés de la file d’attente de contrôle.
workItemQueueVisibilityTimeout 5 minutes Délai d’expiration de la visibilité des messages supprimés de la file d’attente des éléments de travail.
maxConcurrentActivityFunctions Plan de consommation : 10
Plan dédié/Premium : 10 fois le nombre de processeurs présents sur l’ordinateur actuel		 Nombre maximal de fonctions d’activité pouvant être traitées simultanément sur une seule instance d’hôte.
maxConcurrentOrchestratorFunctions Plan de consommation : 5
Plan dédié/Premium : 10 fois le nombre de processeurs présents sur l’ordinateur actuel		 Nombre maximal de fonctions d’orchestrateur pouvant être traitées simultanément sur une seule instance d’hôte.
maxQueuePollingInterval 30 secondes Intervalle d’interrogation de la file d’attente des éléments de travail et de contrôle maximum, indiqué au format hh:mm:ss. Des valeurs plus élevées peuvent entraîner une plus grande latence lors du traitement des messages. Des valeurs plus faibles peuvent entraîner des coûts de stockage plus importants, suite à un nombre plus important de transactions de stockage.
connectionName (2.7.0 et versions ultérieures)
connectionStringName (2.x)
azureStorageConnectionStringName (1.x)		 AzureWebJobsStorage Nom d’un paramètre d’application ou d’une collection de paramètres spécifiant la façon de se connecter aux ressources de Stockage Azure sous-jacentes. Quand un seul paramètre d’application est fourni, il doit s’agir d’une chaîne de connexion à Stockage Azure.
trackingStoreConnectionName (2.7.0 et versions ultérieures)
trackingStoreConnectionStringName		 Nom d’un paramètre d’application ou d’une collection de paramètres d’application spécifiant la façon de se connecter aux tables Historique et Instances. Quand un seul paramètre d’application est fourni, il doit s’agir d’une chaîne de connexion à Stockage Azure. S’il n’est pas spécifié, la connexion connectionStringName (Durable 2.x) ou azureStorageConnectionStringName (Durable 1.x) est utilisée.
trackingStoreNamePrefix Préfixe à utiliser pour les tables d’historique et d’instances lorsque le paramètre trackingStoreConnectionStringName est spécifié. S’il n’est pas défini, la valeur du préfixe par défaut correspond à DurableTask. Si le paramètre trackingStoreConnectionStringName n’est pas spécifié, les tables d’historique et d’instances utilisent la valeur hubName en tant que préfixe, et tous les paramètres relatifs à trackingStoreNamePrefix sont ignorés.
traceInputsAndOutputs false Valeur indiquant s’il faut tracer les entrées et sorties des appels de fonction. Lors du traçage d’événements d’exécution de fonctions, le nombre d’octets est inclus par défaut dans les entrées et les sorties sérialisées pour les appels de fonction. Ce comportement fournit un minimum d’informations sur l’apparence des entrées et sorties, sans encombrer les journaux d’activité ni exposer accidentellement des informations sensibles. La définition de cette propriété sur True amène la journalisation de la fonction par défaut à consigner la totalité du contenu des entrées et sorties de fonction.
traceReplayEvents false Valeur indiquant s’il faut écrire les événements de relecture d’orchestration à Application Insights.
eventGridTopicEndpoint URL du point de terminaison de la rubrique personnalisée Azure Event Grid. Lorsque cette propriété est définie, les événements de notification du cycle de vie de l’orchestration sont publiés sur ce point de terminaison. Cette propriété prend en charge la résolution de paramètres de l’application.
eventGridKeySettingName Nom du paramètre d’application contenant la clé utilisée pour l’authentification à l’aide de la rubrique personnalisée Azure Event Grid sur EventGridTopicEndpoint.
eventGridPublishRetryCount 0 Nombre de nouvelles tentatives à effectuer en cas d’échec de la publication de la rubrique Event Grid.
eventGridPublishRetryInterval 5 minutes L’intervalle avant nouvelle tentative de publication Event Grid au format hh:mm:ss.
eventGridPublishEventTypes Liste des types d’événement à publier sur Event Grid. Si elle n’est pas spécifiée, cela signifie que tous les types d’événement seront publiés. Les valeurs autorisées sont Started, Completed, Failed et Terminated.
useAppLease true Quand la valeur est true, les applications nécessitent l’acquisition d’un bail d’objet blob au niveau de l’application pour traiter les messages du hub de tâches. Pour plus d’informations, consultez la documentation Récupération d’urgence et géodistribution. Disponible à partir de la version 2.3.0.
useLegacyPartitionManagement false Quand sa valeur est false, utilise un algorithme de gestion des partitions qui réduit le risque d’exécuter une fonction en double lors du scale-out. Disponible à partir de la version 2.3.0.
useTablePartitionManagement false Lorsque défini sur true, il utilise un algorithme de gestion de partition conçu pour réduire les coûts des comptes Stockage Azure V2. Disponible à partir de la version 2.10.0. Cette fonctionnalité est actuellement en préversion et n’est pas encore compatible avec le plan Consommation.
useGracefulShutdown false (Préversion) Activez l’arrêt approprié pour réduire le risque d’échecs d’arrêt de l’hôte dans les exécutions de fonctions in-process.
maxEntityOperationBatchSize(2.6.1) Plan de consommation : 50
Plan dédié/Premium : 5000		 Le nombre maximal d’opérations d’entité traitées comme un lot. Si la valeur est 1, le traitement par lot est désactivé et chaque message d’opération est traité par un appel de fonction distinct.
storeInputsInOrchestrationHistory false Lorsque défini sur true, indique au Durable Task Framework d’enregistrer les entrées d’activité dans la table d’historique. Cela permet l’affichage des entrées de fonction d’activité lors de l’interrogation de l’historique d’orchestration.

La plupart de ces paramètres sont destinés à l’optimisation des performances. Pour plus d’informations, consultez Performances et échelle.

Étapes suivantes

Référence sur l'API HTTP intégrée pour la gestion des instances