Freigeben über

Azure Tables-Ausgabebindungen für Azure Functions

  • Artikel

Verwenden Sie eine Azure Tables-Ausgabebindung, um Entitäten in eine Tabelle in Azure Cosmos DB for Table oder Azure Table Storage zu schreiben.

Informationen zu Setup- und Konfigurationsdetails finden Sie in der Übersicht.

Hinweis

Diese Ausgabebindung unterstützt nur das Erstellen neuer Entitäten in einer Tabelle. Wenn Sie eine vorhandene Entität aus Ihrem Funktionscode aktualisieren müssen, verwenden Sie stattdessen direkt ein Azure Tables SDK.

Wichtig

In diesem Artikel werden Registerkarten verwendet, um mehrere Versionen des Node.js-Programmiermodells zu unterstützen. Das v4-Modell ist allgemein verfügbar und bietet JavaScript- und TypeScript-Entwicklern eine flexiblere und intuitivere Erfahrung. Weitere Informationen zur Funktionsweise des v4-Modells finden Sie im Azure Functions Node.js-Entwicklerhandbuch. Weitere Informationen zu den Unterschieden zwischen v3 und v4 finden Sie im Migrationshandbuch.

Beispiel

Eine C#-Funktion kann mit einem der folgenden C#-Modi erstellt werden:

  • Isoliertes Workermodell: Kompilierte C#-Funktion, die in einem Workerprozess ausgeführt wird, der von der Runtime isoliert ist. Ein isolierter Workerprozess ist erforderlich, um C#-Funktionen zu unterstützen, die in LTS- und Nicht-LTS-Versionen von .NET und .NET Framework ausgeführt werden. Erweiterungen für isolierte Workerprozessfunktionen verwenden Microsoft.Azure.Functions.Worker.Extensions.*-Namespaces.
  • In-Process-Modell: Kompilierte C#-Funktion, die im gleichen Prozess wie die Functions-Runtime ausgeführt wird. In einer Variante dieses Modells kann Functions mithilfe von C#-Skripts ausgeführt werden. Dies wird hauptsächlich für die Bearbeitung im C#-Portal unterstützt. Erweiterungen für In-Process-Funktionen verwenden Microsoft.Azure.WebJobs.Extensions.*-Namespaces.

Wichtig

Die Unterstützung für das In-Process-Modell endet am 10. November 2026. Es wird dringend empfohlen, Ihre Apps zum isolierten Workermodell zu migrieren, um den vollständigen Support zu ermöglichen.

Die folgende MyTableData-Klasse stellt eine Datenzeile in der Tabelle dar:

public class MyTableData : Azure.Data.Tables.ITableEntity
{
    public string Text { get; set; }

    public string PartitionKey { get; set; }
    public string RowKey { get; set; }
    public DateTimeOffset? Timestamp { get; set; }
    public ETag ETag { get; set; }
}

Die folgende Funktion, die von einem Queue Storage-Trigger gestartet wird, schreibt eine neue MyDataTable-Entität in eine Tabelle mit dem Namen OutputTable.

[Function("TableFunction")]
[TableOutput("OutputTable", Connection = "AzureWebJobsStorage")]
public static MyTableData Run(
    [QueueTrigger("table-items")] string input,
    [TableInput("MyTable", "<PartitionKey>", "{queueTrigger}")] MyTableData tableInput,
    FunctionContext context)
{
    var logger = context.GetLogger("TableFunction");

    logger.LogInformation($"PK={tableInput.PartitionKey}, RK={tableInput.RowKey}, Text={tableInput.Text}");

    return new MyTableData()
    {
        PartitionKey = "queue",
        RowKey = Guid.NewGuid().ToString(),
        Text = $"Output record with rowkey {input} created at {DateTime.Now}"
    };
}

Das folgende Beispiel zeigt eine Java-Funktion, die einen HTTP-Trigger zum Schreiben einer einzelnen Tabellenzeile verwendet.

