Freigeben über


Anbindungen für Durable Functions (Azure Functions)

Die Erweiterung Durable Functions führt drei Triggerbindungen ein, die die Ausführung von Orchestrator-, Entitäts- und Aktivitätsfunktionen steuern. Außerdem wird eine Ausgabebindung eingeführt, die als Client für die Durable Functions Laufzeitumgebung fungiert.

In diesem Artikel wird die Verwendung dieser vier Bindungen erläutert und Codebeispiele bereitgestellt. Außerdem enthält sie Informationen zu den Durable Functions Konfigurationseigenschaften in host.json, der Metadatendatei, die Einstellungen enthält, die sich auf alle Funktionen in einer Funktions-App auswirken.

Stellen Sie sicher, dass Sie ihre Durable Functions Entwicklungssprache oben im Artikel auswählen.

Beide Versionen des Python-Programmiermodells für Azure Functions werden von Durable Functions unterstützt. Da Python v2 die empfohlene Version ist, enthalten Beispiele in diesem Artikel ausschließlich diese Version.

Voraussetzungen

  • Durable Functions SDK, das das Python Package Index (PyPI)-Paket azure-functions-durable, Version 1.2.2 oder höher ist
  • Erweiterungspaket Version 4.x (oder eine höhere Version), die in der host.json Projektdatei festgelegt wird

Sie können Feedback und Vorschläge im Durable Functions SDK für Python Repository bereitstellen.

Orchestrierungstrigger

Sie können den Orchestrierungstrigger verwenden, um dauerhafte Orchestratorfunktionen zu entwickeln. Dieser Trigger wird ausgeführt, wenn eine neue Orchestrierungsinstanz geplant wird und eine vorhandene Orchestrierungsinstanz ein Ereignis empfängt. Beispiele für Ereignisse, die Orchestratorfunktionen auslösen können, sind dauerhafte Timerablauf, Aktivitätsfunktionsantworten und Ereignisse, die von externen Clients ausgelöst werden.

Wenn Sie Funktionen in .NET entwickeln, verwenden Sie das Attribut OrchestrationTriggerAttribute .NET zum Konfigurieren des Orchestrierungstriggers.

Für Java verwenden Sie die @DurableOrchestrationTrigger Anmerkung, um den Orchestrierungstrigger zu konfigurieren.

Wenn Sie Version 4 des Node.js Programmiermodells zum Entwickeln von Funktionen verwenden, importieren Sie das app Objekt aus dem @azure/functions npm Modul. Anschließend rufen Sie die app.orchestration-Methode der Durable Functions-API direkt in Ihrem Funktionscode auf. Diese Methode registriert Ihre Orchestratorfunktion mit dem Durable Functions Framework.

Wenn Sie Orchestratorfunktionen schreiben, definieren Sie den Orchestrierungstrigger mithilfe des folgenden JSON-Objekts im bindings Array der function.json-Datei :

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

Der orchestration Wert ist der Name der Orchestrierung, die Clients verwenden müssen, wenn sie neue Instanzen der Orchestratorfunktion starten möchten. Diese Eigenschaft ist optional. Wenn Sie sie nicht angeben, wird der Name der Funktion verwendet.

Wenn Sie das Python v2-Programmiermodell verwenden, können Sie einen Orchestrierungstrigger mithilfe des orchestration_trigger Dekorators direkt in Ihrem Python Funktionscode definieren.

Im v2-Modell greifen Sie auf die Durable Functions Trigger und Bindungen aus einer Instanz von DFApp zu. Sie können diese Unterklasse von FunctionApp verwenden, um Dekorateure zu exportieren, die für Durable Functions spezifisch sind.

Diese Triggerbindung überprüft intern den konfigurierten persistenten Speicher auf neue Orchestrierungsereignisse. Beispiele für Ereignisse sind Orchestrierungsstartereignisse, dauerhafte Ablaufereignisse des Zeitgebers, Reaktionsereignisse der Aktivitätsfunktion und externe Ereignisse, die von anderen Funktionen ausgelöst werden.

Triggerverhalten

