Condividi tramite


Associazioni per Funzioni permanenti (Funzioni di Azure)

L'estensione Durable Functions introduce tre associazioni di trigger che controllano l'esecuzione di funzioni di orchestrazione, entità e attività. Introduce anche un'associazione di output che funge da client per il runtime di Durable Functions.

Questo articolo illustra l'uso di queste quattro associazioni e fornisce esempi di codice. Fornisce anche informazioni sulle proprietà di configurazione di Durable Functions in host.json, il file di metadati che contiene le impostazioni che influiscono su tutte le funzioni in un'app per le funzioni.

Assicurarsi di selezionare il linguaggio di sviluppo di Durable Functions nella parte superiore dell'articolo.

Entrambe le versioni del modello di programmazione Python per Funzioni di Azure sono supportate da Durable Functions. Poiché Python v2 è la versione consigliata, gli esempi in questo articolo includono esclusivamente questa versione.

Prerequisiti

  • Durable Functions SDK, cioè il pacchetto azure-functions-durable Python Package Index (PyPI), versione 1.2.2 o una versione più recente
  • Bundle di estensione versione 4.x (o versione successiva), impostato nel file di progetto host.json

È possibile fornire commenti e suggerimenti nel repository Durable Functions SDK per Python.

Trigger di orchestrazione

È possibile usare il trigger di orchestrazione per sviluppare funzioni di orchestratore durevoli. Questo trigger viene eseguito quando viene pianificata una nuova istanza di orchestrazione e quando un'istanza di orchestrazione esistente riceve un evento. Esempi di eventi che possono attivare funzioni dell’agente di orchestrazione includono scadenza dei timer durevoli, risposte alle funzioni di attività ed eventi sollevati da client esterni.

Quando si sviluppano funzioni in .NET, si usa l'attributo .NET OrchestrationTriggerAttribute per configurare il trigger di orchestrazione.

Per Java si usa l'annotazione @DurableOrchestrationTrigger per configurare il trigger di orchestrazione.

Quando si usa la versione 4 del modello di programmazione Node.js per sviluppare funzioni, importare l'oggetto app dal @azure/functions npm modulo. Chiamare quindi il app.orchestration metodo dell'API Durable Functions direttamente nel codice della funzione. Questo metodo registra la funzione di orchestrazione con il framework Durable Functions.

Quando si scrivono funzioni dell'agente di orchestrazione, si definisce il trigger di orchestrazione usando l'oggetto JSON seguente nella bindings matrice del file function.json :

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

Il valore orchestration è il nome dell'orchestrazione che i client devono usare quando vogliono avviare nuove istanze della funzione di orchestrazione. Questa proprietà è facoltativa. Se non viene specificato, viene usato il nome della funzione.

Quando si usa il modello di programmazione Python v2, è possibile definire un trigger di orchestrazione usando l'elemento orchestration_trigger Decorator direttamente nel codice della funzione Python.

Nel modello v2 si accede ai trigger e alle associazioni di Durable Functions da un'istanza di DFApp. È possibile usare questa sottoclasse di FunctionApp per esportare decoratori specifici di Durable Functions.

Internamente, questa associazione di trigger esegue il polling dell'archivio durevole configurato per i nuovi eventi di orchestrazione. Esempi di eventi includono eventi di avvio dell'orchestrazione, eventi di scadenza timer durevoli, eventi di risposta delle funzioni di attività ed eventi esterni generati da altre funzioni.

Comportamento di trigger

Di seguito vengono indicate alcune note relative al trigger di orchestrazione:

  • Single-threading: viene utilizzato un singolo thread dispatcher per tutte le esecuzioni delle funzioni orchestratore in una singola istanza host. Per questo motivo, è importante assicurarsi che il codice della funzione dell'agente di orchestrazione sia efficiente e non esegua alcuna operazione di I/O. È anche importante assicurarsi che questo thread non funzioni asincrona, tranne quando si attendono tipi di attività specifici di Durable Functions.
  • Gestione dei messaggi non elaborabili: non è disponibile alcun supporto per i messaggi non elaborabili nei trigger di orchestrazione.
  • Visibilità dei messaggi: i messaggi dei trigger di orchestrazione vengono rimossi dalla coda e resi invisibili per un periodo di tempo configurabile. La visibilità di questi messaggi viene rinnovata automaticamente, purché l'app per le funzioni sia in esecuzione e integra.
  • Valori restituiti: i valori restituiti vengono serializzati in JSON e salvati nella tabella della cronologia dell'orchestrazione in Azure Table Storage. Su tali valori l'associazione client di orchestrazione può eseguire query, come descritto in seguito.