public class Person {
    private String PartitionKey;
    private String RowKey;
    private String Name;

    public String getPartitionKey() {return this.PartitionKey;}
    public void setPartitionKey(String key) {this.PartitionKey = key; }
    public String getRowKey() {return this.RowKey;}
    public void setRowKey(String key) {this.RowKey = key; }
    public String getName() {return this.Name;}
    public void setName(String name) {this.Name = name; }
}

public class AddPerson {

    @FunctionName("addPerson")
    public HttpResponseMessage get(
            @HttpTrigger(name = "postPerson", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.FUNCTION, route="persons/{partitionKey}/{rowKey}") HttpRequestMessage<Optional<Person>> request,
            @BindingName("partitionKey") String partitionKey,
            @BindingName("rowKey") String rowKey,
            @TableOutput(name="person", partitionKey="{partitionKey}", rowKey = "{rowKey}", tableName="%MyTableName%", connection="MyConnectionString") OutputBinding<Person> person,
            final ExecutionContext context) {

        Person outPerson = new Person();
        outPerson.setPartitionKey(partitionKey);
        outPerson.setRowKey(rowKey);
        outPerson.setName(request.getBody().get().getName());

        person.setValue(outPerson);

        return request.createResponseBuilder(HttpStatus.OK)
                        .header("Content-Type", "application/json")
                        .body(outPerson)
                        .build();
    }
}

Das folgende Beispiel zeigt eine Java-Funktion, die einen HTTP-Trigger zum Schreiben mehrerer Tabellenzeilen verwendet.

public class Person {
    private String PartitionKey;
    private String RowKey;
    private String Name;

    public String getPartitionKey() {return this.PartitionKey;}
    public void setPartitionKey(String key) {this.PartitionKey = key; }
    public String getRowKey() {return this.RowKey;}
    public void setRowKey(String key) {this.RowKey = key; }
    public String getName() {return this.Name;}
    public void setName(String name) {this.Name = name; }
}

public class AddPersons {

    @FunctionName("addPersons")
    public HttpResponseMessage get(
            @HttpTrigger(name = "postPersons", methods = {HttpMethod.POST}, authLevel = AuthorizationLevel.FUNCTION, route="persons/") HttpRequestMessage<Optional<Person[]>> request,
            @TableOutput(name="person", tableName="%MyTableName%", connection="MyConnectionString") OutputBinding<Person[]> persons,
            final ExecutionContext context) {

        persons.setValue(request.getBody().get());

        return request.createResponseBuilder(HttpStatus.OK)
                        .header("Content-Type", "application/json")
                        .body(request.getBody().get())
                        .build();
    }
}

Das folgende Beispiel zeigt eine Tabellenausgabebindung, die mehrere Tabellenentitäten schreibt.

import { app, HttpRequest, HttpResponseInit, InvocationContext, output } from '@azure/functions';

const tableOutput = output.table({
    tableName: 'Person',
    connection: 'MyStorageConnectionAppSetting',
});

interface PersonEntity {
    PartitionKey: string;
    RowKey: string;
    Name: string;
}

export async function httpTrigger1(request: HttpRequest, context: InvocationContext): Promise<HttpResponseInit> {
    const rows: PersonEntity[] = [];
    for (let i = 1; i < 10; i++) {
        rows.push({
            PartitionKey: 'Test',
            RowKey: i.toString(),
            Name: `Name ${i}`,
        });
    }
    context.extraOutputs.set(tableOutput, rows);
    return { status: 201 };
}

app.http('httpTrigger1', {
    methods: ['POST'],
    authLevel: 'anonymous',
    extraOutputs: [tableOutput],
    handler: httpTrigger1,
});

const { app, output } = require('@azure/functions');

const tableOutput = output.table({
    tableName: 'Person',
    connection: 'MyStorageConnectionAppSetting',
});

