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.

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

Importante

Questo articolo supporta sia i modelli di programmazione Python v1 che Python v2 per Durable Functions.

Modello di programmazione Python v2

Durable Functions è supportato nel nuovo modello di programmazione Python v2. Per usare il modello v2, è necessario installare Durable Functions SDK, ovvero il pacchetto azure-functions-durablePyPI, la versione 1.2.2 o una versione successiva. È anche necessario verificare host.json per assicurarsi che l'app faccia riferimento ai bundle di estensioni versione 4.x per usare il modello v2 con Durable Functions.

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

Trigger di orchestrazione

Il trigger di orchestrazione consente di scrivere funzioni di orchestrazione 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 creano funzioni in .NET, il trigger di orchestrazione viene configurato usando l'attributo OrchestrationTriggerAttribute .NET.

Per Java, l'annotazione @DurableOrchestrationTrigger viene usata per configurare il trigger di orchestrazione.

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

{
    "name": "<Name of input parameter in function signature>",
    "orchestration": "<Optional - name of the orchestration>",
    "type": "orchestrationTrigger",
    "direction": "in"
}
  • orchestration è il nome dell'orchestrazione che i client devono usare quando vogliono avviare nuove istanze di questa funzione di orchestrazione. Questa proprietà è facoltativa. Se non specificato, viene usato il nome della funzione.

Funzioni di Azure supporta due modelli di programmazione per Python. Il modo in cui si definisce un trigger di orchestrazione dipende dal modello di programmazione scelto.

Il modello di programmazione Python v2 consente di definire un trigger di orchestrazione usando l'elemento orchestration_trigger Decorator direttamente nel codice della funzione Python.

Nel modello v2, i trigger e le associazioni di Durable Functions sono accessibili da un'istanza di DFApp, che è una sottoclasse di FunctionApp che esporta inoltre elementi Decorator specifici di Durable Functions.

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

Comportamento di trigger

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

  • Thread singolo - Un singolo thread del dispatcher viene usato per l'esecuzione di tutte le funzioni dell'agente di orchestrazione in un'unica istanza dell'host. Per questo motivo, è importante assicurarsi che il codice della funzione dell'agente di orchestrazione sia efficiente e non esegua operazioni 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 memorizzati nella tabella di cronologia di orchestrazione nell'archivio di tabelle di Azure. 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. In caso contrario, possono verificarsi problemi con l'estensione di attività permanenti in quanto tali associazioni potrebbero non rispettare le regole di thread singolo e di I/O. 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 la documentazione relativa ai vincoli di codice delle funzioni 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 alcuni aspetti da conoscere sulla gestione dell'input e dell'output:

  • input: i trigger di orchestrazione possono essere richiamati con input, a cui si accede 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 e deve essere serializzabile in JSON.

Esempio di trigger

Il codice di esempio seguente mostra come potrebbe apparire la funzione orchestratrice "Hello World" più semplice. Questo agente di orchestrazione di esempio non pianifica effettivamente alcuna attività.

L'attributo specifico usato per definire il trigger dipende dal fatto che si eseguano funzioni C# in-process o in un processo di lavoro isolato.