Avvertimento

Le funzioni dell'agente di orchestrazione non devono mai usare associazioni di input o output diverse dall'associazione del trigger di orchestrazione. L'utilizzo di altri binding può causare problemi con l'estensione Durable Task, perché tali binding potrebbero non rispettare le regole di I/O e single-threading. Se si vogliono usare altre associazioni, aggiungerle a una funzione di attività chiamata dalla funzione dell'agente di orchestrazione. Per altre informazioni sui vincoli di codifica per le funzioni dell'agente di orchestrazione, vedere Vincoli di codice della funzione di Orchestrator.

Avvertimento

Le funzioni di orchestrazione non devono mai essere dichiarate async.

Utilizzo dei trigger

L'associazione di trigger di orchestrazione supporta sia input che output. Ecco alcune note sulla gestione dell'input e dell'output:

  • Input: è possibile richiamare trigger di orchestrazione con input. Gli input sono accessibili tramite l'oggetto di input del contesto. Tutti gli input devono essere serializzabili in JSON.
  • Output: i trigger di orchestrazione supportano sia i valori di output che di input. Il valore restituito della funzione viene usato per assegnare il valore di output. Il valore restituito deve essere serializzabile in JSON.

Esempio di trigger

Il codice seguente fornisce un esempio di funzione dell'agente di orchestrazione Hello World di base. Questo agente di orchestrazione di esempio non pianifica alcuna attività.

L'attributo usato per definire il trigger dipende dal fatto che si eseguano le funzioni C# nello stesso processo del processo host di Funzioni o in un processo di lavoro isolato.

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

Annotazioni

