Partager via

Liaisons pour Fonctions durables (Azure Functions)

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é. Il introduit également une liaison de sortie qui agit en tant que client pour l'environnement d'exécution Durable Functions.

Cet article décrit l’utilisation de ces quatre liaisons et fournit des exemples de code. Il fournit également des informations sur les propriétés de configuration Durable Functions dans host.json, le fichier de métadonnées qui contient des paramètres qui affectent toutes les fonctions d’une application de fonction.

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

Les deux versions du modèle de programmation Python pour Azure Functions sont prises en charge par Durable Functions. Étant donné que Python v2 est la version recommandée, des exemples de cet article présentent exclusivement cette version.

Prerequisites

  • Durable Functions SDK, qui est le package du Python Package Index (PyPI)azure-functions-durable, version 1.2.2 ou une version ultérieure
  • Extension bundle version 4.x (ou une version ultérieure), qui est définie dans le fichier projet host.json

Vous pouvez fournir des commentaires et des suggestions dans le référentiel Python du SDK Durable Functions.

Déclencheur d’orchestration

Vous pouvez utiliser le déclencheur d’orchestration pour développer 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. Des exemples d’événements pouvant déclencher des fonctions d’orchestrateur incluent des expirations durables du minuteur, des réponses de fonction d’activité et des événements déclenchés par des clients externes.

Lorsque vous développez des fonctions dans .NET, vous utilisez l’attribut OrchestrationTriggerAttribute .NET pour configurer le déclencheur d’orchestration.

Pour Java, vous utilisez l’annotation @DurableOrchestrationTrigger pour configurer le déclencheur d’orchestration.

Lorsque vous utilisez la version 4 du modèle de programmation Node.js pour développer des fonctions, vous importez l’objet app à partir du @azure/functions npm module. Ensuite, vous appelez la app.orchestration méthode de l’API Durable Functions directement dans votre code de fonction. Cette méthode inscrit votre fonction d’orchestrateur auprès de l’infrastructure Durable Functions.

Lorsque vous écrivez des fonctions d’orchestrateur, vous définissez le déclencheur d’orchestration à l’aide de l’objet JSON suivant dans le bindings tableau du fichier function.json :

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "orchestration": "<optional-name-of-orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}

La orchestration valeur est le nom de l’orchestration que les clients doivent utiliser quand ils souhaitent démarrer de nouvelles instances de la fonction orchestrator. Cette propriété est facultative. Si vous ne le spécifiez pas, le nom de la fonction est utilisé.

Lorsque vous utilisez le modèle de programmation Python v2, vous pouvez définir un déclencheur d’orchestration à l’aide du orchestration_trigger décorateur directement dans votre code de fonction Python.

Dans le modèle v2, vous accédez aux déclencheurs et liaisons Durable Functions à partir d’une instance de DFApp. Vous pouvez utiliser cette sous-classe de FunctionApp pour exporter des décorateurs spécifiques à Durable Functions.

En interne, cette liaison de déclencheur interroge le magasin durable configuré à la recherche de nouveaux événements d’orchestration. Parmi les exemples d’événements, citons les événements de démarrage d’orchestration, les événements d’expiration du minuteur durable, les événements de réponse de fonction d’activité et les événements externes déclenchés par d’autres fonctions.

Comportement des déclencheurs

Voici quelques notes sur le déclencheur d’orchestration :

  • Thread unique : un thread de répartiteur unique est utilisé pour l’exécution de toutes les fonctions d’orchestrateur sur une instance d’hôte unique. Pour cette raison, il est important de s’assurer que le code de fonction d’orchestrateur est efficace et n’effectue aucune opération d’E/S. Il est également important de s’assurer que ce thread ne fait pas de travail asynchrone, sauf en attente de types de tâches spécifiques à Durable Functions.
  • Gestion des messages empoisonnés : il n’existe aucune prise en charge des messages empoisonnés dans les déclencheurs d’orchestration.
  • 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 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 de l’orchestration dans Stockage Table Azure. Ces valeurs de retour peuvent être interrogées par la liaison du client d’orchestration, décrite plus loin.