Hier sind einige Notizen zum Orchestrierungsauslöser:

  • Single-Threading: Ein einzelner Dispatcherthread wird für die Ausführung aller Orchestratorfunktionen in einer einzigen Hostinstanz verwendet. Aus diesem Grund ist es wichtig, sicherzustellen, dass Orchestratorfunktionscode effizient ist und keine E/A-Vorgänge ausführt. Es ist auch wichtig, sicherzustellen, dass dieser Thread keine asynchrone Arbeit abnimmt, außer beim Warten auf Aufgabentypen, die spezifisch für Durable Functions sind.
  • Umgang mit Giftnachrichten: Es gibt keine Unterstützung für Giftnachrichten in Orchestrierungsauslösern.
  • Nachrichtensichtbarkeit: Nachrichten zur Orchestrierungsauslösung werden aus der Warteschlange entfernt und für eine konfigurierbare Dauer unsichtbar gehalten. Die Sichtbarkeit dieser Nachrichten wird automatisch verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Return-Werte: Rückgabewerte werden in JSON serialisiert und in der Orchestrierungsverlaufstabelle in Azure Table Storage beibehalten. Diese Rückgabewerte können von der Orchestrierungsclientbindung abgefragt werden, die später beschrieben wird.

Warnung

Orchestratorfunktionen sollten niemals andere Eingabe- oder Ausgabebindungen als die Orchestrierungstriggerbindung verwenden. Die Verwendung anderer Bindungen kann zu Problemen mit der Durable-Task-Erweiterung führen, da solche Bindungen möglicherweise nicht den Regeln für Singlethreading und Ein-/Ausgabe gehorchen. Wenn Sie andere Bindungen verwenden möchten, fügen Sie sie einer Aktivitätsfunktion hinzu, die von Ihrer Orchestratorfunktion aufgerufen wird. Weitere Informationen zum Codieren von Einschränkungen für Orchestratorfunktionen finden Sie unter Orchestrator-Funktionscodeeinschränkungen.

Warnung

Orchestrator-Funktionen sollten niemals deklariert asyncwerden.

Triggerverwendung

Die Orchestrierungstriggerbindung unterstützt sowohl Ein- als auch Ausgaben. Hier sind einige Hinweise zur Eingabe- und Ausgabebehandlung:

  • Eingaben: Sie können Orchestrierungstrigger mit Eingaben aufrufen. Auf die Eingaben wird über das Kontexteingabeobjekt zugegriffen. Alle Eingaben müssen JSON-serialisierbar sein.
  • Ausgaben: Orchestrierungstrigger unterstützen sowohl Ausgabe- als auch Eingabewerte. Der Rückgabewert der Funktion wird verwendet, um den Ausgabewert zuzuweisen. Der Rückgabewert muss JSON-serialisierbar sein.

Triggerbeispiel

Der folgende Code enthält ein Beispiel für eine einfache Hello World Orchestratorfunktion. In diesem Beispiel-Orchestrator werden keine Aufgaben geplant.

Das Attribut, das Sie zum Definieren des Triggers verwenden, hängt davon ab, ob Sie Ihre C#-Funktionen im selben Prozess wie der Hostprozess "Functions" oder in einem isolierten Arbeitsprozess ausführen.

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

Hinweis

Der vorangehende Code gilt für Durable Functions 2.x. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie unter Durable Functions Versionsübersicht.

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

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

Hinweis

Die durable-functions Bibliothek ruft die synchrone context.done Methode auf, wenn die Generatorfunktion beendet wird.

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

Die meisten Orchestratorfunktionen rufen Aktivitätsfunktionen auf. Der folgende Code enthält ein Hello World Beispiel zum Aufrufen einer Aktivitätsfunktion:

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

Hinweis

Der vorangehende Code gilt für Durable Functions 2.x. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie unter Durable Functions Versionsübersicht.

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

Aktivitätsauslöser

Sie können den Aktivitätstrigger verwenden, um Funktionen zu entwickeln, die als Aktivitätsfunktionen bezeichnet werden, die von Orchestratorfunktionen aufgerufen werden.

Sie verwenden das Attribut ActivityTriggerAttribute .NET zum Konfigurieren des Aktivitätstriggers.

Sie verwenden die @DurableActivityTrigger Anmerkung, um den Aktivitätstrigger zu konfigurieren.

Um Ihre Aktivitätsfunktion zu registrieren, importieren Sie das app Objekt aus dem @azure/functions npm Modul. Anschließend rufen Sie die app.activity-Methode der Durable Functions-API direkt in Ihrem Funktionscode auf.

Um den Aktivitätsauslöser zu definieren, verwenden Sie das folgende JSON-Objekt im bindings Array von function.json:

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

Der activity Wert ist der Name der Aktivität. Dieser Wert ist der Name, den Orchestratorfunktionen zum Aufrufen dieser Aktivitätsfunktion verwenden. Diese Eigenschaft ist optional. Wenn Sie sie nicht angeben, wird der Name der Funktion verwendet.

