Associazioni per Funzioni permanenti (Funzioni di Azure)

  • Articolo

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

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 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 creare funzioni dell'agente 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 scadenze timer durevoli, risposte alle funzioni di attività ed eventi generati 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 dell'agente 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 che esporta inoltre elementi Decorator specifici di FunctionApp 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 garantire che il thread non esegua alcuna operazione asincrona, ad eccezione di quando è in attesa su tipi di attività specifiche di Funzioni permanenti.
  • 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 fino a quando l'app per le funzioni è in esecuzione e integra.
  • Valori restituiti - I valori restituiti vengono serializzati in JSON e salvati in modo permanente nella tabella di cronologia di orchestrazione nell'archiviazione tabelle di Azure. Su tali valori l'associazione client di orchestrazione può eseguire query, come descritto in seguito.

Avviso

Le funzioni dell'agente di orchestrazione non devono mai usare alcuna associazione di input o output diversa da quella di 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.

Avviso

Le funzioni dell'agente di orchestrazione non devono mai essere dichiarate async.

Utilizzo dei trigger

L'associazione di trigger di orchestrazione supporta sia input che output. Di seguito sono illustrati alcuni aspetti da conoscere sulla gestione di input e 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 valori di output in modo analogo ai valori 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 l'aspetto della funzione dell'agente di orchestrazione "Hello World" più semplice. Si noti che 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}!";
}

Nota

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

Nota

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à, pertanto viene riportato 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;
}

Nota

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

Trigger attività

Il trigger di attività consente di creare funzioni chiamate dalle funzioni dell'agente 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 dell'elemento 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 presentano restrizioni relative a threading oppure a operazioni di I/O e possono essere considerati come normali funzioni.
  • Gestione dei messaggi non elaborabili: non è disponibile alcun supporto per i messaggi non elaborabili 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 fino a quando l'app per le funzioni è 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. Di seguito sono illustrati alcuni aspetti da conoscere sulla gestione di input e output.

  • input: i trigger di attività possono essere richiamati con input da una funzione dell'agente di orchestrazione. Tutti gli input devono essere serializzabili in JSON.
  • output - Le funzioni di attività supportano i valori di output in modo analogo a quelli 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 .NET ActivityTriggerAttribute è IDurableActivityContext (o DurableActivityContext per Durable Functions v1). I trigger di attività .NET, tuttavia, supportano anche l'associazione diretta a tipi serializzabili in JSON, ad esempio tipi primitivi, e di conseguenza la stessa funzione potrebbe essere semplificata nel modo seguente:

[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, di conseguenza la stessa funzione potrebbe essere semplificata nel modo seguente:

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 inserire l'input nell'associazione di attività e inviare un messaggio a un hub eventi usando 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 client di orchestrazione consente di scrivere funzioni che interagiscono con le funzioni dell'agente di orchestrazione. Queste funzioni vengono spesso definite funzioni client. È possibile ad esempio agire su 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.
  • Ripulire la cronologia di istanza.

È 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 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": "orchestrationClient",
    "direction": "in"
}
  • taskHub - Usato in scenari in cui più app per le funzioni condividono lo stesso account di archiviazione, ma devono essere isolate tra loro. Se non specificato, viene usato il valore predefinito da host.json. Tale valore deve corrispondere a quello usato dalle funzioni dell'agente 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.

Nota

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 dell'elemento durable_client_input Decorator 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 DurableClientContext alla classe .

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

Nota

Il codice C# precedente è per Durable Functions 2.x. Per Durable Functions 1.x, è necessario usare OrchestrationClient l'attributo anziché l'attributo DurableClient ed è necessario usare il DurableOrchestrationClient tipo di IDurableOrchestrationClientparametro anziché . 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 di istanze, vedere Instance management (Gestione di istanze).

Trigger di entità

I trigger di entità consentono di creare funzioni di entità. Questo trigger supporta l'elaborazione di eventi per un'istanza di entità specifica.

Nota

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 bindings matrice 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.

Nota

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 dell'elemento entity_trigger Decorator 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 verranno elaborate una alla volta.
  • Gestione dei messaggi non elaborabili: non è disponibile alcun supporto per i messaggi non elaborabili nei trigger di entità.
  • Visibilità dei messaggi: i messaggi trigger di entità vengono dequeuati e mantenuti invisibili per una durata configurabile. La visibilità di questi messaggi viene rinnovata automaticamente fino a quando l'app per le funzioni è 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 altre informazioni ed esempi sulla definizione e l'interazione con i trigger di entità, vedere la documentazione sulle entità durevoli.

Client di entità

L'associazione client di entità consente di attivare in modo asincrono le funzioni di entità. Queste funzioni vengono talvolta definite funzioni client.

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

Nota