Avertissement

Les fonctions Orchestrator ne doivent jamais utiliser de liaisons d’entrée ou de sortie autres que la liaison de déclencheur d’orchestration. L’utilisation d’autres liaisons peut entraîner des problèmes avec l’extension Durable Task, car ces liaisons peuvent ne pas respecter les règles de monothreading 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 pour les fonctions d’orchestrateur, consultez contraintes de code de fonction Orchestrator.

Avertissement

Les fonctions d'orchestrateur ne doivent jamais être déclarées async.

Utilisation des déclencheurs

La liaison du déclencheur d’orchestration prend en charge à la fois les entrées et les sorties. Voici quelques notes sur la gestion des entrées et des sorties :

  • Entrées : vous pouvez appeler des déclencheurs d’orchestration qui ont des entrées. Les entrées sont accessibles via l’objet d’entrée de contexte. Toutes les entrées doivent être sérialisables JSON.
  • Sorties : les déclencheurs d’orchestration prennent en charge les valeurs de sortie et d’entrée. La valeur de retour de la fonction est utilisée pour affecter la valeur de sortie. La valeur de retour doit être sérialisable JSON.

Exemple de déclencheur

Le code suivant fournit un exemple de fonction d’orchestrateur Hello World de base. Cet exemple d’orchestrateur ne planifie aucune tâche.

L’attribut que vous utilisez pour définir le déclencheur dépend de l’exécution de vos fonctions C# dans le même processus que le processus hôte Functions ou dans un processus de travail isolé.

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

Remarque

Le code précédent concerne Durable Functions 2.x. Pour Durable Functions 1.x, vous devez utiliser DurableOrchestrationContext au lieu de IDurableOrchestrationContext. Pour plus d’informations sur les différences entre les versions, consultez la vue d'ensemble des versions de Durable Functions.

const { app } = require('@azure/functions');
const df = require('durable-functions');

df.app.orchestration('helloOrchestrator', function* (context) {
    const name = context.df.getInput();
    return `Hello ${name}`;
});

Remarque

La durable-functions bibliothèque appelle la méthode synchrone context.done lorsque la fonction du générateur se ferme.

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é. Le code suivant fournit un exemple Hello World qui montre comment appeler une fonction d’activité :

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

Remarque

Le code précédent concerne Durable Functions 2.x. Pour Durable Functions 1.x, vous devez utiliser DurableOrchestrationContext au lieu de IDurableOrchestrationContext. Pour plus d’informations sur les différences entre les versions, consultez la vue d'ensemble des versions de Durable Functions.

const { app } = require('@azure/functions');
const df = require('durable-functions');

const activityName = 'hello';