Sie können einen Aktivitätsauslöser definieren, indem Sie den activity_trigger-Dekoror direkt in Ihrem Python Funktionscode verwenden.

Intern werden mit dieser Triggerbindung neue Aktivitätsausführungsereignisse vom konfigurierten permanenten Speicher abgefragt.

Triggerverhalten

Hier sind einige Hinweise zum Aktivitätsauslöser:

  • Threading: Im Gegensatz zum Orchestrierungstrigger haben Aktivitätstrigger keine Einschränkungen für Threading- oder E/A-Vorgänge. Sie können wie normale Funktionen behandelt werden.
  • Umgang mit Giftnachrichten: Es gibt keine Unterstützung für Giftnachrichten in Aktivitätsauslösern.
  • Sichtbarkeit von Nachrichten: Nachrichten des Aktivitätstriggers werden aus der Warteschlange entfernt und bleiben für eine konfigurierbare Dauer unsichtbar. Die Sichtbarkeit dieser Nachrichten wird automatisch verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Rückgabewerte: Rückgabewerte werden in JSON serialisiert und im konfigurierten dauerhaften Speicher beibehalten.

Triggerverwendung

Die Aktivitätstriggerbindung unterstützt sowohl Eingaben als auch Ausgaben, genau wie der Orchestrierungstrigger. Hier sind einige Hinweise zur Eingabe- und Ausgabebehandlung:

  • Eingaben: Aktivitätstrigger können mit Eingaben aus einer Orchestratorfunktion aufgerufen werden. Alle Eingaben müssen JSON-serialisierbar sein.
  • Ausgaben: Aktivitätsfunktionen unterstützen sowohl Ausgabe- als auch Eingabewerte. Der Rückgabewert der Funktion wird verwendet, um den Ausgabewert zuzuweisen, und muss JSON-serialisierbar sein.
  • Metadata: .NET Aktivitätsfunktionen können eine Bindung an einen parameter string instanceId herstellen, um die Instanz-ID der aufrufenden Orchestrierung abzurufen.

Triggerbeispiel

Der folgende Code stellt ein Beispiel für eine einfache Hello World-Aktivitätsfunktion bereit.

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

Der Standardparametertyp für die bindung .NET ActivityTriggerAttribute ist IDurableActivityContext (oder DurableActivityContext für Durable Functions 1.x). .NET Aktivitätstrigger unterstützen jedoch auch die direkte Bindung an JSON-serialisierbare Typen (einschließlich primitiver Typen), sodass Sie auch die folgende vereinfachte Version der Funktion verwenden können:

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

Verwenden von Eingabe- und Ausgabebindungen

Neben der Aktivitätstriggerbindung können Sie auch normale Eingabe- und Ausgabebindungen verwenden.

Beispielsweise kann eine Aktivitätsfunktion Eingaben von einer Orchestratorfunktion empfangen. Die Aktivitätsfunktion kann diese Eingabe dann als Nachricht an Azure Event Hubs senden.

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

Orchestrierungsclient

Sie können die Orchestrierungsclientbindung verwenden, um Funktionen zu schreiben, die mit Orchestratorfunktionen interagieren. Diese Funktionen werden häufig als Clientfunktionen bezeichnet. Sie können beispielsweise auf Orchestrierungsinstanzen in den folgenden Weisen reagieren:

  • Starten
  • Fragen Sie ihren Status ab.
  • Eliminieren Sie sie.
  • Senden von Ereignissen an die Instanzen während der Ausführung
  • Bereinigen Sie den Instanzverlauf.

Sie können eine Bindung an einen Orchestrierungsclient mithilfe des Attributs DurableClientAttribute (OrchestrationClientAttribute in Durable Functions 1.x) herstellen.

Sie können eine Bindung an einen Orchestrierungsclient mithilfe der @DurableClientInput Anmerkung herstellen.

Um Ihre Clientfunktion zu registrieren, importieren Sie das app Objekt aus dem @azure/functions npm Modul. Anschließend rufen Sie eine Durable Functions API-Methode auf, die spezifisch für Ihren Triggertyp ist. Für einen HTTP-Trigger rufen Sie beispielsweise die app.http Methode auf. Für einen Warteschlangentrigger rufen Sie die app.storageQueue Methode auf.