[FunctionName("HelloWorld")]
public static string Run([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 l'articolo Versioni di Durable Functions .

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

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

Annotazioni

La durable-functions libreria si occupa della chiamata al 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 dell'agente di orchestrazione chiama funzioni di attività, quindi ecco un esempio "Hello World" che illustra come chiamare una funzione di attività:

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

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 l'articolo Versioni di 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;
}

Attivatore di attività

Il trigger di attività consente di scrivere funzioni che vengono chiamate dalle funzioni di orchestrazione, note come funzioni di attività.

Il trigger di attività viene configurato usando l'attributo ActivityTriggerAttribute .NET.

Il trigger di attività viene configurato usando l'annotazione @DurableActivityTrigger .

Il trigger di attività è definito dall'oggetto JSON seguente nella bindings matrice di function.json:

{
    "name": "<Name of input parameter in function signature>",
    "activity": "<Optional - name of the activity>",
    "type": "activityTrigger",
    "direction": "in"
}
  • activity è 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 specificato, viene usato il nome della funzione.

Il modo in cui si definisce un trigger di attività dipende dal modello di programmazione scelto.

Uso del decoratore activity_trigger 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 relative al threading o all'I/O. Possono essere trattati come funzioni regolari.
  • Gestione dei messaggi avvelenati - Non è disponibile alcun supporto per i messaggi avvelenati 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 alcuni aspetti da conoscere 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.
  • metadata : 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 di esempio seguente mostra l'aspetto di una semplice SayHello funzione di attività.

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

Il tipo di parametro predefinito per l'associazione ActivityTriggerAttribute .NET è IDurableActivityContext (o DurableActivityContext per Durable Functions v1). Tuttavia, i trigger di attività .NET supportano anche l'associazione diretta a tipi serializzabili JSON (inclusi i tipi primitivi), quindi la stessa funzione potrebbe essere semplificata come indicato di seguito:

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

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

Le associazioni JavaScript possono anche essere passate come parametri aggiuntivi, quindi la stessa funzione può essere semplificata come indicato di seguito:

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

Uso di associazioni di input e output

È possibile usare associazioni regolari di input e output oltre all'associazione di trigger di attività.

Ad esempio, è possibile prendere l'input per l'associazione di attività e inviare un messaggio a un hub eventi utilizzando l'associazione di output di Hub Eventi.

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

L'associazione del client di orchestrazione consente di scrivere funzioni che interagiscono con le funzioni dell'agente di orchestrazione. 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.
  • Eliminare la cronologia delle istanze.

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

È possibile eseguire il binding al client di orchestrazione usando l'annotazione @DurableClientInput .

Il trigger del client durevole è definito dall'oggetto JSON seguente nella matrice bindings di 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 - Usato negli scenari in cui più app per le funzioni condividono lo stesso account di archiviazione, ma devono essere isolate l'una dall'altra. Se non specificato, viene utilizzato il valore predefinito di host.json . Questo valore deve corrispondere al valore usato dalle funzioni di orchestrazione di destinazione.
  • 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 usato dalle funzioni dell'agente di orchestrazione di destinazione. Se non è specificato, 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.

Il modo in cui si definisce un trigger client durevole dipende dal modello di programmazione scelto.

Uso del decoratore durable_client_input direttamente nel codice della funzione Python.

Uso del client

In genere si esegue l'associazione a IDurableClient (DurableOrchestrationClient in Durable Functions v1.x), che offre 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.

Ecco un esempio di funzione attivata dalla coda che avvia un'orchestrazione "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);
}

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 l'articolo Versioni di 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);
}

Per altre informazioni sull'avvio delle istanze, vedere Gestione delle istanze.

Trigger entità

I trigger di entità consentono di creare funzioni 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.

Il trigger di entità viene configurato usando l'attributo EntityTriggerAttribute .NET.

Il trigger di entità è definito dall'oggetto JSON seguente nella matrice bindings di function.json:

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

Per impostazione predefinita, il nome di un'entità è il nome della funzione.

Annotazioni

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

Il modo in cui si definisce un trigger di entità dipende dal modello di programmazione scelto.

Uso del decoratore entity_trigger direttamente nel codice della funzione Python.

Comportamento di trigger

Ecco alcune note sul trigger di entità:

  • Thread singolo: 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 di messaggi non elaborabili - I trigger di entità non supportano i messaggi non elaborabili.
  • 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 possono essere usate per salvare lo stato o passare di nuovo i valori alle orchestrazioni.

Qualsiasi modifica dello stato apportata a un'entità durante l'esecuzione verrà salvata automaticamente in modo permanente al termine dell'esecuzione.

Per ulteriori informazioni ed esempi sulla definizione e l'interazione con i trigger di entità, vedere la documentazione delle Durable Entities.

Client di entità

L'associazione client all'entità consente di 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

Il [DurableClientAttribute] può anche essere utilizzato per associarsi al client di orchestrazione.