df.app.orchestration('helloOrchestrator', function* (context) {
    const name = context.df.getInput();
    const result = yield context.df.callActivity(activityName, 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é

Vous pouvez utiliser le déclencheur d’activité pour développer des fonctions appelées fonctions d’activité appelées par des fonctions d’orchestrateur.

Vous utilisez l’attribut ActivityTriggerAttribute .NET pour configurer le déclencheur d’activité.

Vous utilisez l’annotation @DurableActivityTrigger pour configurer le déclencheur d’activité.

Pour inscrire votre fonction d’activité, vous importez l’objet app à partir du @azure/functions npm module. Ensuite, vous appelez la app.activity méthode de l’API Durable Functions directement dans votre code de fonction.

Pour définir le déclencheur d’activité, vous utilisez l’objet JSON suivant dans le bindings tableau de function.json:

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "activity": "<optional-name-of-activity>",
    "type": "activityTrigger",
    "direction": "in"
}

La activity valeur est le nom de l’activité. Cette valeur est le nom que les fonctions d’orchestrateur utilisent pour appeler cette fonction d’activité. Cette propriété est facultative. Si vous ne le spécifiez pas, le nom de la fonction est utilisé.

Vous pouvez définir un déclencheur d’activité à l’aide du activity_trigger décorateur directement dans votre code de 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 des déclencheurs

Voici quelques notes sur le déclencheur d’activité :

  • Threading : contrairement au déclencheur d’orchestration, les déclencheurs d’activité n’ont aucune restriction sur les opérations de thread ou d’E/S. Ils peuvent être traités comme des fonctions régulières.
  • Gestion des poison messages : Il n’existe aucune prise en charge des poison messages dans les déclencheurs d’activité.
  • Visibilité des messages : les messages du déclencheur d’activité sont mis en file d’attente et conservés invisibles pendant une durée configurable. La visibilité de ces messages est renouvelée automatiquement tant que l’application de 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 des déclencheurs

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 notes sur la gestion des entrées et des sorties :

  • Entrées : les déclencheurs d’activité peuvent être appelés avec des entrées d’une fonction d’orchestrateur. Toutes les entrées doivent être sérialisables JSON.
  • Sorties : les fonctions d’activité prennent en charge les valeurs de sortie et d’entrée. La valeur de retour de la fonction est utilisée pour affecter la valeur de sortie et doit être sérialisable JSON.
  • Métadonnées : les fonctions d’activité .NET peuvent être liées à un string instanceId paramètre pour obtenir l’ID d’instance de l’orchestration appelante.

Exemple de déclencheur

Le code suivant fournit un exemple de fonction d’activité Hello World de base.

[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 les fonctions durables 1.x). Toutefois, les déclencheurs d’activité .NET prennent également en charge la liaison directement aux types sérialisables JSON (y compris les types primitifs), afin que vous puissiez également utiliser la version simplifiée suivante de la fonction :

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

const { app } = require('@azure/functions');
const df = require('durable-functions');
const activityName = 'hello';
df.app.activity(activityName, {
    handler: (input) => {
        return `Hello, ${input}`;
    },
});

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);
}

Utiliser des liaisons d’entrée et de sortie

Outre la liaison de déclenchement d’activité, vous pouvez également utiliser des liaisons d’entrée et de sortie classiques.

Par exemple, une fonction d’activité peut recevoir une entrée d’une fonction d’orchestrateur. La fonction d’activité peut ensuite envoyer cette entrée en tant que message à Azure Event Hubs.

const { app } = require('@azure/functions');
const df = require('durable-functions');

df.app.orchestration('helloOrchestrator', function* (context) {
    const input = context.df.getInput();
    yield context.df.callActivity('sendToEventHub', input);
    return `Message sent: ${input}`;
});

const { EventHubProducerClient } = require("@azure/event-hubs");
const connectionString = process.env.EVENT_HUB_CONNECTION_STRING;
const eventHubName = process.env.EVENT_HUB_NAME;

df.app.activity("sendToEventHub", {
    handler: async (message, context) => {
        const producer = new EventHubProducerClient(connectionString, eventHubName);
        try {
            const batch = await producer.createBatch();
            batch.tryAdd({ body: message });
            await producer.sendBatch(batch);
            context.log(`Message sent to Event Hubs: ${message}`);
        } catch (err) {
            context.log.error("Failed to send message to Event Hubs:", err);
            throw err;
        } finally {
            await producer.close();
        }
    },
});

app.storageQueue('helloQueueStart', {
    queueName: 'start-orchestration',
    extraInputs: [df.input.durableClient()],
    handler: async (message, context) => {
        const client = df.getClient(context);
        const orchestratorName = message.orchestratorName || 'helloOrchestrator';
        const input = message.input || null;
        const instanceId = await client.startNew(orchestratorName, { input });
        context.log(`Started orchestration with ID = '${instanceId}'`);
    },
});

Client d’orchestration

Vous pouvez utiliser la liaison du client d’orchestration pour é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 d’orchestration de la manière suivante :

  • Démarrez-les.
  • Vérifiez leur statut.
  • Éliminez-les.
  • Leur envoyer des événements pendant qu’elles sont exécutées.
  • Videz l’historique de l’instance.

Vous pouvez établir une liaison à un client d’orchestration à l’aide de l’attribut DurableClientAttribute (OrchestrationClientAttribute dans Durable Functions 1.x).

Vous pouvez établir une liaison à un client d’orchestration à l’aide de l’annotation @DurableClientInput .