Um den dauerhaften Clienttrigger zu definieren, verwenden Sie das folgende JSON-Objekt im bindings Array von 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"
}
  • Die taskHub Eigenschaft wird verwendet, wenn mehrere Funktions-Apps dasselbe Speicherkonto gemeinsam nutzen, aber voneinander isoliert werden müssen. Wenn Sie diese Eigenschaft nicht angeben, wird der Standardwert aus host.json verwendet. Dieser Wert muss mit dem Wert übereinstimmen, den die Ziel-Orchestratorfunktionen verwenden.
  • Der Wert connectionName ist der Name einer App-Einstellungen, die eine Speicherkonto-Verbindungszeichenfolge enthält. Das Speicherkonto, das durch diese Verbindungszeichenfolge dargestellt wird, muss dasselbe sein, das auch die Ziel-Orchestratorfunktionen verwenden. Wenn Sie diese Eigenschaft nicht angeben, wird die Standardspeicherkonto-Verbindungszeichenfolge für die Funktions-App verwendet.

Hinweis

In den meisten Fällen wird empfohlen, diese Eigenschaften wegzulassen und das Standardverhalten zu verwenden.

Sie können einen dauerhaften Clienttrigger definieren, indem Sie den durable_client_input-Dekoror direkt in Ihrem Python Funktionscode verwenden.

Kundennutzung

In der Regel binden Sie an eine Implementierung von IDurableClient (DurableOrchestrationClient in Durable Functions 1.x), damit Sie vollständigen Zugriff auf alle Orchestrierungsclient-APIs erhalten, die Durable Functions unterstützt.

Sie binden in der Regel an die DurableClientContext Klasse.

Sie müssen das sprachspezifische SDK verwenden, um Zugriff auf ein Clientobjekt zu erhalten.

Der folgende Code stellt ein Beispiel für eine Warteschlangen-auslöser-Funktion bereit, die eine Hello World Orchestrierung startet.

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

Hinweis

Der vorangehende C#-Code ist für Durable Functions 2.x vorgesehen. Für Durable Functions 1.x müssen Sie das Attribut OrchestrationClient anstelle des Attributs DurableClient verwenden, und Sie müssen den Parametertyp DurableOrchestrationClient anstelle von IDurableOrchestrationClient verwenden. Weitere Informationen zu den Unterschieden zwischen den Versionen finden Sie unter Durable Functions Versionsübersicht.

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

Detaillierte Informationen zum Starten von Instanzen finden Sie unter Verwalten von Instanzen in Durable Functions in Azure.

Entitätstrigger

Sie können den Entitätstrigger verwenden, um eine Entitätsfunktion zu entwickeln. Dieser Trigger unterstützt die Verarbeitung von Ereignissen für eine bestimmte Entitätsinstanz.

Hinweis

Entitätstrigger sind ab Durable Functions 2.x verfügbar.

Intern werden mit dieser Triggerbindung neue Entitätsvorgänge, die ausgeführt werden müssen, vom konfigurierten permanenten Speicher abgefragt.

Sie verwenden das Attribut EntityTriggerAttribute .NET zum Konfigurieren des Entitätstriggers.

Um den Entitätstrigger zu registrieren, importieren Sie das app Objekt aus dem @azure/functions npm Modul. Anschließend rufen Sie die app.entity-Methode der Durable Functions-API direkt in Ihrem Funktionscode auf.

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

Hinweis

Entitätstrigger werden für Java noch nicht unterstützt.

Hinweis

Entitätstrigger werden für PowerShell noch nicht unterstützt.

Sie können einen Entitätstrigger definieren, indem Sie den entity_trigger-Dekoror direkt in Ihrem Python Funktionscode verwenden.

Triggerverhalten

Hier sind einige Hinweise zum Entitätsauslöser:

  • Single-Threading: Ein einzelner Dispatcherthread wird verwendet, um Vorgänge für eine bestimmte Entität zu verarbeiten. Wenn mehrere Nachrichten gleichzeitig an eine einzelne Entität gesendet werden, werden die Vorgänge einzeln verarbeitet.
  • Behandlung von Giftnachrichten: Es gibt keine Unterstützung für Giftnachrichten in Entitätsauslösern.
  • Sichtbarkeit von Nachrichten: Nachrichten des Entitätstriggers werden aus der Warteschlange entfernt und bleiben für eine konfigurierbare Dauer unsichtbar. Die Sichtbarkeit dieser Nachrichten wird automatisch verlängert, solange die Funktions-App ausgeführt und fehlerfrei ist.
  • Rückgabewerte: Entitätsfunktionen unterstützen keine Rückgabewerte. Es gibt bestimmte APIs, mit denen Sie Status speichern oder Werte an Orchestrierungen zurückgeben können.