[DurableClientAttribute] Può essere usato anche per eseguire l'associazione 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 in scenari in cui più app per le funzioni condividono lo stesso account di archiviazione, ma devono essere isolate tra loro. Se non specificato, viene usato il valore predefinito da 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 questo stringa di connessione deve essere lo stesso usato dalle funzioni dell'entità di destinazione. Se non è specificato, viene usata la stringa di connessione dell'account di archiviazione predefinito dell'app per le funzioni.

Nota

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 dell'elemento durable_client_input Decorator direttamente nel codice della funzione Python.

Nota

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 Funzioni permanenti.

Nota

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 in uso. Gli esempi seguenti riguardano 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 file host.json deve trovarsi nella radice della configurazione host.json invece che in un campo sotto "extension".

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

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'app per le funzioni è TestHubName. Per altre informazioni, vedere Hub attività.

Proprietà Predefinito Descrizione
hubName TestHubName (DurableFunctionsHub se si usa Durable Functions 1.x) I nomi alternativi dell'hub attività possono essere usati per separare le applicazioni di Durable Functions, anche se usano lo stesso back-end di archiviazione.
controlQueueBatchSize 32 Numero di messaggi di cui eseguire il pull dalla coda di controllo contemporaneamente.
controlQueueBufferThreshold Piano a consumo per Python: 32
Piano a consumo per JavaScript e C#: 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.
partitionCount 4 Numero di partizioni per la coda di controllo. Può essere un numero intero positivo compreso tra 1 e 16.
controlQueueVisibilityTimeout 5 minuti Timeout di visibilità dei messaggi rimossi dalla coda di controllo.
workItemQueueVisibilityTimeout 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 contemporaneamente in una singola istanza host.
maxConcurrentOrchestratorFunctions Piano a 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 contemporaneamente in una singola istanza host.
maxQueuePollingInterval 30 secondi Intervallo massimo di polling della coda di controllo e degli elementi di lavoro nel formato hh:mm:ss. Valori più elevati possono comportare un incremento della latenza nell'elaborazione dei messaggi. Valori inferiori possono comportare un incremento dei costi di archiviazione a causa dell'aumento del numero di transazione di archiviazione.
connectionName (2.7.0 e versioni successive)
connectionStringName (2.x)
azure Archiviazione Connessione ionStringName (1.x)		 AzureWebJobsStorage Nome di un'impostazione o di una raccolta di impostazioni dell'app che specifica come connettersi alle risorse Archiviazione di Azure sottostanti. Quando viene specificata una singola impostazione dell'app, deve essere un Archiviazione di Azure stringa di connessione.
trackingStore Connessione ionName (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'app, deve essere un Archiviazione di Azure stringa di connessione. Se non è specificato, viene usata la connessione connectionStringName (Durable 2.x) o azureStorageConnectionStringName (Durable 1.x).
trackingStoreNamePrefix Prefisso da usare per le tabelle Cronologia e Istanze quando si specifica trackingStoreConnectionStringName. Se non è impostato, il valore predefinito del prefisso sarà DurableTask. Se trackingStoreConnectionStringName non è specificato, come prefisso delle tabelle Cronologia e Istanze verrà usato il valore hubName ed eventuali impostazioni di trackingStoreNamePrefix verranno ignorate.
traceInputsAndOutputs false Valore che indica se tenere traccia degli input e degli output di chiamate di funzione. Quando si tiene traccia degli eventi di esecuzione delle funzioni, il comportamento predefinito prevede di includere il numero di byte degli input e output serializzati per le chiamate di funzione. Con questo comportamento vengono offerte informazioni minime sull'aspetto di input e output senza aumentare il numero di log o esporre inavvertitamente informazioni riservate. Se questa proprietà viene impostata su true, per impostazione predefinita viene registrato l'intero contenuto degli input e output della funzione.
traceReplayEvents false 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. Se 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.
eventGridKeySettingName Nome dell'impostazione dell'app che contiene la chiave usata per l'autenticazione con l'argomento personalizzato di Griglia di eventi di Azure in EventGridTopicEndpoint.
eventGridPublishRetryCount 0 Il numero di tentativi se la pubblicazione nell'argomento di Griglia di eventi ha esito negativo.
eventGridPublishRetryInterval 5 minuti Intervallo fra i tentativi di pubblicazione in Griglia di eventi nel formato hh:mm:ss.
eventGridPublishEventTypes Elenco dei 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.
useAppLease true 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 su ripristino di emergenza e distribuzione geografica. Disponibile a partire dalla versione v2.3.0.
useLegacyPartitionManagement false 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.
useTablePartitionManagement false Se impostato su true, usa un algoritmo di gestione delle partizioni progettato per ridurre i costi per gli account Archiviazione di Azure V2. Disponibile a partire dalla versione 2.10.0. Questa funzionalità è attualmente in anteprima e non è ancora compatibile con il piano a consumo.
useGracefulShutdown false (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.
storeInputsInOrchestrationHistory false 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 sulla cronologia dell'orchestrazione.

Molte di queste impostazioni vengono usate 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