Il client di entità è definito dall'oggetto JSON seguente nella bindings matrice di 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 - Usato negli scenari in cui più app per le funzioni condividono lo stesso account di archiviazione, ma devono essere isolate l'una dall'altra. Se non specificato, viene utilizzato il valore predefinito di host.json . Questo valore deve corrispondere al valore usato dalle funzioni di entità di destinazione.
  • 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 usato dalle funzioni di entità di destinazione. Se non è specificato, viene usata la stringa di connessione dell'account di archiviazione predefinito dell'app per le funzioni.

Annotazioni

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

Il modo in cui si definisce un client di entità dipende dal modello di programmazione scelto.

Uso del decoratore durable_client_input direttamente nel codice della funzione Python.

Annotazioni

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

Per altre informazioni ed esempi sull'interazione con le entità come client, vedere la documentazione sulle entità durevoli .

impostazioni host.json

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 è leggermente diverso a seconda della versione del runtime di Funzioni di Azure e della versione dell'estensione Durable Functions usata. Gli esempi seguenti sono per l'uso con Funzioni di Azure 2.0 e 3.0. In entrambi gli esempi, se si usa Funzioni di Azure 1.0, le impostazioni disponibili sono le stesse, ma la sezione "durableTask" del host.json deve trovarsi nella radice della configurazione host.json anziché come campo in "estensioni".

{
 "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": false,
      "useTablePartitionManagement": true,
      "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,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "storeInputsInOrchestrationHistory": false
  }
 }
}

I nomi degli hub attività devono iniziare con una lettera e contenere solo lettere e numeri. Se non specificato, il nome predefinito dell'hub attività per un'applicazione di funzioni è TestHubName. Per altre informazioni, vedere Hub attività.

