Teilen über

Bindungen für dauerhafte Funktionen (Azure-Funktionen)

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-Laufzeit fungiert.

In diesem Artikel wird die Verwendung dieser vier Bindungen erläutert und Codebeispiele bereitgestellt. Darüber hinaus enthält sie Informationen zu den Konfigurationseigenschaften für dauerhafte Funktionen 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 Entwicklungssprache für dauerhafte Funktionen 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 eine höhere Version 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 OrchestrationTriggerAttribute .NET-Attribut, um den Orchestrierungstrigger zu konfigurieren.

Für Java verwenden Sie die @DurableOrchestrationTrigger Anmerkung zum Konfigurieren des Orchestrierungstriggers.

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 API für dauerhafte Funktionen direkt in Ihrem Funktionscode auf. Diese Methode registriert Ihre Orchestratorfunktion im Framework "Durable Functions".

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 definieren, indem Sie den orchestration_trigger Dekorierer direkt in Ihrem Python-Funktionscode verwenden.

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

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 asynchronen Aufgaben ausführt, außer beim Warten auf Aufgabentypen, die für Durable Functions spezifisch sind.
  • Umgang mit Giftnachrichten: Es gibt keine Unterstützung für Giftnachrichten in Orchestrierungsauslösern.
  • Sichtbarkeit von Nachrichten: Nachrichten des Orchestrierungstriggers 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 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 dauerhafte Funktionen 2.x. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen Versionen finden Sie in der Übersicht über dauerhafte Funktionen.

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 stellt ein Hello World-Beispiel bereit, das veranschaulicht, wie eine Aktivitätsfunktion aufgerufen wird:

[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 dauerhafte Funktionen 2.x. Für Durable Functions 1.x müssen Sie DurableOrchestrationContext anstelle von IDurableOrchestrationContext verwenden. Weitere Informationen zu den Unterschieden zwischen Versionen finden Sie in der Übersicht über dauerhafte Funktionen.

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 ActivityTriggerAttribute .NET-Attribut, um den Aktivitätsauslöser zu konfigurieren.

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 API für dauerhafte Funktionen 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 Dekorateur 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.
  • Metadaten: .NET-Aktivitätsfunktionen können eine Bindung an einen string instanceId Parameter 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 .NET-Bindung ActivityTriggerAttribute ist "IDurableActivityContext " (oder "DurableActivityContext " für dauerhafte Funktionen 1.x). .NET-Aktivitätstrigger unterstützen jedoch auch die direkte Bindung an JSON-serialisierbare Typen (einschließlich Grundtypen), 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 API-Methode für dauerhafte Funktionen auf, die für den Triggertyp spezifisch 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 connectionName Wert ist der Name einer App-Einstellung, die eine Verbindungszeichenfolge für Speicherkonten enthält. Das durch diese Verbindungszeichenfolge dargestellte Speicherkonto muss dasselbe sein, das die Ziel-Orchestratorfunktionen verwenden. Wenn Sie diese Eigenschaft nicht angeben, wird die Standardverbindungszeichenfolge für das Speicherkonto der Function 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 Dekorateur direkt in Ihrem Python-Funktionscode verwenden.

Kundennutzung

Sie binden in der Regel an eine Implementierung von IDurableClient (DurableOrchestrationClient in Durable Functions 1.x), wodurch 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 zeigt ein Beispiel einer von einer Warteschlange ausgelösten Funktion, die eine Hallo Welt-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 gilt für dauerhafte Funktionen 2.x. Für dauerhafte Funktionen 1.x müssen Sie das OrchestrationClient Attribut anstelle des DurableClient Attributs verwenden, und Sie müssen den DurableOrchestrationClient Parametertyp anstelle von IDurableOrchestrationClient. Weitere Informationen zu den Unterschieden zwischen Versionen finden Sie in der Übersicht über dauerhafte Funktionen.

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

Ausführliche Informationen zum Starten von Instanzen finden Sie unter Verwalten von Instanzen in dauerhaften Funktionen 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 EntityTriggerAttribute .NET-Attribut, um den Entitätstrigger zu konfigurieren.

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 API für dauerhafte Funktionen 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 Dekorateur 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 mithilfe des DurableClientAttribute .NET-Attributs in .NET-Klassenbibliotheksfunktionen herstellen.

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.

Einstellungen für dauerhafte Funktionen in host.json

Dieser Abschnitt enthält Informationen zu den Konfigurationseigenschaften für dauerhafte Funktionen in host.json. Informationen zu allgemeinen Einstellungen in host.jsonfinden 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 für alle Versionen der Azure Functions-Runtime unterstützt. Das Schema der host.json-Konfiguration unterscheidet sich jedoch geringfügig von der Version der Azure Functions-Laufzeit und der Version der verwendeten Erweiterung "Durable Functions".

Der folgende Code enthält zwei Beispiele für durableTask Einstellungen in host.json: eine für dauerhafte Funktionen 2.x und eine für dauerhafte Funktionen 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 der host.json befindet sich im Stamm der host.json-Konfiguration , anstatt ein Feld unter extensions.

{
 "extensions": {
  "durableTask": {
    "hubName": "MyTaskHub",
    "defaultVersion": "1.0",
    "versionMatchStrategy": "CurrentOrOlder",
    "versionFailureStrategy": "Reject",
    "storageProvider": {
      "connectionStringName": "AzureWebJobsStorage",
      "controlQueueBatchSize": 32,
      "controlQueueBufferThreshold": 256,
      "controlQueueVisibilityTimeout": "00:05:00",
      "FetchLargeMessagesAutomatically": true,
      "maxQueuePollingInterval": "00:00:30",
      "partitionCount": 4,
      "trackingStoreConnectionStringName": "TrackingStorage",
      "trackingStoreNamePrefix": "DurableTask",
      "useLegacyPartitionManagement": false,
      "useTablePartitionManagement": true,
      "workItemQueueVisibilityTimeout": "00:05:00",
      "QueueClientMessageEncoding": "UTF8"
    },
    "tracing": {
      "traceInputsAndOutputs": false,
      "traceReplayEvents": false,
    },
    "notifications": {
      "eventGrid": {
        "topicEndpoint": "https://topic_name.westus2-1.eventgrid.azure.net/api/events",
        "keySettingName": "EventGridKey",
        "publishRetryCount": 3,
        "publishRetryInterval": "00:00:30",
        "publishEventTypes": [
          "Started",
          "Completed",
          "Failed",
          "Terminated"
        ]
      }
    },
    "maxConcurrentActivityFunctions": 10,
    "maxConcurrentOrchestratorFunctions": 10,
    "maxConcurrentEntityFunctions": 10,
    "extendedSessionsEnabled": false,
    "extendedSessionIdleTimeoutInSeconds": 30,
    "useAppLease": true,
    "useGracefulShutdown": false,
    "maxEntityOperationBatchSize": 50,
    "maxOrchestrationActions": 100000,
    "storeInputsInOrchestrationHistory": false
  }
 }
}
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 Anwendungen für dauerhafte Funktionen 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 vom Feature Orchestrierungsversionsverwaltung verwendet, um Szenarien wie Bereitstellungen ohne Downtime mit Breaking Changes 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 Verbrauchstarif 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 Sichtbarkeitstimeout von aus der Steuerelementwarteschlange entfernten Nachrichten im Format hh:mm:ss.
workItemQueueVisibilityTimeout 00:05:00 Das Sichtbarkeitstimeout von aus der Warteschlange für Arbeitsausgaben entfernten Nachrichten im Format hh:mm:ss.
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 Abrufintervall der Steuerelement- und Arbeitselement-Warteschlangen im Format hh:mm:ss. 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-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit den zugrunde liegenden Azure Storage-Ressourcen hergestellt werden soll. Wenn Sie eine einzelne App-Einstellung angeben, sollte es sich um eine Azure Storage-Verbindungszeichenfolge 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 angeben, sollte es sich um eine Azure Storage-Verbindungszeichenfolge handeln. Wenn Sie keine Einstellung angeben, wird die Verbindung mit dem Wert connectionStringName (v2.x) oder azureStorageConnectionStringName (v1.x) 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 benutzerdefinierten Azure Event Grid-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 Wiederholungsintervall der Event Grid-Veröffentlichung 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: false		 Ein Wert, der den Typ des zu verwendenden Partitionsverwaltungsalgorithmus angibt. Bei dieser Einstellung truewird ein Algorithmus verwendet, der dazu dient, die Kosten für Azure Storage v2-Konten zu reduzieren. 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 Isolated Worker und Java-Apps.
grpcHttpClientTimeout 00:01:40 Das Timeout im Format hh:mm:ss für den HTTP-Client, das vom gRPC-Client in Durable Functions verwendet wird. Der Client wird derzeit für .NET isolierte Worker-Apps (.NET 6 und höhere Versionen) 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.

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

Nächste Schritte

Integrierte HTTP-API-Referenz für die Instanzverwaltung

  • Last updated on