Alle Zustandsänderungen, die während der Ausführung an einer Entität vorgenommen wurden, werden nach Abschluss der Ausführung automatisch beibehalten.

Weitere Informationen und Beispiele für das Definieren und Interagieren mit Entitätstriggern finden Sie unter Entitätsfunktionen.

Entitäts-Client

Sie können die Entitätsclientbindung verwenden, um Entitätsfunktionen asynchron auszulösen. Diese Funktionen werden manchmal als Clientfunktionen bezeichnet.

Sie können eine Bindung an den Entitätsclient herstellen, indem Sie das Attribut DurableClientAttribute .NET in .NET Klassenbibliotheksfunktionen verwenden.

Hinweis

Sie können auch [DurableClientAttribute] verwenden, um an den Orchestrierungsclient zu binden.

Anstatt einen Entitätsclient zu registrieren, verwenden Sie signalEntity oder callEntity, um eine Entitätstriggermethode aus einer beliebigen registrierten Funktion aufzurufen.

  • Aus einer von einer Warteschlange ausgelösten Funktion können Sie client.signalEntity verwenden:

    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);
        },
    });
    
  • Über eine Orchestratorfunktion können Sie context.df.callEntity verwenden:

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

Sie können einen Entitätsclient mithilfe des durable_client_input-Dekorators direkt in Ihrem Python Funktionscode definieren.

Hinweis

Entitätsclients werden für Java noch nicht unterstützt.

Hinweis

Entitätsclients werden für PowerShell noch nicht unterstützt.

Weitere Informationen und Beispiele für die Interaktion mit Entitäten als Client finden Sie unter Access-Entitäten.

Durable Functions Einstellungen in host.json

Dieser Abschnitt enthält Informationen zu den Durable Functions Konfigurationseigenschaften in host.json. Informationen zu allgemeinen Einstellungen in host.json finden Sie unter host.json Referenz für Azure Functions 1.x oder host.json Referenz für Azure Functions 2.x und höher.

Konfigurationseinstellungen für Durable Functions.

Hinweis

Alle Hauptversionen von Durable Functions werden in allen Versionen der Azure Functions Laufzeit unterstützt. Das Schema der host.jsonkonfiguration unterscheidet sich jedoch geringfügig je nach Version der Azure Functions Laufzeit und der Version der verwendeten Durable Functions-Erweiterung.