Pour inscrire votre fonction cliente, vous importez l’objet app à partir du @azure/functions npm module. Ensuite, vous appelez une méthode d’API Durable Functions spécifique à votre type de déclencheur. Par exemple, pour un déclencheur HTTP, vous appelez la app.http méthode. Pour un déclencheur de file d’attente, vous appelez la app.storageQueue méthode.

Pour définir le déclencheur client durable, vous utilisez l’objet JSON suivant dans le bindings tableau de function.json:

{
    "name": "<name-of-input-parameter-in-function-signature>",
    "taskHub": "<optional-name-of-task-hub>",
    "connectionName": "<optional-name-of-connection-string-app-setting>",
    "type": "orchestrationClient",
    "direction": "in"
}
  • La taskHub propriété est utilisée lorsque plusieurs applications de fonction partagent le même compte de stockage, mais doivent être isolées les unes des autres. Si vous ne spécifiez pas cette propriété, la valeur par défaut de host.json est utilisée. Cette valeur doit correspondre à la valeur que les fonctions d’orchestrateur cible utilisent.
  • La connectionName valeur est le nom d’un paramètre d’application qui contient une chaîne de connexion de 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 vous ne spécifiez pas cette propriété, la chaîne de connexion de compte de stockage par défaut pour l’application de fonction est utilisée.

Remarque

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

Vous pouvez définir un déclencheur client durable à l’aide du décorateur durable_client_input directement dans votre code de fonction Python.

Utilisation du client

En règle générale, vous vous liez à une implémentation d’IDurableClient (DurableOrchestrationClient dans Durable Functions 1.x), ce qui vous donne un accès complet à toutes les API clientes d’orchestration que Durable Functions prend en charge.

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.

Le code suivant fournit un exemple de fonction déclenchée par une file d’attente qui démarre une orchestration Hello World .

[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);
}

Remarque

Le code C# précédent est destiné à 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 DurableOrchestrationClient type de paramètre au lieu de IDurableOrchestrationClient. Pour plus d’informations sur les différences entre les versions, consultez la vue d'ensemble des versions de Durable Functions.

const { app } = require('@azure/functions');
const df = require('durable-functions');

app.storageQueue('helloQueueStart', {
    queueName: 'start-orchestration',
    extraInputs: [df.input.durableClient()],
    handler: async (message, context) => {
        const client = df.getClient(context);
        const orchestratorName = message.orchestratorName || 'helloOrchestrator';
        const input = message.input || null;
        const instanceId = await client.startNew(orchestratorName, { input });
        context.log(`Started orchestration with ID = '${instanceId}' from queue message.`);
    },
});

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

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

@myApp.queue_trigger(
    arg_name="msg",
    queue_name="start-orchestration",
    connection="AzureWebJobsStorage"
)
@myApp.durable_client_input(client_name="client")
async def client_function(msg: func.QueueMessage, client: df.DurableOrchestrationClient):
    input_data = msg.get_body().decode("utf-8")
    await client.start_new("my_orchestrator", None, input_data)
    return None

function.json