Proprietà Impostazione predefinita Descrizione
hubName TestHubName (DurableFunctionsHub se si usa Durable Functions 1.x) I nomi alternativi dell'hub delle attività possono essere usati per isolare diverse applicazioni Durable Functions tra loro, anche se utilizzano lo stesso sistema di archiviazione.
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/Premium: 256		 Numero di messaggi della coda di controllo che possono essere memorizzati nel buffer in memoria contemporaneamente. Dopo tale soglia il dispatcher attenderà prima di rimuovere dalla coda eventuali 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. Può essere un numero intero positivo compreso tra 1 e 16. La modifica di questo valore richiede la configurazione di un nuovo hub attività.
controlQueueVisibilityTimeout (timeout di visibilità della coda di controllo) 5 minuti Timeout di visibilità dei messaggi rimossi dalla coda di controllo.
timeoutDiVisibilitàCodaElementoDiLavoro 5 minuti Timeout di visibilità dei messaggi rimossi dalla coda degli elementi di lavoro.
maxConcurrentActivityFunctions Piano a consumo: 10
Piano Dedicato/Premium: 10X 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/Premium: 10X 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/Premium: 10X 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 a maxConcurrentOrchestratorFunctions.
maxQueuePollingInterval 30 secondi 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.
connectionName (2.7.0 e versioni successive)
connectionStringName (2.x)
azureStorageConnectionStringName (1.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 viene specificata una singola impostazione dell’applicazione, deve essere una stringa di connessione all'archiviazione di Azure.
trackingStoreConnectionName (2.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. Quando viene specificata una singola impostazione dell’applicazione, deve essere una stringa di connessione all'archiviazione di Azure. Se non specificato, viene usata la connessione connectionStringName (Durable 2.x) o la connessione azureStorageConnectionStringName (Durable 1.x).
trackingStoreNamePrefix Prefisso da utilizzare per le tabelle Cronologia e Istanze quando trackingStoreConnectionStringName viene specificato . Se non è impostato, il valore del prefisso predefinito sarà DurableTask. Se trackingStoreConnectionStringName non viene specificato, le tabelle Cronologia e Istanze useranno il hubName valore come prefisso e qualsiasi impostazione per trackingStoreNamePrefix verrà ignorata.
traceInputsAndOutputs falso Valore che indica se tracciare gli input e gli output delle chiamate di funzione. Il comportamento predefinito quando si tracciano gli eventi di esecuzione della funzione consiste nell'includere il numero di byte negli input serializzati e negli output per le chiamate di funzione. Questo comportamento fornisce informazioni minime sull'aspetto degli input e degli output senza gonfiare i log o esporre inavvertitamente le informazioni riservate. Se si imposta questa proprietà su true, la registrazione delle funzioni predefinita registra 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.
eventGridTopicEndpoint URL di un endpoint di un argomento personalizzato di Griglia di eventi di Azure. Quando questa proprietà è impostata, gli eventi di notifica del ciclo di vita dell'orchestrazione vengono pubblicati in questo endpoint. Questa proprietà supporta la risoluzione delle impostazioni dell'app.
NomeImpostazioneChiaveEventGrid Nome dell'impostazione dell'app contenente la chiave usata per l'autenticazione con l'argomento personalizzato di Griglia di eventi di Azure all'indirizzo EventGridTopicEndpoint.
eventGridPublishRetryCount 0 Il numero di tentativi se la pubblicazione nell'argomento di Griglia di eventi ha esito negativo.
eventGridPublishRetryInterval 5 minuti Griglia di eventi pubblica l'intervallo di ripetizione dei tentativi nel formato hh:mm:ss .
TipiDiEventiPubblicatiSuEventGrid Elenco di tipi di evento da pubblicare in Griglia di eventi. Se non specificato, verranno pubblicati tutti i tipi di evento. I valori consentiti includono Started, Completed, Failed, Terminated.
usaAppLease vero Se è impostato su true, le app richiederanno l'acquisizione di un lease di BLOB a livello di app prima di elaborare i messaggi dell'hub attività. Per altre informazioni, vedere la documentazione sul ripristino di emergenza e sulla distribuzione geografica . Disponibile a partire dalla versione 2.3.0.
Utilizzare gestione partizioni legacy falso Se impostato su false, usa un algoritmo di gestione delle partizioni che riduce la possibilità di esecuzione di funzioni duplicate durante l'aumento del numero di istanze. Disponibile a partire dalla versione 2.3.0. L'impostazione di questo valore su true non è consigliata.
useTablePartitionManagement true in versioni dell’estensione v3.x
false in versioni dell’estensione v2.x		 Se impostato su true, usa un algoritmo di gestione delle partizioni progettato per ridurre i costi per gli account di Archiviazione di Azure V2. Disponibile a partire da WebJobs.Extensions.DurableTask v2.10.0. L'uso di questa impostazione con l'identità gestita richiede WebJobs.Extensions.DurableTask v3.x o versioni successive o Worker.Extensions.DurableTask precedenti alla versione 1.2.x o successiva.
utilizzaSpegnimentoGraduale falso (Anteprima) Abilita l'arresto in modalità normale per ridurre la possibilità di arresti dell'host che non riescono a completare le esecuzioni di funzioni in-process.
maxEntityOperationBatchSize(2.6.1) Piano a consumo: 50
Piano Dedicato/Premium: 5000		 Numero massimo di operazioni di entità elaborate come batch. Se impostato su 1, l'invio in batch è disabilitato e ogni messaggio dell'operazione viene elaborato da una chiamata di funzione separata.
memorizzaDatiNellaStoriaDell'Orchestrazione falso Se impostato su true, indica a Durable Task Framework di salvare gli input dell'attività nella tabella della cronologia. In questo modo, è possibile visualizzare gli input della funzione di attività durante l'esecuzione di query della cronologia dell'orchestrazione.
maxGrpcMessageSizeInBytes 4194304 Valore intero che imposta le dimensioni massime, in byte, dei messaggi che il client gRPC per DurableTaskClient può ricevere. Questo vale per Durable Functions .NET isolato e Java.
grpcHttpClientTimeout 100 secondi Imposta il timeout per il client HTTP usato dal client gRPC in Durable Functions, attualmente supportato per le app isolate .NET (.NET 6 e versioni successive) e per Java.

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

Passaggi successivi

Informazioni di riferimento sulle API HTTP predefinite per la gestione delle istanze