Der folgende Code enthält zwei Beispiele für durableTask-Einstellungen in host.json: eine für Durable Functions 2.x und eine für Durable Functions 1.x. Sie können beide Beispiele mit Azure Functions 2.0 und 3.0 verwenden. Mit Azure Functions 1.0 sind die verfügbaren Einstellungen identisch, aber der durableTask Abschnitt von host.json befindet sich im Stammverzeichnis der host.jsonkonfiguration, anstatt ein Feld unter extensions zu sein.

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "defaultVersion": "1.0",
    "versionMatchStrategy": "CurrentOrOlder",
    "versionFailureStrategy": "Reject",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "FetchLargeMessagesAutomatically": true,
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": false,
      "useTablePartitionManagement": true,
      "workItemQueueVisibilityTimeout": "00:05:00",
      "QueueClientMessageEncoding": "UTF8"
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "httpSettings":{
      "defaultAsyncRequestSleepTimeMilliseconds": 30000,
      "useForwardedHost": false,
    },
    "notifications": {
      "eventGrid": {
        "topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
        "keySettingName": "EventGridKey",
        "publishRetryCount": 3,
        "publishRetryInterval": "00:00:30",
        "publishEventTypes": [
          "Started",
          "Completed",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "storeInputsInOrchestrationHistory": false
  }
 }
}
Eigentum Standardwert BESCHREIBUNG
hubName TestHubName (DurableFunctionsHub in v1.x) Der Name des Hubs, der den aktuellen Zustand einer Funktions-App speichert. Aufgabenhubnamen müssen mit einem Buchstaben beginnen und bestehen nur aus Buchstaben und Ziffern. Wenn Sie keinen Namen angeben, wird der Standardwert verwendet. Alternative Aufgabenhubnamen können verwendet werden, um mehrere Durable Functions Anwendungen voneinander zu isolieren, auch wenn sie dasselbe Speicher-Back-End verwenden. Weitere Informationen finden Sie unter Task Hubs.
defaultVersion Die Standardversion, die auf neue Orchestrierungsinstanzen angewendet wird. Wenn Sie eine Version angeben, werden neue Orchestrierungsinstanzen dauerhaft diesem Versionswert zugeordnet. Diese Einstellung wird von der Orchestrierungsversionsfunktion verwendet, um Szenarien wie Bereitstellungen ohne Ausfallzeiten mit unterbrechungsfreien Änderungen zu ermöglichen. Sie können einen beliebigen Zeichenfolgenwert für die Version verwenden.
Versionsabgleich-Strategie CurrentOrOlder Ein Wert, der angibt, wie Orchestrierungsversionen beim Laden von Orchestratorfunktionen übereinstimmen. Gültige Werte sind None, Strictund CurrentOrOlder. Ausführliche Erläuterungen finden Sie unter "Orchestrierungsversionierung".
versionFailureStrategy Ablehnen Ein Wert, der angibt, was passiert, wenn eine Orchestrierungsversion nicht mit dem aktuellen defaultVersion Wert übereinstimmt. Gültige Werte sind Reject und Fail. Ausführliche Erläuterungen finden Sie unter "Orchestrierungsversionierung".
controlQueueBatchSize 32 Die Anzahl der aus der Steuerelement-Warteschlange jeweils abzurufenden Nachrichten.
controlQueueBufferThreshold Verbrauchsplan für Python: 32
Verbrauchsplan für andere Sprachen: 128
Dedizierter oder Premium-Plan: 256
Die Anzahl der Kontrollwarteschlangenmeldungen, die gleichzeitig im Arbeitsspeicher gepuffert werden können. Wenn die angegebene Zahl erreicht ist, wartet der Dispatcher, bevor andere Nachrichten aus der Warteschlange entfernt werden. In einigen Fällen kann die Verringerung dieses Werts die Arbeitsspeicherauslastung erheblich reduzieren.
partitionCount 4 Die Anzahl der Partitionen für die Steuerelement-Warteschlange. Dieser Wert muss eine positive ganze Zahl zwischen 1 und 16 sein. Zum Ändern dieses Werts muss ein neuer Aufgabenhub konfiguriert werden.
controlQueueVisibilityTimeout 00:05:00 Das Timeout für die Sichtbarkeit von Nachrichten aus Steuerungswarteschlangen im Format hh:mm:ss.
workItemQueueVisibilityTimeout 00:05:00 Das Timeout für sichtbarkeitsbedingte Warteschlangenmeldungen für Arbeitsaufgaben im hh:mm:ss-Format .
GroßeNachrichtenAutomatischAbrufen Wahr Ein Wert, der angibt, ob große Nachrichten in Orchestrierungsstatusabfragen abgerufen werden sollen. Wenn diese Einstellung lautet true, werden große Nachrichten, die den Grenzwert für die Warteschlangengröße überschreiten, abgerufen. Wenn diese Einstellung lautet false, wird eine BLOB-URL abgerufen, die auf jede große Nachricht verweist.
maxConcurrentActivityFunctions Verbrauchsplan: 10
Dedizierter oder Premium-Plan: 10 mal die Anzahl der Prozessoren auf dem aktuellen Computer
Die maximale Anzahl von Aktivitätsfunktionen, die gleichzeitig auf einer einzelnen Hostinstanz verarbeitet werden können.
maxConcurrentOrchestratorFunctions Verbrauchsplan: 5
Dedizierter oder Premium-Plan: 10 mal die Anzahl der Prozessoren auf dem aktuellen Computer
Die maximale Anzahl von Orchestratorfunktionen, die gleichzeitig auf einer einzelnen Hostinstanz verarbeitet werden können.
maxConcurrentEntityFunctions Verbrauchsplan: 5
Dedizierter oder Premium-Plan: 10 mal die Anzahl der Prozessoren auf dem aktuellen Computer
Die maximale Anzahl von Entitätsfunktionen, die gleichzeitig in einer einzelnen Hostinstanz verarbeitet werden können. Diese Einstellung gilt nur, wenn Sie den dauerhaften Vorgangsplaner verwenden. Andernfalls ist die maximale Anzahl gleichzeitiger Entitätsausführungen auf den maxConcurrentOrchestratorFunctions Wert beschränkt.
maxQueuePollingInterval 00:00:30 Das maximale Steuerungsintervall und das Abfrageintervall der Arbeitsaufgaben-Warteschlange im hh:mm:ss-Format. Höhere Werte können zu höherer Latenz bei der Nachrichtenverarbeitung führen. Niedrigere Werte können aufgrund verstärkter Speichertransaktionen zu höheren Speicherkosten führen.
maxOrchestrationActions 100,000 Die maximale Anzahl von Aktionen, die eine Orchestratorfunktion während eines einzelnen Ausführungszyklus ausführen kann.
connectionName (v2.7.0 und höher)
connectionStringName (v2.x)
azureStorageConnectionStringName (v1.x)
AzureWebJobsStorage Der Name einer App-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit den zugrunde liegenden Azure Storage Ressourcen hergestellt werden soll. Wenn Sie eine einzelne App-Einstellung bereitstellen, sollte es sich um eine Azure Storage connection string handeln.
trackingStoreConnectionName (v2.7.0 und höher)
trackingStoreConnectionStringName
Der Name einer App-Einstellungs- oder Einstellungsauflistung, die angibt, wie eine Verbindung mit den Tabellen "Verlauf" und "Instanzen" hergestellt werden soll, die den Ausführungsverlauf und Metadaten zu Orchestrierungsinstanzen speichern. Wenn Sie eine einzelne App-Einstellung bereitstellen, sollte es sich um eine Azure Storage connection string handeln. Wenn Sie keine Einstellung angeben, wird der connectionStringName-Wert (v2.x) oder der azureStorageConnectionStringName-Wert (v1.x) der Verbindung verwendet.
trackingStoreNamePrefix Das für die Verlaufs- und Instanzentabellen zu verwendende Präfix, wenn trackingStoreConnectionStringName angegeben ist. Wenn Sie kein Präfix angeben, wird der Standardwert DurableTask verwendet. Wenn trackingStoreConnectionStringName nicht angegeben, verwenden die Tabellen "Verlauf" und "Instanzen" den hubName Wert als Präfix, und die trackingStoreNamePrefix Einstellung wird ignoriert.
traceInputsAndOutputs Falsch Ein Wert, der angibt, ob die Eingaben und Ausgaben von Funktionsaufrufen nachverfolgt werden sollen. Wenn Funktionsausführungsereignisse nachverfolgt werden, besteht das Standardverhalten darin, die Anzahl der Bytes in die serialisierten Eingaben und Ausgaben für Funktionsaufrufe einzuschließen. Dieses Verhalten bietet minimale Informationen zu den Eingaben und Ausgaben, sodass die Protokolle nicht aufgebläht werden oder versehentlich vertrauliche Informationen verfügbar gemacht werden. Wenn diese Eigenschaft lautet true, werden der gesamte Inhalt der Funktionseingaben und -ausgaben protokolliert.
traceReplayEvents Falsch Ein Wert, der angibt, ob Orchestrierungs-Wiederholungsereignisse in Application Insights geschrieben werden sollen.
Ereigniswiedergabe protokollieren (logReplayEvents) Falsch Ein Wert, der angibt, ob wiederholte Ausführungen in Anwendungsprotokollen protokolliert werden sollen.
eventGridTopicEndpoint Die URL eines Azure Event Grid benutzerdefinierten Themenendpunkts. Wenn Sie diese Eigenschaft festlegen, werden Benachrichtigungsereignisse des Orchestrierungslebenszyklus für diesen Endpunkt veröffentlicht. Diese Eigenschaft unterstützt die Auflösung von App-Einstellungen.
eventGridKeySettingName Der Name der App-Einstellung, die den Schlüssel enthält, der für die Authentifizierung mit dem benutzerdefinierten Ereignisrasterthema unter der EventGridTopicEndpoint URL verwendet wird.
eventGridPublishRetryCount 0 Die Anzahl der Versuche, wenn das Veröffentlichen in einem Event Grid-Thema fehlschlägt.
eventGridPublishRetryInterval 00:05:00 Das Event Grid Veröffentlichungs-Wiederholungsintervall im Format hh:mm:ss.
eventGridPublishEventTypes Eine Liste von Ereignistypen, die in Event Grid veröffentlicht werden sollen. Wenn Sie keine Typen angeben, werden alle Ereignistypen veröffentlicht. Zulässige Werte umfassen Started, , Completed, Failedund Terminated.
erweitereSitzungenAktiviert Falsch Ein Wert, der angibt, ob Sitzungsorchestrator und Entitätsfunktionssitzungen zwischengespeichert werden.
extendedSessionIdleTimeoutInSeconds 30 Die Anzahl der Sekunden, die ein sich im Leerlauf befindlicher Orchestrator oder eine Entitätsfunktion im Arbeitsspeicher verbleibt, bevor sie entladen werden. Diese Einstellung wird nur verwendet, wenn die extendedSessionsEnabled Einstellung lautet true.
useAppLease Wahr Ein Wert, der angibt, ob Apps vor der Verarbeitung von Aufgabenhubnachrichten einen Blob-Lease auf App-Ebene erwerben müssen. Weitere Informationen finden Sie unter Notfallwiederherstellung und Geoverteilung in Durable Functions. Diese Einstellung ist ab v2.3.0 verfügbar.
VerwendenSieLegacyPartitionManagement Falsch Ein Wert, der den Typ des zu verwendenden Partitionsverwaltungsalgorithmus angibt. Bei dieser Einstellung falsewird ein Algorithmus verwendet, der die Möglichkeit der Ausführung doppelter Funktionen beim Skalieren reduziert. Diese Einstellung ist ab v2.3.0 verfügbar. Das Festlegen dieses Werts auf true "Nicht empfohlen".
useTablePartitionManagement In v3.x: wahr
In v2.x: falsch
Ein Wert, der den Typ des zu verwendenden Partitionsverwaltungsalgorithmus angibt. Wenn diese Einstellung true ist, wird ein Algorithmus verwendet, mit dem die Kosten für Azure Storage v2-Konten reduziert werden. Diese Einstellung ist ab WebJobs.Extensions.DurableTask v2.10.0 verfügbar. Die Verwendung dieser Einstellung mit einer verwalteten Identität erfordert WebJobs.Extensions.DurableTask v3.x oder höher oder Worker.Extensions.DurableTask v1.2.x oder höher.
useGracefulShutdown Falsch (Vorschau) Ein Wert, der angibt, ob ein ordnungsgemäßes Herunterfahren durchgeführt werden soll, um die Wahrscheinlichkeit zu verringern, dass ein Host-Herunterfahren zum Fehlschlagen von In-Process-Funktionsausführungen führt.
maxEntityOperationBatchSize Verbrauchsplan: 50
Dedizierter oder Premium-Plan: 5.000
Die maximale Anzahl von Entitätsvorgängen, die als Batch verarbeitet werden. Wenn dieser Wert 1 ist, wird die Batchverarbeitung deaktiviert, und ein separater Funktionsaufruf verarbeitet jede Vorgangsmeldung. Diese Einstellung ist ab v2.6.1 verfügbar.
Eingaben in der Orchestrierungshistorie speichern Falsch Ein Wert, der angibt, wie Eingaben gespeichert werden. Wenn diese Einstellung lautet true, speichert das Durable Task Framework Aktivitätseingaben in der Tabelle "Verlauf", und Aktivitätsfunktionseingaben werden in Abfrageergebnissen des Orchestrierungsverlaufs angezeigt.
maxGrpcMessageSizeInBytes 4,194,304 Ein ganzzahliger Wert, der die maximale Größe in Byte von Nachrichten festlegt, die der generische Remoteprozeduraufruf (gRPC)-Client empfangen kann. Die Implementierung von DurableTaskClient verwendet den gRPC-Client zum Verwalten von Orchestrierungsinstanzen. Diese Einstellung gilt für Durable Functions .NET isolierter Worker und die Java-Apps.
grpcHttpClientTimeout 00:01:40 Das Timeout im hh:mm:ss Format für den HTTP-Client, der vom gRPC-Client in Durable Functions verwendet wird. Der Client wird derzeit für .NET isolierte Worker-Apps (.NET 6 und höher) und für Java Apps unterstützt.
QueueClientMessageEncoding UTF8 Die Codierungsstrategie für Azure Queue Storage Nachrichten. Gültige Strategien sind Unicode Transformation Format-8-Bit (UTF8) und Base64. Diese Einstellung gilt, wenn Sie Microsoft Azure WebJobs.Extensions.DurableTask 3.4.0 oder höher oder Microsoft Azure Functions.Worker.Extensions.DurableTask 1.7.0 oder höher verwenden.
defaultAsyncRequestSleepTimeMilliseconds 30.000 Das Standardabfragungsintervall in Millisekunden für asynchrone HTTP-APIs. Wenn ein Client den Status einer lang andauernden Orchestrierung mithilfe des HTTP-Statusabfrage-Endpunkts abfragt, bestimmt dieser Wert, wie lange der Client warten soll, bevor er erneut abfragt.
useForwardedHost Falsch Bei Festlegung auf "true" verwendet die Erweiterung die Header "X-Forwarded-Host" und "X-Forwarded-Proto", um URLs in HTTP-Antworten zu erstellen.

Viele dieser Einstellungen werden zur Optimierung der Leistung verwendet. Weitere Informationen finden Sie unter Leistung und Skalierung.

Nächste Schritte