Il codice precedente è per Durable Functions 2.x. Per Durable Functions 1.x, è necessario usare DurableOrchestrationContext anziché IDurableOrchestrationContext. Per altre informazioni sulle differenze tra le versioni, vedere Panoramica delle versioni di 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}`;
});

Annotazioni

La durable-functions libreria chiama il metodo sincrono context.done quando la funzione generatore viene chiusa.

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 maggior parte delle funzioni di orchestrazione chiama le funzioni di attività. Il codice seguente fornisce un esempio Hello World che illustra come chiamare una funzione di attività:

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

Annotazioni

Il codice precedente è per Durable Functions 2.x. Per Durable Functions 1.x, è necessario usare DurableOrchestrationContext anziché IDurableOrchestrationContext. Per altre informazioni sulle differenze tra le versioni, vedere Panoramica delle versioni di 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;
}

Attivatore di attività

È possibile usare il trigger di attività per sviluppare funzioni chiamate funzioni di attività che sono invocate dalle funzioni di orchestrazione.

Usare l'attributo ActivityTriggerAttribute .NET per configurare il trigger di attività.

Usi l'annotazione @DurableActivityTrigger per configurare il trigger di attività.

Per registrare la funzione di attività, importare l'oggetto app dal @azure/functions npm modulo. Chiamare quindi il app.activity metodo dell'API Durable Functions direttamente nel codice della funzione.

Per definire il trigger di attività, usare l'oggetto JSON seguente nella bindings matrice di function.json:

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

Il activity valore è il nome dell'attività. Questo valore è il nome usato dalle funzioni dell'agente di orchestrazione per richiamare questa funzione di attività. Questa proprietà è facoltativa. Se non viene specificato, viene usato il nome della funzione.

È possibile definire un trigger di attività usando il activity_trigger decorator direttamente nel codice della funzione Python.

Internamente, questa associazione di trigger esegue il polling dell'archivio durevole configurato per i nuovi eventi di esecuzione delle attività.

Comportamento di trigger

Di seguito vengono indicate alcune note relative al trigger di attività:

  • Threading: a differenza del trigger di orchestrazione, i trigger di attività non hanno restrizioni per le operazioni di threading o I/O. Possono essere trattati come funzioni regolari.
  • Gestione dei messaggi dannosi: non è disponibile alcun supporto per i messaggi dannosi nei trigger di attività.
  • Visibilità dei messaggi: i messaggi dei trigger di attività vengono rimossi dalla coda e resi invisibili per un periodo di tempo configurabile. La visibilità di questi messaggi viene rinnovata automaticamente, purché l'app per le funzioni sia in esecuzione e integra.
  • Valori restituiti: i valori restituiti vengono serializzati in JSON e resi persistenti nell'archivio durevole configurato.

Utilizzo dei trigger

In modo analogo al trigger di orchestrazione, l'associazione di trigger di attività supporta sia input che output. Ecco alcune note sulla gestione dell'input e dell'output:

  • Input: i trigger di attività possono essere richiamati con input da una funzione di orchestrazione. Tutti gli input devono essere serializzabili in JSON.
  • Output: le funzioni di attività supportano sia i valori di output che di input. Il valore restituito della funzione viene usato per assegnare il valore di output e deve essere serializzabile in JSON.
  • Metadati: le funzioni di attività .NET possono essere associate a un string instanceId parametro per ottenere l'ID istanza dell'orchestrazione chiamante.

Esempio di trigger

Il codice seguente fornisce un esempio di una funzione di attività Hello World di base.

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

Il tipo di parametro predefinito per il binding .NET ActivityTriggerAttribute è IDurableActivityContext (o DurableActivityContext per *Durable Functions* 1.x). Tuttavia, i trigger di attività .NET supportano anche l'associazione diretta a tipi serializzabili JSON (inclusi i tipi primitivi), quindi è anche possibile usare la versione semplificata seguente della funzione:

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

Usare associazioni di input e output

Oltre all'associazione del trigger di attività, è anche possibile usare associazioni regolari di input e output.

Ad esempio, una funzione di attività può ricevere input da una funzione di orchestrazione. La funzione di attività può quindi inviare tale input come messaggio a Hub eventi di Azure.

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 di orchestrazione

È possibile usare il binding del client di orchestrazione per scrivere funzioni che interagiscono con le funzioni dell'orchestratore. Queste funzioni vengono spesso definite funzioni client. Ad esempio, è possibile agire sulle istanze di orchestrazione nei modi seguenti:

  • Avviare le istanze.
  • Eseguire query sullo stato delle istanze.
  • Terminare le istanze.
  • Inviare eventi alle istanze mentre sono in esecuzione.
  • Cancellare la cronologia delle istanze.

È possibile eseguire l'associazione a un client di orchestrazione usando l'attributo DurableClientAttribute (OrchestrationClientAttribute in Durable Functions 1.x).

È possibile eseguire l'associazione a un client di orchestrazione usando l'annotazione @DurableClientInput .

Per registrare la funzione client, importare l'oggetto app dal @azure/functions npm modulo. Quindi, chiama un metodo dell'API di Durable Functions specifico per il tipo di trigger. Ad esempio, per un trigger HTTP, chiamate il metodo app.http. Per un trigger della coda, chiamare il metodo app.storageQueue.

Per definire il trigger client durevole, usare l'oggetto JSON seguente nella bindings matrice di 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 proprietà viene usata quando più app per le funzioni condividono lo stesso account di archiviazione, ma devono essere isolate l'una dall'altra. Se non si specifica questa proprietà, viene usato il valore predefinito di host.json . Questo valore deve corrispondere al valore usato dalle funzioni dell'orchestratore di destinazione.
  • Il valore connectionName è il nome di un'impostazione dell'app che contiene la stringa di connessione di un account di archiviazione. L'account di archiviazione rappresentato da questa stringa di connessione deve essere lo stesso utilizzato dalle funzioni di orchestrazione di destinazione. Se non si specifica questa proprietà, viene usata la stringa di connessione dell'account di archiviazione predefinito dell'app per le funzioni.

Annotazioni

Nella maggior parte dei casi, è consigliabile omettere queste proprietà e basarsi sul comportamento predefinito.

È possibile definire un trigger client durevole usando l'elemento Decoratordurable_client_input direttamente nel codice della funzione Python.

Uso del client

In genere si esegue il binding a un'implementazione di IDurableClient (DurableOrchestrationClient in Durable Functions 1.x), che consente l'accesso completo a tutte le API client di orchestrazione supportate da Durable Functions.

In genere si esegue l'associazione alla classe DurableClientContext.

È necessario usare l'SDK specifico del linguaggio per ottenere l'accesso a un oggetto client.

Il codice seguente fornisce un esempio di funzione attivata dalla coda che avvia un'orchestrazione 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);
}

Annotazioni

Il codice C# precedente è per Durable Functions 2.x. Per Durable Functions 1.x, è necessario usare l'attributo OrchestrationClient anziché l'attributo DurableClient ed è necessario usare il tipo di parametro DurableOrchestrationClient anziché IDurableOrchestrationClient. Per altre informazioni sulle differenze tra le versioni, vedere Panoramica delle versioni di 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);
}

Per informazioni dettagliate sull'avvio delle istanze, vedere Gestire le istanze in Durable Functions in Azure.

Trigger entità

È possibile usare il trigger di entità per sviluppare una funzione di entità. Questo trigger supporta l'elaborazione di eventi per un'istanza di entità specifica.

Annotazioni

I trigger di entità sono disponibili a partire da Durable Functions 2.x.

Internamente, questa associazione di trigger esegue il polling dell'archivio durevole configurato per le nuove operazioni di entità che devono essere eseguite.

Per configurare il trigger dell'entità, si utilizza l'attributo EntityTriggerAttribute di .NET.

Per registrare il trigger di entità, importare l'oggetto app dal modulo @azure/functions npm. Chiamare quindi il app.entity metodo dell'API Durable Functions direttamente nel codice della funzione.

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

Annotazioni

I trigger di entità non sono ancora supportati per Java.

Annotazioni

I trigger di entità non sono ancora supportati per PowerShell.

È possibile definire un trigger di entità usando il decoratore entity_trigger direttamente nel codice della funzione Python.

Comportamento di trigger

Ecco alcune note sul trigger di entità:

  • Single-threading: viene usato un singolo thread dispatcher per elaborare le operazioni per una determinata entità. Se più messaggi vengono inviati a una singola entità contemporaneamente, le operazioni vengono elaborate una alla volta.
  • Gestione dei messaggi poison: non è disponibile alcun supporto per i messaggi poison nei trigger di entità.
  • Visibilità dei messaggi: i messaggi dei trigger di entità vengono rimossi dalla coda e resi invisibili per un periodo di tempo configurabile. La visibilità di questi messaggi viene rinnovata automaticamente, purché l'app per le funzioni sia in esecuzione e integra.
  • Valori restituiti: le funzioni di entità non supportano i valori restituiti. Esistono API specifiche che è possibile usare per salvare lo stato o passare di nuovo i valori alle orchestrazioni.

Tutte le modifiche di stato apportate a un'entità durante l'esecuzione vengono mantenute automaticamente al termine dell'esecuzione.

Per altre informazioni ed esempi di definizione e interazione con i trigger di entità, vedere Funzioni di entità.

Client di entità

È possibile usare l'associazione client di entità per attivare in modo asincrono le funzioni di entità. Queste funzioni vengono talvolta definite funzioni client.

È possibile eseguire l’associazione al client di entità usando l'attributo DurableClientAttribute .NET nelle funzioni della libreria di classi .NET.

Annotazioni

È anche possibile usare il [DurableClientAttribute] per eseguire l'associazione al client di orchestrazione.

Anziché registrare un client di entità, usare signalEntity o callEntity per chiamare un metodo trigger di entità da qualsiasi funzione registrata.

  • Da una funzione attivata dalla coda, è possibile usare 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);
        },
    });
    
  • Da una funzione dell'agente di orchestrazione è possibile usare 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;
    });
    

È possibile definire un client di entità usando l'elemento durable_client_input Decorator direttamente nel codice della funzione Python.

Annotazioni

I client di entità non sono ancora supportati per Java.

Annotazioni

I client di entità non sono ancora supportati per PowerShell.

Per altre informazioni ed esempi di interazione con le entità come client, vedere Accedere alle entità.

Impostazioni di Durable Functions in host.json

In questa sezione vengono fornite informazioni sulle proprietà di configurazione di Durable Functions in host.json. Per informazioni sulle impostazioni generali in host.json, consultare riferimento a host.json per Funzioni di Azure 1.x o riferimento a host.json per Funzioni di Azure 2.x e versioni successive.

Impostazioni di configurazione per Durable Functions.

Annotazioni

Tutte le versioni principali di Durable Functions sono supportate in tutte le versioni del runtime di Funzioni di Azure. Tuttavia, lo schema della configurazione host.json varia leggermente a seconda della versione del runtime di Funzioni di Azure e della versione dell'estensione Durable Functions usata.

Il codice seguente fornisce due esempi di durableTask impostazioni in host.json: una per Durable Functions 2.x e una per Durable Functions 1.x. È possibile usare entrambi gli esempi con Funzioni di Azure 2.0 e 3.0. Con Funzioni di Azure 1.0, le impostazioni disponibili sono le stesse, ma la durableTask sezione di host.json si trova nella radice della configurazione host.json anziché essere un campo in 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,
    },
    "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
  }
 }
}
Proprietà Valore predefinito Descrizione
hubName TestHubName (DurableFunctionsHub nella versione 1.x) Nome dell'hub che archivia lo stato corrente di un'app per le funzioni. I nomi degli hub attività devono iniziare con una lettera e contenere solo lettere e numeri. Se non si specifica un nome, viene usato il valore predefinito. I nomi alternativi degli hub delle attività possono essere usati per isolare più applicazioni Durable Functions tra loro, anche se usano lo stesso backend di archiviazione. Per altre informazioni, vedere Hub attività.
defaultVersion Versione predefinita da assegnare alle nuove istanze di orchestrazione. Quando si specifica una versione, le nuove istanze di orchestrazione vengono associate in modo permanente a questo valore di versione. Questa impostazione è usata dalla funzionalità di controllo delle versioni dell'orchestrazione per abilitare scenari come distribuzioni senza tempi di inattività con modifiche di rilievo. È possibile utilizzare qualsiasi stringa di testo per la versione.
versionMatchStrategy CurrentOrOlder Un valore che specifica come le versioni di orchestrazione vengono abbinate quando vengono caricate le funzioni di orchestrazione. I valori validi sono None, Stricte CurrentOrOlder. Per spiegazioni dettagliate, vedere Controllo delle versioni dell'orchestrazione.
versionFailureStrategy Rifiutare Valore che specifica cosa accade quando una versione di orchestrazione non corrisponde al valore corrente defaultVersion . I valori validi sono Reject e Fail. Per spiegazioni dettagliate, vedere Controllo delle versioni dell'orchestrazione.
controlQueueBatchSize 32 Numero di messaggi di cui eseguire il pull dalla coda di controllo contemporaneamente.
controlQueueBufferThreshold Piano di consumo per Python: 32
Piano di consumo per altre lingue: 128
Piano dedicato o Premium: 256
Numero di messaggi della coda di controllo che possono essere bufferizzati in memoria simultaneamente. Quando viene raggiunto il numero specificato, il dispatcher attende prima di rimuovere dalla coda altri messaggi. In alcune situazioni, la riduzione di questo valore può ridurre significativamente il consumo di memoria.
numero di partizioni 4 Numero di partizioni per la coda di controllo. Questo valore deve essere un numero intero positivo compreso tra 1 e 16. La modifica di questo valore richiede la configurazione di un nuovo hub attività.
controlQueueVisibilityTimeout 00:05:00 Timeout di visibilità dei messaggi rimossi dalla coda di controllo in formato hh:mm:ss.
workItemQueueVisibilityTimeout 00:05:00 Timeout di visibilità dei messaggi rimossi dalla coda degli elementi di lavoro in formato hh:mm:ss.
RecuperaMessaggiGrandiAutomaticamente true Valore che specifica se recuperare messaggi di grandi dimensioni nelle query sullo stato dell'orchestrazione. Quando questa impostazione è true, vengono recuperati messaggi di grandi dimensioni che superano il limite di dimensioni della coda. Quando questa impostazione è false, viene recuperato un URL BLOB che punta a ogni messaggio di grandi dimensioni.
maxConcurrentActivityFunctions Piano a consumo: 10
Piano dedicato o Premium: 10 volte il numero di processori nel computer corrente
Numero massimo di funzioni di attività che possono essere elaborate simultaneamente in una singola istanza host.
maxConcurrentOrchestratorFunctions Piano di consumo: 5
Piano dedicato o Premium: 10 volte il numero di processori nel computer corrente
Numero massimo di funzioni dell'agente di orchestrazione che possono essere elaborate simultaneamente in una singola istanza host.
maxConcurrentEntityFunctions Piano di consumo: 5
Piano dedicato o Premium: 10 volte il numero di processori nel computer corrente
Numero massimo di funzioni di entità che possono essere elaborate simultaneamente in una singola istanza host. Questa impostazione è applicabile solo quando si usa l'utilità di pianificazione dell'attività durevole. In caso contrario, il numero massimo di esecuzioni simultanee di entità è limitato al valore maxConcurrentOrchestratorFunctions.
maxQueuePollingInterval 00:00:30 Intervallo massimo di polling della coda di controllo e degli elementi di lavoro nel formato hh:mm:ss. I valori più elevati possono comportare latenze di elaborazione dei messaggi più elevate. I valori inferiori possono comportare costi di archiviazione più elevati a causa di transazioni di archiviazione aumentate.
maxOrchestrationActions 100,000 Numero massimo di azioni che una funzione dell'agente di orchestrazione può eseguire durante un singolo ciclo di esecuzione.
connectionName (v2.7.0 e versioni successive)
connectionStringName (v2.x)
azureStorageConnectionStringName (v1.x)
AzureWebJobsStorage Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi alle risorse di Archiviazione di Azure sottostanti. Quando si specifica una singola impostazione dell'app, deve trattarsi di una stringa di connessione di Archiviazione di Azure.
trackingStoreConnectionName (v2.7.0 e versioni successive)
trackingStoreConnectionStringName
Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi alle tabelle Cronologia e Istanze, che archivia la cronologia di esecuzione e i metadati relativi alle istanze di orchestrazione. Quando si specifica una singola impostazione dell'app, deve trattarsi di una stringa di connessione di Archiviazione di Azure. Se non specifichi un'impostazione, viene utilizzato il valore di connessione connectionStringName (v2.x) o il valore di connessione azureStorageConnectionStringName (v1.x).
trackingStoreNamePrefix Prefisso da utilizzare per le tabelle Cronologia e Istanze quando trackingStoreConnectionStringName viene specificato . Se non si specifica un prefisso, viene usato il valore predefinito di DurableTask . Se trackingStoreConnectionStringName non viene specificato, le tabelle Cronologia e Istanze usano il hubName valore come prefisso e l'impostazione trackingStoreNamePrefix viene ignorata.
traceInputsAndOutputs falso Valore che indica se tracciare gli input e gli output delle chiamate di funzione. Quando vengono tracciati gli eventi di esecuzione delle funzioni, il comportamento predefinito consiste nell'includere il numero di byte negli input serializzati e negli output per le chiamate di funzione. Questo comportamento fornisce informazioni minime sugli input e sugli output, per evitare di ingrossare i registri o di esporre inavvertitamente informazioni sensibili. Quando questa proprietà è true, vengono registrati l'intero contenuto degli input e degli output della funzione.
traceReplayEvents falso Un valore che indica se scrivere eventi di riproduzione di orchestrazione in Application Insights.
logReplayEvents falso Valore che indica se registrare le esecuzioni riprodotte nei log applicazioni.
eventGridTopicEndpoint URL di un endpoint di un argomento personalizzato di Griglia di eventi di Azure. Quando si imposta questa proprietà, gli eventi di notifica del ciclo di vita dell'orchestrazione vengono pubblicati in questo endpoint. Questa proprietà supporta la risoluzione delle impostazioni dell'app.
eventGridKeySettingName Nome dell'impostazione dell'app che contiene la chiave usata per l'autenticazione con l'argomento personalizzato di Griglia di eventi nell'URL EventGridTopicEndpoint .
eventGridPublishRetryCount 0 Numero di tentativi se la pubblicazione nell'argomento griglia di eventi ha esito negativo.
eventGridPublishRetryInterval 00:05:00 Intervallo fra i tentativi di pubblicazione in Griglia di eventi nel formato hh:mm:ss.
eventGridPublishEventTypes Elenco di tipi di evento da pubblicare in Griglia di eventi. Se non si specifica alcun tipo, vengono pubblicati tutti i tipi di evento. I valori consentiti includono Started, CompletedFailed, e Terminated.
extendedSessionsEnabled falso Valore che specifica se le sessioni dell'agente di orchestrazione della sessione e delle funzioni di entità vengono memorizzate nella cache.
extendedSessionIdleTimeoutInSeconds 30 Numero di secondi in cui un agente di orchestrazione o una funzione di entità inattiva rimane in memoria prima di essere scaricata. Questa impostazione viene usata solo quando l'impostazione extendedSessionsEnabled è true.
usaAppLease true Valore che indica se le app devono acquisire un lease BLOB a livello di applicazione prima di elaborare i messaggi dell'hub attività. Per altre informazioni, vedere Ripristino di emergenza e distribuzione geografica in Durable Functions. Questa impostazione è disponibile a partire dalla versione 2.3.0.
useLegacyPartitionManagement falso Valore che specifica il tipo di algoritmo di gestione delle partizioni da utilizzare. Quando questa impostazione è false, viene usato un algoritmo che riduce la possibilità di esecuzione di funzioni duplicate quando si aumenta il numero di istanze. Questa impostazione è disponibile a partire dalla versione 2.3.0. L'impostazione di questo valore su true non è consigliata.
useTablePartitionManagement In v3.x: vero
In v2.x: false
Valore che specifica il tipo di algoritmo di gestione delle partizioni da utilizzare. Quando questa impostazione è true, viene usato un algoritmo progettato per ridurre i costi per gli account di Archiviazione di Azure v2. Questa impostazione è disponibile a partire da WebJobs.Extensions.DurableTask v2.10.0. L'uso di questa impostazione con un'identità gestita richiede WebJobs.Extensions.DurableTask v3.x o versione successiva oppure Worker.Extensions.DurableTask v1.2.x o versione successiva.
useGracefulShutdown falso (Anteprima) Un valore che indica se eseguire l'arresto in modo graduale per ridurre la probabilità che gli arresti dell'host causino il fallimento delle esecuzioni di funzioni in-process.
maxEntityOperationBatchSize Piano a consumo: 50
Piano dedicato o Premium: 5.000
Numero massimo di operazioni di entità elaborate come batch. Se questo valore è 1, l'invio in batch è disabilitato e una chiamata di funzione separata elabora ogni messaggio dell'operazione. Questa impostazione è disponibile a partire dalla versione 2.6.1.
storeInputsInOrchestrationHistory falso Valore che specifica come archiviare gli input. Quando questa impostazione è true, il Durable Task Framework salva gli input delle attività nella tabella Cronologia e gli input delle funzioni delle attività appaiono nei risultati delle query sulla cronologia dell'orchestrazione.
maxGrpcMessageSizeInBytes 4,194,304 Valore intero che imposta le dimensioni massime, in byte, dei messaggi che possono essere ricevuti dal client generico Remote Procedure Call (gRPC). L'implementazione di DurableTaskClient usa il client gRPC per gestire le istanze di orchestrazione. Questa impostazione si applica ai ruoli di lavoro isolati di Funzioni permanenti .NET e alle app Java.
grpcHttpClientTimeout 00:01:40 Timeout in formato hh:mm:ss per il client HTTP usato dal client gRPC in Durable Functions. Il client è attualmente supportato per le app di lavoro isolate .NET (.NET 6 e versioni successive) e per le app Java.
QueueClientMessageEncoding UTF8 Strategia di codifica per i messaggi di Archiviazione code di Azure. Le strategie valide sono Formato trasformazione Unicode a 8 bit (UTF8) e Base64. Questa impostazione si applica quando si usa Microsoft.Azure.WebJobs.Extensions.DurableTask 3.4.0 o versione successiva oppure Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.7.0 o versione successiva.

Molte di queste impostazioni sono per ottimizzare le prestazioni. Per altre informazioni, vedere Prestazioni e scalabilità.

Passaggi successivi