{
  "bindings": [
    {
      "name": "InputData",
      "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);
}

Pour plus d’informations sur le démarrage des instances, consultez Gérer les instances dans Durable Functions dans Azure.

Déclencheur d’entité

Vous pouvez utiliser le déclencheur d’entité pour développer une fonction d’entité. Ce déclencheur prend en charge le traitement des événements pour une instance d’entité spécifique.

Remarque

Les déclencheurs d’entité sont disponibles à partir de 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.

Vous utilisez l’attribut EntityTriggerAttribute .NET pour configurer le déclencheur d’entité.

Pour inscrire le déclencheur d’entité, vous importez l’objet app à partir du @azure/functions npm module. Ensuite, vous appelez la app.entity méthode de l’API Durable Functions directement dans votre code de fonction.

const df = require('durable-functions');
df.app.entity('counter', (context) => {
    const currentValue = context.df.getState(() => 0);
    switch (context.df.operationName) {
        case 'add':
            context.df.setState(currentValue + context.df.getInput());
            break;
        case 'reset':
            context.df.setState(0);
            break;
        case 'get':
            context.df.return(currentValue);
            break;
    }
});

Remarque

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

Remarque

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

Vous pouvez définir un déclencheur d’entité à l’aide du entity_trigger décorateur directement dans votre code de fonction Python.

Comportement des déclencheurs

Voici quelques notes sur le déclencheur d’entité :

  • Thread unique : un thread de répartiteur unique est utilisé pour traiter les opérations d’une entité particulière. Si plusieurs messages sont envoyés simultanément à une seule entité, les opérations sont traitées une par une.
  • Gestion des messages empoisonnés : Il n'existe aucune prise en charge des messages empoisonnés dans les déclencheurs d'entité.
  • Visibilité des messages : les messages de déclencheur d’entité sont retirés de la file d’attente et conservés invisibles pendant une durée configurable. La visibilité de ces messages est renouvelée automatiquement tant que l’application de 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. Il existe des API spécifiques que vous pouvez utiliser pour enregistrer l’état ou transmettre des valeurs aux orchestrations.

Toutes les modifications d’état apportées à une entité pendant son exécution sont automatiquement conservées une fois l’exécution terminée.

Pour plus d’informations et d’exemples de définition et d’interaction avec des déclencheurs d’entité, consultez Fonctions d’entité.

Client d’entité

Vous pouvez utiliser la liaison du client d’entité pour déclencher de manière asynchrone les fonctions d’entité. Ces fonctions sont parfois appelées fonctions clientes.

Pour se lier au client d'entité, vous pouvez utiliser l’attribut DurableClientAttribute de .NET dans les fonctions de bibliothèque de classes .NET.

Remarque

Vous pouvez également utiliser le [DurableClientAttribute] pour vous lier au client d’orchestration.

Au lieu d’enregistrer une entité client, vous utilisez signalEntity ou callEntity et appelez une méthode de déclenchement de l’entité à partir de n’importe quelle fonction enregistrée.

  • À partir d’une fonction déclenchée par une file d’attente, vous pouvez utiliser client.signalEntity:

    const { app } = require('@azure/functions');
const df = require('durable-functions');
app.storageQueue('helloQueueStart', {
    queueName: 'start-orchestration',
    extraInputs: [df.input.durableClient()],
    handler: async (message, context) => {
        const client = df.getClient(context);
        const entityId = new df.EntityId('counter', 'myCounter');
        await client.signalEntity(entityId, 'add', 5);
    },
});

  • À partir d’une fonction d’orchestrateur, vous pouvez utiliser context.df.callEntity:

    const { app } = require('@azure/functions');
const df = require('durable-functions');
df.app.orchestration('entityCaller', function* (context) {
    const entityId = new df.EntityId('counter', 'myCounter');
    yield context.df.callEntity(entityId, 'add', 5);
    yield context.df.callEntity(entityId, 'add', 5);
    const result = yield context.df.callEntity(entityId, 'get');
    return result;
});

Vous pouvez définir un client d’entité à l’aide du durable_client_input décorateur directement dans votre code de fonction Python.

Remarque

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

Remarque

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

Pour plus d’informations et d’exemples d’interaction avec des entités en tant que client, consultez Entités Access.

Paramètres de Durable Functions dans host.json

Cette section fournit des informations sur les propriétés de configuration Durable Functions dans host.json. Pour plus d’informations sur les paramètres généraux dans host.json, consultez host.json référence pour Azure Functions 1.x ou host.json référence pour Azure Functions 2.x et versions ultérieures.

Paramètres de configuration pour Durable Functions.

Remarque

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 diffère légèrement selon la version du runtime Azure Functions et la version de l’extension Durable Functions que vous utilisez.

Le code suivant fournit deux exemples de durableTask paramètres dans host.json: un pour Durable Functions 2.x et un pour Durable Functions 1.x. Vous pouvez utiliser les deux exemples avec Azure Functions 2.0 et 3.0. Avec Azure Functions 1.0, les paramètres disponibles sont identiques, mais la durableTask section de host.json se trouve à la racine de la configuration host.json au lieu d’être un champ sous extensions.

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "defaultVersion": "1.0",
    "versionMatchStrategy": "CurrentOrOlder",
    "versionFailureStrategy": "Reject",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "FetchLargeMessagesAutomatically": true,
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": false,
      "useTablePartitionManagement": true,
      "workItemQueueVisibilityTimeout": "00:05:00",
      "QueueClientMessageEncoding": "UTF8"
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "httpSettings":{
      "defaultAsyncRequestSleepTimeMilliseconds": 30000,
      "useForwardedHost": 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,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "storeInputsInOrchestrationHistory": false
  }
 }
}
Propriété Valeur par défaut Descriptif
hubName TestHubName (DurableFunctionsHub dans v1.x) Nom du hub qui stocke l’état actuel d’une application de fonction. Les noms de hubs de tâches doivent commencer par une lettre et contenir uniquement des lettres et des chiffres. Si vous ne spécifiez pas de nom, la valeur par défaut est utilisée. D’autres noms de hub de tâches peuvent être utilisés pour isoler plusieurs applications Durable Functions les unes des autres, même s’ils utilisent le même serveur principal de stockage. Pour plus d’informations, consultez Hubs de tâches.
defaultVersion Version par défaut à affecter à de nouvelles instances d’orchestration. Lorsque vous spécifiez une version, de nouvelles instances d’orchestration sont définitivement associées à cette valeur de version. Ce paramètre est utilisé par la fonctionnalité de contrôle de version d’orchestration pour permettre des scénarios tels que des déploiements sans temps d’arrêt avec des changements cassants. Vous pouvez utiliser n’importe quelle valeur de chaîne pour la version.
versionMatchStrategy CurrentOrOlder Valeur qui spécifie la mise en correspondance des versions d’orchestration lorsque les fonctions d’orchestrateur sont chargées. Les valeurs valides sont None, Strictet CurrentOrOlder. Pour obtenir des explications détaillées, consultez Contrôle de version d’orchestration.
versionFailureStrategy Rejeter Valeur qui spécifie ce qui se passe quand une version d’orchestration ne correspond pas à la valeur actuelle defaultVersion . Les valeurs valides sont Reject et Fail. Pour obtenir des explications détaillées, consultez Contrôle de version d’orchestration.
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 d’autres langues : 128
Plan dédié ou Premium : 256		 Nombre de messages de file d’attente de contrôle pouvant être mis en mémoire tampon à la fois. Lorsque le nombre spécifié est atteint, le répartiteur attend avant de retirer d'autres messages de la file d'attente. Dans certaines situations, la réduction de cette valeur peut réduire considérablement la consommation de mémoire.
nombre de partitions 4 Nombre de partitions de la file d’attente de contrôle. Cette valeur doit être un entier positif compris entre 1 et 16. La modification de cette valeur nécessite la configuration d’un nouveau hub de tâches.
controlQueueVisibilityTimeout 00:05:00 Délai d’expiration de la visibilité des messages supprimés de la file d’attente de contrôle au format hh:mm:ss.
workItemQueueVisibilityTimeout 00:05:00 Délai d’expiration de la visibilité des messages supprimés de la file d’attente de l’élément de travail au format hh:mm:ss.
RécupérerAutomatiquementLesGrandsMessages vrai Valeur qui spécifie s’il faut récupérer des messages volumineux dans les requêtes d’état d’orchestration. Lorsque ce paramètre est truedéfini, les messages volumineux qui dépassent la limite de taille de file d’attente sont récupérés. Lorsque ce paramètre est false, une URL d’objet blob qui pointe vers chaque message volumineux est récupérée.
maxConcurrentActivityFunctions Plan de consommation : 10
Plan dédié ou Premium : 10 fois le nombre de processeurs 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é ou Premium : 10 fois le nombre de processeurs sur l’ordinateur actuel		 Nombre maximal de fonctions d’orchestrateur pouvant être traitées simultanément sur une seule instance d’hôte.
maxConcurrentEntityFunctions Plan de consommation : 5
Plan dédié ou Premium : 10 fois le nombre de processeurs sur l’ordinateur actuel		 Nombre maximal de fonctions d’entité qui peuvent être traitées simultanément sur une instance d’hôte unique. Ce paramètre s’applique uniquement lorsque vous utilisez le planificateur de tâches durable. Sinon, le nombre maximal d’exécutions d’entités simultanées est limité à la maxConcurrentOrchestratorFunctions valeur.
maxQueuePollingInterval 00:00:30 Intervalle d’interrogation de la file d’attente des éléments de travail et de contrôle maximum 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.
maxOrchestrationActions 100 000 Le nombre maximal d’actions qu’une fonction d’orchestrateur peut effectuer pendant un cycle d’exécution unique.
connectionName (v2.7.0 et versions ultérieures)
connectionStringName (v2.x)
azureStorageConnectionStringName (v1.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. Lorsque vous fournissez un paramètre d’application unique, il doit s’agir d’une chaîne de connexion stockage Azure.
trackingStoreConnectionName (v2.7.0 et versions ultérieures)
trackingStoreConnectionStringName		 Nom d’un paramètre d’application ou d’une collection de paramètres qui spécifie comment se connecter aux tables Historique et Instances, qui stockent l’historique d’exécution et les métadonnées sur les instances d’orchestration. Lorsque vous fournissez un paramètre d’application unique, il doit s’agir d’une chaîne de connexion stockage Azure. Si vous ne spécifiez pas de paramètre, la valeur connectionStringName (v2.x) ou la connexion de valeur azureStorageConnectionStringName (v1.x) est utilisée.
trackingStoreNamePrefix Préfixe à utiliser pour les tables d’historique et d’instances lorsque le paramètre trackingStoreConnectionStringName est spécifié. Si vous ne spécifiez pas de préfixe, la valeur par défaut est DurableTask utilisée. Si trackingStoreConnectionStringName n'est pas spécifié, les tables Historique et Instances utilisent la valeur hubName comme préfixe, et le paramètre trackingStoreNamePrefix est ignoré.
traceInputsAndOutputs faux Valeur qui indique s’il faut suivre les entrées et sorties des appels de fonction. Lorsque les événements d’exécution de fonction sont suivis, le comportement par défaut consiste à inclure le nombre d’octets dans les entrées sérialisées et les sorties pour les appels de fonction. Ce comportement fournit des informations minimales sur les entrées et les sorties afin de ne pas surcharger les journaux ni exposer involontairement des informations sensibles. Lorsque cette propriété est true, le contenu entier des entrées et sorties de fonction est journalisé.
traceReplayEvents faux Valeur indiquant s’il faut écrire les événements de relecture d’orchestration dans Application Insights.
logReplayEvents faux Valeur qui indique s’il faut journaliser les exécutions rejouées dans les journaux d’application.
eventGridTopicEndpoint URL du point de terminaison de la rubrique personnalisée Azure Event Grid. Lorsque vous définissez cette propriété, les événements de notification du cycle de vie de l'orchestration sont publiés sur ce point final. Cette propriété prend en charge la résolution des paramètres d’application.
eventGridKeySettingName Nom du paramètre d’application qui contient la clé utilisée pour l’authentification avec la rubrique personnalisée Event Grid à l’URL EventGridTopicEndpoint .
eventGridPublishRetryCount 0 Nombre de nouvelles tentatives si la publication dans la rubrique Event Grid échoue.
eventGridPublishRetryInterval 00:05:00 L'intervalle de réessai de publication pour Event Grid au format hh:mm:ss.
eventGridPublishEventTypes Liste des types d’événement à publier sur Event Grid. Si vous ne spécifiez aucun type, tous les types d’événements sont publiés. Les valeurs autorisées incluent Started, , CompletedFailedet Terminated.
extendedSessionsEnabled faux Valeur qui spécifie si les sessions d’orchestrateur de session et de fonction d’entité sont mises en cache.
extendedSessionIdleTimeoutInSeconds 30 Le nombre de secondes pendant lesquelles une fonction d’orchestrateur ou d’entité inactive reste en mémoire avant d’être déchargée. Ce paramètre est utilisé uniquement lorsque le extendedSessionsEnabled paramètre est true.
useAppLease vrai Valeur qui indique si les applications doivent acquérir un bail de blob au niveau de l’application avant de traiter les messages du hub de tâches. Pour plus d’informations, consultez La récupération d’urgence et la géo-distribution dans Durable Functions. Ce paramètre est disponible à partir de la version 2.3.0.
useLegacyPartitionManagement faux Valeur qui spécifie le type d’algorithme de gestion de partition à utiliser. Lorsque ce paramètre est falsedéfini, un algorithme est utilisé qui réduit la possibilité d’exécution de fonction en double lors d’un scale-out. Ce paramètre est disponible à partir de la version 2.3.0. La définition de cette valeur true n’est pas recommandée.
useTablePartitionManagement Dans v3.x : true
Dans v2.x : false		 Valeur qui spécifie le type d’algorithme de gestion de partition à utiliser. Lorsque ce paramètre est truedéfini, un algorithme est utilisé pour réduire les coûts des comptes Stockage Azure v2. Ce paramètre est disponible à partir de WebJobs.Extensions.DurableTask v2.10.0. L’utilisation de ce paramètre avec une identité managée nécessite WebJobs.Extensions.DurableTask v3.x ou version ultérieure, ou Worker.Extensions.DurableTask v1.2.x ou version ultérieure.
useGracefulShutdown faux (Préversion) Valeur qui indique s’il faut procéder à un arrêt en douceur pour réduire le risque d’échec des exécutions en cours de fonctions en raison de l’arrêt de l’hôte.
maxEntityOperationBatchSize Plan de consommation : 50
Plan dédié ou Premium : 5 000		 Nombre maximal d’opérations d’entité traitées en tant que lot. Si cette valeur est 1, le traitement par lots est désactivé et un appel de fonction distinct traite chaque message d’opération. Ce paramètre est disponible à partir de la version 2.6.1.
storeInputsInOrchestrationHistory faux Valeur qui spécifie comment stocker les entrées. Lorsque ce paramètre est truedéfini, Durable Task Framework enregistre les entrées d’activité dans la table Historique et les entrées de fonction d’activité apparaissent dans les résultats de la requête d’historique d’orchestration.
maxGrpcMessageSizeInBytes 4,194,304 Valeur entière qui définit la taille maximale, en octets, des messages que le client d’appel de procédure distante générique (gRPC) peut recevoir. L'implémentation de DurableTaskClient utilise le client gRPC pour gérer les instances d'orchestration. Ce paramètre s’applique aux applications Java et Worker isolés .NET Durable Functions.
grpcHttpClientTimeout 00:01:40 Délai d’expiration au format hh :mm :ss pour le client HTTP utilisé par le client gRPC dans Durable Functions. Le client est actuellement pris en charge pour les applications worker isolées .NET (.NET 6 et versions ultérieures) et pour les applications Java.
QueueClientMessageEncoding UTF8 Stratégie de codage pour les messages de Stockage File d’attente Azure. Les stratégies valides sont Unicode Transformation Format–8 bits (UTF8) et Base64. Ce paramètre s’applique lorsque vous utilisez Microsoft.Azure.WebJobs.Extensions.DurableTask 3.4.0 ou version ultérieure, ou Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.7.0 ou version ultérieure.
Temps de pause par défaut pour les requêtes asynchrones en millisecondes (defaultAsyncRequestSleepTimeMilliseconds) 30000 Intervalle d’interrogation par défaut, en millisecondes, pour les API HTTP asynchrones. Lorsqu’un client interroge l’état d’une orchestration de longue durée à l’aide du point de terminaison de requête d’état HTTP, cette valeur détermine la durée pendant laquelle le client doit attendre avant d’interroger à nouveau.
utiliserHôteTransféré faux Lorsque la valeur est true, l’extension utilise les en-têtes X-Forwarded-Host et X-Forwarded-Proto pour construire des URL dans les réponses HTTP.

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

Étapes suivantes

Informations de référence sur l’API HTTP intégrées pour la gestion des instances

  • Last updated on