app.http('httpTrigger1', {
    methods: ['POST'],
    authLevel: 'anonymous',
    extraOutputs: [tableOutput],
    handler: async (request, context) => {
        const rows = [];
        for (let i = 1; i < 10; i++) {
            rows.push({
                PartitionKey: 'Test',
                RowKey: i.toString(),
                Name: `Name ${i}`,
            });
        }
        context.extraOutputs.set(tableOutput, rows);
        return { status: 201 };
    },
});

Das folgende Beispiel veranschaulicht, wie mehrere Entitäten aus einer Funktion in eine Tabelle geschrieben werden.

Bindungskonfiguration in function.json:

{
  "bindings": [
    {
      "name": "InputData",
      "type": "manualTrigger",
      "direction": "in"
    },
    {
      "tableName": "Person",
      "connection": "MyStorageConnectionAppSetting",
      "name": "TableBinding",
      "type": "table",
      "direction": "out"
    }
  ],
  "disabled": false
}

PowerShell-Code in run.ps1:

param($InputData, $TriggerMetadata)

foreach ($i in 1..10) {
    Push-OutputBinding -Name TableBinding -Value @{
        PartitionKey = 'Test'
        RowKey = "$i"
        Name = "Name $i"
    }
}

Das folgende Beispiel zeigt, wie Sie die Tabellenspeicherausgabe-Bindung verwenden. Konfigurieren Sie die table-Bindung in der Datei function.json, indem Sie name, tableName, partitionKey und connection Werte zuweisen:

{
  "scriptFile": "__init__.py",
  "bindings": [
    {
      "name": "message",
      "type": "table",
      "tableName": "messages",
      "partitionKey": "message",
      "connection": "AzureWebJobsStorage",
      "direction": "out"
    },
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

Die folgende Funktion generiert eine eindeutige UUI für den rowKey-Wert und speichert die Nachricht dauerhaft im Tabellenspeicher.

import logging
import uuid
import json

import azure.functions as func

def main(req: func.HttpRequest, message: func.Out[str]) -> func.HttpResponse:

    rowKey = str(uuid.uuid4())

    data = {
        "Name": "Output binding message",
        "PartitionKey": "message",
        "RowKey": rowKey
    }

    message.set(json.dumps(data))

    return func.HttpResponse(f"Message created with the rowKey: {rowKey}")

Attribute

Sowohl C#-Bibliotheken des Typs In-Process als auch des Typs Isolierter Workerprozess verwenden Attribute zum Definieren der Funktion. Das C#-Skript verwendet stattdessen eine Konfigurationsdatei function.json, wie im C#-Skript-Handbuch beschrieben.

In C#-Klassenbibliotheken unterstützt TableInputAttribute die folgenden Eigenschaften:

Attributeigenschaft BESCHREIBUNG
TableName Der Name der Tabelle, in die geschrieben werden soll.
PartitionKey Der Partitionsschlüssel der zu schreibenden Tabellenentität.
Zeilenschlüssel Der Zeilenschlüssel der zu schreibenden Tabellenentität.
Connection Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit dem Tabellendienst hergestellt wird. Siehe Verbindungen.

Anmerkungen

Verwenden Sie in der Java-Funktionslaufzeitbibliothek die TableOutput-Anmerkung für Parameter, um Werte in Ihre Tabellen zu schreiben. Das Attribut unterstützt die folgenden Elemente:

Element BESCHREIBUNG
name Der Variablenname, der in Funktionscode zur Darstellung der Tabelle oder Entität verwendet wird.
dataType Definiert, wie die Functions-Runtime den Parameterwert behandeln soll. Weitere Informationen finden Sie unter dataType.
tableName Der Name der Tabelle, in die geschrieben werden soll.
partitionKey Der Partitionsschlüssel der zu schreibenden Tabellenentität.
rowKey Der Zeilenschlüssel der zu schreibenden Tabellenentität.
connection Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit dem Tabellendienst hergestellt wird. Siehe Verbindungen.

Konfiguration

In der folgenden Tabelle werden die Eigenschaften erläutert, die Sie für das options-Objekt festlegen können, das an die output.table()-Methode übergeben wurde.

Eigenschaft Beschreibung
tableName Der Name der Tabelle, in die geschrieben werden soll.
partitionKey Der Partitionsschlüssel der zu schreibenden Tabellenentität.
rowKey Der Zeilenschlüssel der zu schreibenden Tabellenentität.
connection Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit dem Tabellendienst hergestellt wird. Siehe Verbindungen.

Konfiguration

Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.

function.json-Eigenschaft BESCHREIBUNG
type Muss auf table festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen.
direction Muss auf out festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen.
name Der Variablenname, der in Funktionscode zur Darstellung der Tabelle oder Entität verwendet wird. Legen Sie diesen Wert auf $return fest, um auf den Rückgabewert der Funktion zu verweisen.
tableName Der Name der Tabelle, in die geschrieben werden soll.
partitionKey Der Partitionsschlüssel der zu schreibenden Tabellenentität.
rowKey Der Zeilenschlüssel der zu schreibenden Tabellenentität.
connection Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit dem Tabellendienst hergestellt wird. Siehe Verbindungen.

Wenn Sie die Entwicklung lokal ausführen, fügen Sie Ihre Anwendungseinstellungen in der Datei local.settings.json in der Values-Sammlung hinzu.

Verbindungen

Die connection-Eigenschaft ist ein Verweis auf eine Umgebungskonfiguration, die angibt, wie sich die App mit Ihrem Tabellendienst verbinden soll. Folgendes kann angegeben werden:

Wenn der konfigurierte Wert sowohl eine genaue Übereinstimmung für eine einzelne Einstellung als auch eine Präfix-Übereinstimmung für andere Einstellungen ist, wird die genaue Übereinstimmung verwendet.

Verbindungszeichenfolge

Um eine Verbindungszeichenfolge für Tabellen im Azure Table-Speicher abzurufen, folgen Sie den Schritten unter Verwaltung der Zugriffsschlüssel für Speicherkonten. Um eine Verbindungszeichenfolge für Tabellen in Azure Cosmos DB for Table abzurufen, führen Sie die Schritte aus, die im FAQ zu Azure Cosmos DB for Table gezeigt werden.

Diese Verbindungszeichenfolge sollte in einer Anwendungseinstellung mit einem Namen gespeichert werden, der dem in der Eigenschaft connection der Bindungskonfiguration angegebenen Wert entspricht.

Falls der Name der App-Einstellung mit „AzureWebJobs“ beginnt, können Sie hier nur den Rest des Namens angeben. Wenn Sie connection also beispielsweise auf „MyStorage“ festlegen, sucht die Functions-Laufzeit nach einer App-Einstellung namens „AzureWebJobsMyStorage“. Ohne Angabe für connection verwendet die Functions-Laufzeit die standardmäßige Storage-Verbindungszeichenfolge aus der App-Einstellung AzureWebJobsStorage.

Identitätsbasierte Verbindungen

Wenn Sie die Tabellen-API-Erweiterung verwenden, können Sie die App statt einer Verbindungszeichenfolge mit einem Geheimnis eine Microsoft Entra-Identität verwenden lassen. Dies gilt nur für den Zugriff auf Tabellen in Azure Storage. Um eine Identität zu verwenden, definieren Sie Einstellungen unter einem gemeinsamen Präfix, das der Eigenschaft connection in der Trigger- und Bindungskonfiguration zugeordnet ist.

Wenn Sie connection auf „AzureWebJobsStorage“ festlegen, finden Sie weitere Informationen unter Herstellen einer Verbindung zum Hostspeicher mit einer Identität. Für alle anderen Verbindungen erfordert die Erweiterung die folgenden Eigenschaften:

Eigenschaft Vorlage für Umgebungsvariable BESCHREIBUNG Beispielwert
Tabellendienst-URI <CONNECTION_NAME_PREFIX>__tableServiceUri1 Dies ist der Datenebenen-URI des Azure Storage-Tabellendiensts, mit dem Sie mithilfe des HTTPS-Schemas eine Verbindung herstellen. https://<speicherkonto_name>.table.core.windows.net

1 <CONNECTION_NAME_PREFIX>__serviceUri kann als Alias verwendet werden. Wenn beide Formate bereitgestellt werden, wird das Format tableServiceUri verwendet. Das Format serviceUri kann nicht verwendet werden, wenn die gesamte Verbindungskonfiguration über Blobs, Warteschlangen und/oder Tabellen hinweg verwendet werden soll.

Andere Eigenschaften können festgelegt werden, um die Verbindung anzupassen. Weitere Informationen finden Sie unter Allgemeine Eigenschaften für identitätsbasierte Verbindungen.

Das Format serviceUri kann nicht verwendet werden, wenn die gesamte Verbindungskonfiguration über Blobs, Warteschlangen und/oder Tabellen in Azure Storage hinweg verwendet werden soll. Der URI kann nur den Tabellendienst bezeichnen. Alternativ können Sie einen URI speziell für jeden Dienst unter dem gleichen Präfix bereitstellen, sodass eine einzelne Verbindung verwendet werden kann.

Identitätsbasierte Verbindungen verwenden eine verwaltete Identität, wenn sie im Azure Functions-Dienst gehostet werden. Standardmäßig wird eine vom System zugewiesene Identität verwendet, auch wenn mit den Eigenschaften credential und clientID eine vom Benutzer zugewiesene Identität angegeben werden kann. Beachten Sie, dass das Konfigurieren einer benutzerseitig zugewiesenen Identität mit einer Ressourcen-ID nicht unterstützt wird. Bei Ausführung in anderen Kontexten (z. B. bei der lokalen Entwicklung) wird stattdessen Ihre Entwickleridentität verwendet, Dieses Verhalten kann angepasst werden. Weitere Informationen finden Sie unter Lokale Entwicklung mit identitätsbasierten Verbindungen.

Erteilen der Berechtigung für die Identität

Unabhängig davon, welche Identität verwendet wird, muss diese über Berechtigungen zum Ausführen der vorgesehenen Aktionen verfügen. Daher müssen Sie für die meisten Azure-Dienste eine Rolle in Azure RBAC zuweisen, indem Sie entweder integrierte oder benutzerdefinierte Rollen verwenden, die diese Berechtigungen bieten.

Wichtig

Vom Zieldienst werden möglicherweise einige nicht für alle Kontexte erforderliche Berechtigungen verfügbar gemacht. Befolgen Sie nach Möglichkeit das Prinzip der geringsten Berechtigung, und gewähren Sie der Identität nur die erforderlichen Berechtigungen. Wenn die App beispielsweise nur Daten aus einer Datenquelle lesen muss, verwenden Sie eine Rolle, die nur über Leseberechtigungen verfügt. Es wäre nicht angemessen, eine Rolle zu zuweisen, die auch das Schreiben in diesen Dienst zulässt, da dies eine übermäßige Berechtigung für einen Lesevorgang wäre. Ebenso sollten Sie sicherstellen, dass die Rollenzuweisung auf die Ressourcen begrenzt ist, die gelesen werden müssen.

Sie müssen eine Rollenzuweisung erstellen, die zur Laufzeit Zugriff auf Ihren Azure Storage-Tabellendienst bereitstellt. Verwaltungsrollen wie Besitzer sind nicht ausreichend. Die folgende Tabelle zeigt integrierte Rollen, die für den normalen Betrieb mit der Azure Tables-Erweiterung für Azure Storage empfohlen werden. Ihre Anwendung erfordert möglicherweise zusätzliche Berechtigungen basierend auf dem von Ihnen geschriebenen Code.

Bindungstyp Beispiel für integrierte Rollen (Azure Storage1)
Eingabebindung Storage-Tabellendatenleser
Ausgabebindung Mitwirkender an Storage-Tabellendaten

1 Wenn Ihre App stattdessen eine Verbindung mit Tabellen in Azure Cosmos DB for Table herstellt, wird die Verwendung einer Identität nicht unterstützt, und die Verbindung muss eine Verbindungszeichenfolge verwenden.

Verbrauch

Die Verwendung der Bindung hängt von der Version des Erweiterungspakets und der C#-Modalität ab, die in Ihrer Funktions-App verwendet wird. Dies kann eine der folgenden Modalitäten sein:

Eine Klassenbibliothek in einem isolierten Workerprozess ist eine kompilierte C#-Funktion, die in einem von der Runtime isolierten Prozess ausgeführt wird.

Wählen Sie eine Version aus, um Syntaxdetails für den Modus und die Version anzuzeigen.

Wenn die Funktion in eine einzelne Entität schreiben soll, kann die Blobausgabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
Einen serialisierbaren JSON-Typ, der [ITableEntity] implementiert. Functions versucht, einen POCO-Typ (Plain-Old CLR Object) als die Entität zu serialisieren. Der Typ muss [ITableEntity] implementieren oder über eine Zeichenfolgeneigenschaft RowKey und eine Zeichenfolgeneigenschaft PartitionKey verfügen.

Wenn die Funktion in mehrere Entitäten schreiben soll, kann die Blobausgabebindung an die folgenden Typen gebunden werden:

type BESCHREIBUNG
T[], wobei T einer der einzelnen Entitätstypen ist. Ein Array, das mehrere Entitäten enthält. Jeder Eintrag stellt eine Entität dar.

Für andere Ausgabeszenarien erstellen und verwenden Sie Typen direkt aus Azure.Data.Tables.

Es gibt zwei Optionen für das Ausgeben einer Tabellenspeicherzeile aus einer Funktion mittels der TableStorageOutput-Anmerkung:

Optionen BESCHREIBUNG
Rückgabewert Wenn Sie die Anmerkung auf die Funktion selbst anwenden, wird der Rückgabewert der Funktion als Tabellenspeicherzeile persistent gespeichert.
Imperativ Um die Tabellenzeile explizit festzulegen, wenden Sie die Anmerkung auf einen bestimmten Parameter des Typs OutputBinding<T> an, wobei T die Eigenschaften PartitionKey und RowKey enthält. Sie können diese Eigenschaften begleiten, indem Sie ITableEntity implementieren oder von TableEntity erben.

Legen Sie die Ausgabezeilendaten fest, indem Sie den Wert zurückgeben oder context.extraOutputs.set() verwenden.

Um in Tabellendaten zu schreiben, verwenden Sie das Cmdlet Push-OutputBinding, und legen Sie die Parameter -Name TableBinding und -Value entsprechend den Zeilendaten fest. Weitere Details finden Sie im PowerShell-Beispiel.

Es gibt zwei Optionen für das Ausgeben einer Tabellenspeicherzeilen-Nachricht aus einer Funktion:

Optionen BESCHREIBUNG
Rückgabewert Legen Sie die Eigenschaft name in function.json auf $return fest. Mit dieser Konfiguration wird der Rückgabewert der Funktion als Tabellenspeicherzeile persistent gespeichert.
Imperativ Übergeben Sie einen Wert an die set-Methode des Parameters, der als Out-Typ deklariert ist. Der an set übergebene Wert wird als Tabellenzeile persistent gespeichert.

Spezifische Syntaxdetails finden Sie unter Beispiel.

Ausnahmen und Rückgabecodes

Bindung Verweis
Tabelle Tabellenfehlercodes
Blob, Tabelle, Warteschlange Speicherfehlercodes
Blob, Tabelle, Warteschlange Problembehandlung

Nächste Schritte

Konzepte für Azure Functions-Trigger und -Bindungen