C#-Skriptentwicklerreferenz (C#-Skript, CSX) zu Azure Functions
Dieser Artikel ist eine Einführung in die Entwicklung von Azure Functions mithilfe von C#-Skript (CSX).
Wichtig
Das C#-Skript wird in erster Linie unterstützt, damit Sie in einer bequemen portalinternen Umgebung schnell mit dem Erstellen und Ausführen von C#-Funktionen beginnen können. Für Apps mit Produktionsqualität sollten Sie stattdessen Ihre C#-Funktionen lokal als kompiliertes C#-Klassenbibliotheksprojekt entwickeln. Informationen zum Migrieren eines C#-Skriptprojekts zu einem C#-Klassenbibliotheksprojekt (isolierter Worker) finden Sie unter Konvertieren einer C#-Skript-App in ein C#-Projekt.
Mit Azure Functions können Sie Funktionen mithilfe von C# auf eine der folgenden Arten entwickeln:
| type | Ausführungsprozess | Codeerweiterung | Entwicklungsumgebung | Referenz |
|---|---|---|---|---|
| C#-Skript | Prozessintern | CSX-Datei | Portal Kerntools |
Dieser Artikel |
| C#-Klassenbibliothek (isolierter Worker) | Isolierter Workerprozess | .cs | Visual Studio Visual Studio Code Kerntools |
.NET-Funktionen in isolierten Workerprozessen |
| C#-Klassenbibliothek (In-Process) | In-Process | .cs | Visual Studio Visual Studio Code Kerntools |
In-Process-Klassenbibliotheksfunktionen für C# |
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.
Funktionsweise von CSX
Daten fließen über Methodenargumente in Ihre C#-Funktion ein. Argumentnamen werden in einer function.json-Datei angegeben, und es gibt vordefinierte Namen für den Zugriff auf Elemente wie die Funktionsprotokollierung und Abbruchtoken.
Dank des CSX-Formats müssen Sie weniger Textbausteine schreiben und können sich ganz auf das Schreiben einer C#-Funktion konzentrieren. Anstatt sämtliche Informationen in einem Namespace und einer Klasse zu umschließen, definieren Sie einfach eine Run-Methode. Schließen Sie wie gewohnt alle Assemblyverweise und Namespaces am Anfang der Datei ein.
Die CSX-Dateien einer Funktions-App werden kompiliert, wenn eine Instanz initialisiert wird. Dieser Kompilierungsschritt bedeutet, dass bestimmte Dinge, etwa ein Kaltstart, für C#-Skriptfunktionen im Vergleich zu C#-Klassenbibliotheken länger dauern. Dieser Kompilierungsschritt ist auch der Grund, warum C#-Skriptfunktionen im Azure-Portal bearbeitet werden können, während dies für C#-Klassenbibliotheken nicht möglich ist.
Ordnerstruktur
Die Ordnerstruktur für ein C#-Skriptprojekt sieht wie das folgende Beispiel aus:
FunctionsProject
| - MyFirstFunction
| | - run.csx
| | - function.json
| | - function.proj
| - MySecondFunction
| | - run.csx
| | - function.json
| | - function.proj
| - host.json
| - extensions.csproj
| - bin
Sie können die freigegebene Datei host.json zum Konfigurieren der Funktions-App verwenden. Jede Funktion verfügt über eine eigene Codedatei (CSX-Datei) sowie über eine eigene Bindungskonfigurationsdatei (function.json).
Die in Version 2.x oder höher der Functions-Runtime erforderlichen Bindungserweiterungen sind in der Datei extensions.csproj definiert, die eigentlichen Bibliotheksdateien befinden sich im Ordner bin. Wenn Sie lokal entwickeln, müssen Sie Bindungserweiterungen registrieren. Wenn Sie Funktionen im Azure-Portal entwickeln, wird diese Registrierung für Sie ausgeführt.
Binden an Argumente
Eingabe- oder Ausgabedaten werden über die name-Eigenschaft in der function.json-Konfigurationsdatei an dienen C#-Skriptfunktionsparameter gebunden. Im folgenden Beispiel werden eine function.json- und eine run.csx-Datei für eine über die Warteschlange ausgelöste Funktion gezeigt. Der Parameter, der die Daten aus der Warteschlangennachricht empfängt, hat den Namen myQueueItem, weil dies der Wert der name-Eigenschaft ist.
{
"disabled": false,
"bindings": [
{
"type": "queueTrigger",
"direction": "in",
"name": "myQueueItem",
"queueName": "myqueue-items",
"connection":"MyStorageConnectionAppSetting"
}
]
}
#r "Microsoft.WindowsAzure.Storage"
using Microsoft.Extensions.Logging;
using Microsoft.WindowsAzure.Storage.Queue;
using System;
public static void Run(CloudQueueMessage myQueueItem, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem.AsString}");
}
Die #r-Anweisung ist weiter unten in diesem Artikel erläutert.
Unterstützte Typen für Bindungen
Jede Bindung hat ihre eigenen unterstützten Typen. Beispielsweise kann ein Blobtrigger mit einem Zeichenfolgeparameter, einem POCO-Parameter, einem CloudBlockBlob-Parameter oder einem von mehreren anderen unterstützten Typen verwendet werden. Im Bindungsreferenzartikel für Blobbindungen sind alle unterstützten Parametertypen für Blobtrigger aufgelistet. Weitere Informationen hierzu finden Sie unter Trigger und Bindungen und in den Bindungsreferenzdokumenten für jeden Bindungstyp.
Tipp
Wenn Sie die HTTP- oder WebHook-Bindungen verwenden möchten, vermeiden Sie die Portauslastung, die durch nicht ordnungsgemäße Instanziierung von HttpClient verursacht werden kann. Weitere Informationen finden Sie unter How to manage connections in Azure Functions (Verwalten von Verbindungen in Azure Functions).
Verweisen auf benutzerdefinierte Klassen
Wenn Sie eine benutzerdefinierte POCO-Klasse (Plain Old CLR Object) verwenden müssen, können Sie die Klassendefinition in dieselbe Datei einfügen oder in eine separate Datei setzen.
Im folgenden Beispiel wird ein run.csx-Beispiel veranschaulicht, das eine POCO-Klassendefinition enthält.
public static void Run(string myBlob, out MyClass myQueueItem)
{
log.Verbose($"C# Blob trigger function processed: {myBlob}");
myQueueItem = new MyClass() { Id = "myid" };
}
public class MyClass
{
public string Id { get; set; }
}
Bei einer POCO-Klasse müssen für jede Eigenschaft ein Getter und ein Setter definiert sein.
Wiederverwenden von CSX-Code
Sie können in der Datei run.csx Klassen und Methoden verwenden, die in anderen CSX -Dateien definiert sind. Verwenden Sie zu diesem Zweck #load-Anweisungen in der Datei run.csx. Im folgenden Beispiel wird die Protokollierungsroutine MyLogger in myLogger.csx freigegeben und mit der #load-Anweisung in run.csx geladen:
Beispiel für run.csx:
#load "mylogger.csx"
using Microsoft.Extensions.Logging;
public static void Run(TimerInfo myTimer, ILogger log)
{
log.LogInformation($"Log by run.csx: {DateTime.Now}");
MyLogger(log, $"Log by MyLogger: {DateTime.Now}");
}
Beispiel für mylogger.csx:
public static void MyLogger(ILogger log, string logtext)
{
log.LogInformation(logtext);
}
Die Verwendung einer freigegebenen CSX-Datei ist ein häufiges Verfahren, wenn die Daten, die über ein POCO-Objekt zwischen Funktionen übertragen werden, stark typisiert werden sollen. Im folgenden vereinfachten Beispiel verwenden ein HTTP-Trigger und ein Warteschlangentrigger gemeinsam das POCO-Objekt Order, um die Bestelldaten stark zu typisieren:
Beispiel: run.csx für HTTP-Trigger:
#load "..\shared\order.csx"
using System.Net;
using Microsoft.Extensions.Logging;
public static async Task<HttpResponseMessage> Run(Order req, IAsyncCollector<Order> outputQueueItem, ILogger log)
{
log.LogInformation("C# HTTP trigger function received an order.");
log.LogInformation(req.ToString());
log.LogInformation("Submitting to processing queue.");
if (req.orderId == null)
{
return new HttpResponseMessage(HttpStatusCode.BadRequest);
}
else
{
await outputQueueItem.AddAsync(req);
return new HttpResponseMessage(HttpStatusCode.OK);
}
}
Beispiel: run.csx für Warteschlangentrigger:
#load "..\shared\order.csx"
using System;
using Microsoft.Extensions.Logging;
public static void Run(Order myQueueItem, out Order outputQueueItem, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed order...");
log.LogInformation(myQueueItem.ToString());
outputQueueItem = myQueueItem;
}
Beispiel: order.csx:
public class Order
{
public string orderId {get; set; }
public string custName {get; set;}
public string custAddress {get; set;}
public string custEmail {get; set;}
public string cartId {get; set; }
public override String ToString()
{
return "\n{\n\torderId : " + orderId +
"\n\tcustName : " + custName +
"\n\tcustAddress : " + custAddress +
"\n\tcustEmail : " + custEmail +
"\n\tcartId : " + cartId + "\n}";
}
}
Mit der #load -Direktive können Sie einen relativen Pfad verwenden:
#load "mylogger.csx": Lädt eine Datei, die sich im Funktionsordner befindet.#load "loadedfiles\mylogger.csx": Lädt eine Datei, die sich in einem Ordner im Funktionsordner befindet.#load "..\shared\mylogger.csx": Lädt eine Datei, die sich in einem Ordner auf der gleichen Ebene befindet wie der Funktionsordner (also direkt unter wwwroot).
Die #load-Direktive kann nur mit CSX-Dateien verwendet werden, nicht mit CS-Dateien.
Binden an den Rückgabewert einer Methode
Sie können für eine Ausgabebindung den Rückgabewert einer Methode verwenden, indem Sie den Namen $return in der Datei function.json verwenden.
{
"name": "$return",
"type": "blob",
"direction": "out",
"path": "output-container/{id}"
}
Hier sehen Sie den C#-Skriptcode, der den Rückgabewert verwendet, gefolgt von einem asynchronen Beispiel:
public static string Run(WorkItem input, ILogger log)
{
string json = string.Format("{{ \"id\": \"{0}\" }}", input.Id);
log.LogInformation($"C# script processed queue message. Item={json}");
return json;
}
public static Task<string> Run(WorkItem input, ILogger log)
{
string json = string.Format("{{ \"id\": \"{0}\" }}", input.Id);
log.LogInformation($"C# script processed queue message. Item={json}");
return Task.FromResult(json);
}
Verwenden Sie den Rückgabewert nur dann, wenn eine erfolgreiche Ausführung der Funktion immer einen Rückgabewert ergibt, der an die Ausgabebindung übergeben werden soll. Verwenden Sie andernfalls, wie im folgenden Abschnitt gezeigt, ICollector oder IAsyncCollector.
Schreiben von mehreren Ausgabewerten
Verwenden Sie die Typen ICollector oder IAsyncCollector in folgenden Fällen: 1. um mehrere Werte in eine Ausgabebindung zu schreiben oder 2. wenn ein erfolgreicher Funktionsaufruf möglicherweise keinen übergebbaren Wert für die Ausgabebindung ergibt. Diese Typen stellen lesegeschützte Sammlungen dar, die nach Durchführung der Methode in die Ausgabebindung geschrieben werden.
In diesem Beispiel werden mehrere Warteschlangennachrichten mit ICollector in die gleiche Warteschlange geschrieben:
public static void Run(ICollector<string> myQueue, ILogger log)
{
myQueue.Add("Hello");
myQueue.Add("World!");
}
Protokollierung
Um eine Ausgabe in C# in Ihren Streamingprotokollen zu dokumentieren, fügen Sie ein Argument vom Typ ILogger ein. Verwenden Sie hierzu am besten den Namen log. Vermeiden Sie die Verwendung von Console.Write in Azure Functions.
public static void Run(string myBlob, ILogger log)
{
log.LogInformation($"C# Blob trigger function processed: {myBlob}");
}
Hinweis
Informationen zu einem neueren Protokollierungsframework, das Sie anstelle von TraceWriter verwenden können, finden Sie in der ILogger-Dokumentation im Entwicklerleitfaden für .NET-Klassenbibliotheken.
Protokollieren von benutzerdefinierten Metriken
Sie können die LogMetric-Erweiterungsmethode in ILogger verwenden, um in Application Insights benutzerdefinierte Metriken zu erstellen. Hier ist ein Beispiel für einen Methodenaufruf angegeben:
logger.LogMetric("TestMetric", 1234);
Dieser Code ist eine Alternative zum Aufrufen von TrackMetric mithilfe der Application Insights-API für .NET.
Async
Um eine Funktion asynchron auszuführen, verwenden Sie das async-Schlüsselwort, und geben Sie ein Task-Objekt zurück.
public async static Task ProcessQueueMessageAsync(
string blobName,
Stream blobInput,
Stream blobOutput)
{
await blobInput.CopyToAsync(blobOutput, 4096);
}
Sie können keine out-Parameter in asynchronen Funktionen verwenden. Für Ausgabebindungen verwenden Sie stattdessen Funktionsrückgabewert oder Sammlerobjekt.
Abbruchtoken
Eine Funktion kann einen CancellationToken-Parameter annehmen, der es dem Betriebssystem ermöglicht, den Code vor dem Beenden der Funktion zu benachrichtigen. Sie können diese Benachrichtigung verwenden, um sicherzustellen, dass die Funktion nicht auf eine Weise unerwartet beendet wird, die die Daten in einem inkonsistenten Zustand hinterlässt.
Das folgende Beispiel zeigt, wie Sie nach einer bevorstehenden Beendigung einer Funktion suchen.
using System;
using System.IO;
using System.Threading;
public static void Run(
string inputText,
TextWriter logger,
CancellationToken token)
{
for (int i = 0; i < 100; i++)
{
if (token.IsCancellationRequested)
{
logger.WriteLine("Function was cancelled at iteration {0}", i);
break;
}
Thread.Sleep(5000);
logger.WriteLine("Normal processing for queue message={0}", inputText);
}
}
Importieren von Namespaces
Wenn Sie Namespaces importieren müssen, ist dies wie üblich über die using -Klausel möglich.
using System.Net;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
public static Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger log)
Die folgenden Namespaces werden automatisch importiert und sind daher optional:
SystemSystem.Collections.GenericSystem.IOSystem.LinqSystem.Net.HttpSystem.Threading.TasksMicrosoft.Azure.WebJobsMicrosoft.Azure.WebJobs.Host
Verweise auf externe Assemblys
Bei Frameworkassemblys können Sie Verweise über die #r "AssemblyName" -Anweisung hinzufügen.
#r "System.Web.Http"
using System.Net;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
public static Task<HttpResponseMessage> Run(HttpRequestMessage req, ILogger log)
Die folgenden Assemblys werden automatisch von der Azure Functions-Hostumgebung hinzugefügt:
mscorlibSystemSystem.CoreSystem.XmlSystem.Net.HttpMicrosoft.Azure.WebJobsMicrosoft.Azure.WebJobs.HostMicrosoft.Azure.WebJobs.ExtensionsSystem.Web.HttpSystem.Net.Http.Formatting
Von einem einfachen Namen kann auf folgende Assemblys nach Runtimeversion verwiesen werden:
Im Code werden Assemblys wie das folgende Beispiel referenziert:
#r "AssemblyName"
Verweisen von benutzerdefinierten Assemblys
Um eine benutzerdefinierte Assembly zu verweisen, können Sie entweder eine freigegebene Assembly oder eine private Assembly verwenden:
Freigegebene Assemblys werden für alle Funktionen innerhalb einer Funktionen-App freigegeben. Um auf eine benutzerdefinierte Assembly zu verweisen, laden Sie die Assembly in einen Ordner namens
binim Stammverzeichnis (wwwroot) der Funktions-App hoch.Private Assemblys sind Bestandteil eines Kontexts einer bestimmten Funktion und unterstützen das Querladen von verschiedenen Versionen. Private Assemblys sollten in einen
bin-Ordner im Funktionsverzeichnis hochgeladen werden. Verweisen Sie auf die Assemblys, indem Sie den Dateinamen verwenden, etwa#r "MyAssembly.dll".
Informationen zum Hochladen von Dateien in Ihren Funktionenordner finden Sie im Abschnitt zur Paketverwaltung.
Überwachte Verzeichnisse
Das Verzeichnis, das die Skriptdatei für die Funktion enthält, wird automatisch im Hinblick auf Änderungen an Assemblys überwacht. Um Änderungen an Assemblys in anderen Verzeichnissen zu überwachen, fügen Sie sie der Liste watchDirectories in der Datei host.json hinzu.
Verwenden von NuGet-Paketen
Die Art und Weise, wie sowohl Bindungserweiterungspakete als auch andere NuGet-Pakete zu Ihrer Funktions-App hinzugefügt werden, hängt von der zielbezogenen Version der Funktions-Laufzeit ab.
Standardmäßig werden die unterstützten Funktionenerweiterungs-NuGet-Pakete für Ihre C#-Skript-Funktions-App mithilfe von Erweiterungsbündeln zur Verfügung gestellt. Weitere Informationen finden Sie unter Erweiterungspakete.
Wenn Sie aus irgendeinem Grund Erweiterungsbündel in Ihrem Projekt nicht verwenden können, können Sie auch die Azure Functions Core Tools verwenden, um Erweiterungen basierend auf Bindungen zu installieren, die in den function.json-Dateien in Ihrer App definiert sind. Wenn Sie Core Tools verwenden, um Erweiterungen zu registrieren, stellen Sie sicher, dass Sie die Option --csx verwenden. Weitere Informationen finden Sie unter Installieren von Funktionserweiterungen.
Standardmäßig liest Core Tools die function.json-Dateien und fügt die erforderlichen Pakete zu einer extension.csproj-C#-Klassenbibliothek-Projektdatei im Stamm des Dateisystems der Funktions-App (wwwroot) hinzu. Da Core Tools dotnet.exe verwendet, können Sie sie verwenden, um einen beliebigen NuGet-Paketverweis zu dieser Erweiterungsdatei hinzuzufügen. Während der Installation erstellt Core Tools die extensions.csproj, um die erforderlichen Bibliotheken zu installieren. Hier sehen Sie ein Beispiel für die Datei extensions.csproj, die einen Verweis auf Microsoft.ProjectOxford.Face (Version 1.1.0) hinzufügt:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.ProjectOxford.Face" Version="1.1.0" />
</ItemGroup>
</Project>
Hinweis
Für C#-Skript (CSX-Dateien) müssen Sie TargetFramework auf den Wert netstandard2.0 festlegen. Andere Zielframeworks wie net6.0werden nicht unterstützt.
Um einen benutzerdefinierten NuGet-Feed zu verwenden, geben Sie den Feed in der Datei Nuget.Config im Stammordner der Funktions-App an. Weitere Informationen finden Sie unter Konfigurieren des NuGet-Verhaltens.
Wenn Sie nur im Portal an Ihrem Projekt arbeiten, müssen Sie die Datei „extensions.csproj“ oder eine Nuget.Config-Datei direkt auf der Website manuell erstellen. Weitere Informationen finden Sie unter Manuelles Installieren von Erweiterungen.
Umgebungsvariablen
Verwenden Sie System.Environment.GetEnvironmentVariablezum Abrufen einer Umgebungsvariablen oder zum Abrufen des Werts einer App-Einstellung, wie im folgenden Codebeispiel zu sehen:
public static void Run(TimerInfo myTimer, ILogger log)
{
log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}");
log.LogInformation(GetEnvironmentVariable("AzureWebJobsStorage"));
log.LogInformation(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
}
public static string GetEnvironmentVariable(string name)
{
return name + ": " +
System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
}
Wiederholungsrichtlinien
Functions unterstützt zwei integrierte Wiederholungsrichtlinien. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.
Wiederholungsrichtlinie in der Datei function.json:
{
"disabled": false,
"bindings": [
{
....
}
],
"retry": {
"strategy": "fixedDelay",
"maxRetryCount": 4,
"delayInterval": "00:00:10"
}
}
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| strategy | Verwenden Sie fixedDelay. |
| maxRetryCount | Erforderlich. Die maximale Anzahl zulässiger Wiederholungen pro Funktionsausführung. -1 bedeutet unbegrenzte Wiederholungen. |
| delayInterval | Die Verzögerung, die zwischen Wiederholungsversuchen verwendet wird. Geben Sie sie als Zeichenfolge im Format HH:mm:ss an. |
Binden zur Laufzeit
In C# und anderen .NET-Sprachen können Sie ein imperatives Bindungsmuster verwenden, im Gegensatz zu den deklarativen Bindungen in function.json. Imperative Bindung eignet sich, wenn Bindungsparameter zur Laufzeit statt zur Entwurfszeit berechnet werden müssen. Mit diesem Muster ist die Bindung an unterstützte Eingabe- und Ausgabebindungen direkt im Funktionscode möglich.
Definieren Sie eine imperative Bindung wie folgt:
- Schließen Sie für die gewünschten imperativen Bindungen keinen Eintrag in function.json ein.
- Übergeben Sie den Eingabeparameter
Binder binderoderIBinder binder. - Verwenden Sie das folgende C#-Muster, um die Datenbindung auszuführen.
using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
{
...
}
BindingTypeAttribute ist das .NET-Attribut, das die Bindung definiert, und T ist ein Eingabe- oder Ausgabetyp, der von diesem Bindungstyp unterstützt wird. T darf kein out-Parametertyp sein (wie etwa out JObject). Die ausgehende Bindung der Mobile Apps-Tabelle unterstützt z. B. sechs Ausgabetypen. Sie können jedoch nur ICollector<T> oder IAsyncCollector<T> für T verwenden.
Beispiel mit einem einzigen Attribut
Mit dem folgenden Beispielcode wird eine ausgehende Speicherblob-Bindung mit einem Blobpfad erstellt, der zur Laufzeit definiert wird. Dann wird eine Zeichenfolge in das Blob geschrieben.
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host.Bindings.Runtime;
public static async Task Run(string input, Binder binder)
{
using (var writer = await binder.BindAsync<TextWriter>(new BlobAttribute("samples-output/path")))
{
writer.Write("Hello World!!");
}
}
BlobAttribute definiert die Eingabe- oder Ausgabebindung für den Speicherblob, und TextWriter ist ein unterstützter Ausgabenbindungstyp.
Beispiel für mehrere Attribute
Im vorherigen Beispiel wird die App-Einstellung für die Verbindungszeichenfolge (AzureWebJobsStorage) des Hauptspeicherkontos der Funktions-App abgerufen. Sie können eine benutzerdefinierte App-Einstellung angeben, die für das Storage-Konto verwendet werden soll, indem Sie StorageAccountAttribute hinzufügen und das Attributarray an BindAsync<T>() übergeben. Verwenden Sie einen Binder-Parameter, nicht IBinder. Beispiel:
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Host.Bindings.Runtime;
public static async Task Run(string input, Binder binder)
{
var attributes = new Attribute[]
{
new BlobAttribute("samples-output/path"),
new StorageAccountAttribute("MyStorageAccount")
};
using (var writer = await binder.BindAsync<TextWriter>(attributes))
{
writer.Write("Hello World!");
}
}
In der folgenden Tabelle werden die .NET-Attribute für jeden Bindungstyp und die Pakete aufgelistet, in denen sie definiert sind.
Konvertieren einer C#-Skript-App in ein C#-Projekt
Die einfachste Möglichkeit zum Konvertieren einer C#-Skriptfunktions-App in ein kompiliertes C#-Klassenbibliotheksprojekt besteht darin, mit einem neuen Projekt zu beginnen. Anschließend können Sie für jede Funktion den Code und die Konfiguration aus den einzelnen Dateien „run.csx“ und „function.json“ in einem Funktionsordner in eine einzelne neue CS-Klassenbibliothekscodedatei migrieren. Wenn Sie beispielsweise über eine C#-Skriptfunktion namens HelloWorld verfügen, verfügen Sie dann über zwei Dateien: HelloWorld/run.csx und HelloWorld/function.json. Für diese Funktion erstellen Sie eine Codedatei mit dem Namen HelloWorld.cs in Ihrem neuen Klassenbibliotheksprojekt.
Wenn Sie C#-Skripts für die Portalbearbeitung verwenden, können Sie den App-Inhalt auf Ihren lokalen Computer herunterladen. Wählen Sie die Option Websiteinhalt anstelle von Inhalt und Visual Studio-Projekt aus. Sie müssen kein Projekt generieren und keine Anwendungseinstellungen in den Download einschließen. Sie definieren eine neue Entwicklungsumgebung, die nicht dieselben Berechtigungen wie Ihre gehostete App-Umgebung aufweisen sollte.
In diesen Anweisungen erfahren Sie, wie Sie C#-Skriptfunktionen (die in einem Prozess mit dem Functions-Host ausgeführt werden) in C#-Klassenbibliotheksfunktionen konvertieren, die in einem isolierten Workerprozess ausgeführt werden.
Schließen Sie den Abschnitt Erstellen eines Funktions-App-Projekts in Ihrem bevorzugten Schnellstart aus:
Wenn der ursprüngliche C#-Skriptcode eine Datei mit dem Namen
extensions.csprojoder Dateien mit dem Namenfunction.projenthält, kopieren Sie die Paketverweise aus diesen Dateien, und fügen Sie sie der.csproj-Datei des neuen Projekts in derItemGroupmit den Funktionskernabhängigkeiten hinzu.Tipp
Die Konvertierung bietet eine gute Gelegenheit zum Aktualisieren auf die neuesten Versionen der Abhängigkeiten. Wenn Sie dies tun, können zusätzliche Codeänderungen in einem späteren Schritt erforderlich sein.
Kopieren Sie den Inhalt der ursprünglichen Datei
host.jsonin die Dateihost.jsondes neuen Projekts, mit Ausnahme des AbschnittsextensionBundles. (In kompilierten C#-Projekten werden keine Erweiterungspakete verwendet, und Sie müssen Verweise auf alle in Ihren Funktionen verwendeten Erweiterungen explizit hinzufügen.) Denken Sie beim Zusammenführen von „host.json“-Dateien daran, dass dashost.json-Schema versioniert ist, wobei die meisten Apps Version 2.0 verwenden. Der Inhalt des Abschnittsextensionskann je nach den genauen Versionen der in Ihren Funktionen verwendeten Bindungserweiterungen abweichen. In den Referenzartikeln zu einzelnen Erweiterungen erfahren Sie, wie Sie die Datei „host.json“ für Ihre spezifischen Versionen ordnungsgemäß konfigurieren.Erstellen Sie für alle freigegebenen Dateien, auf die aus einer
#load-Direktive verwiesen wird, eine neue.cs-Datei für jeden dieser freigegebenen Verweise. Am einfachsten kann eine neue.cs-Datei für jede Definition einer freigegebenen Klasse erstellt werden. Wenn statische Methoden ohne Klasse vorhanden sind, müssen Sie für diese Methoden neue Klassen definieren.Führen Sie für jeden
<FUNCTION_NAME>-Ordner in Ihrem ursprünglichen Projekt die folgenden Aufgaben aus:Erstellen Sie eine neue Datei namens
<FUNCTION_NAME>.cs, und ersetzen Sie<FUNCTION_NAME>durch den Namen des Ordners, der Ihre C#-Skriptfunktion definiert hat. Sie können eine neue Funktionscodedatei aus einer der triggerspezifischen Vorlagen wie folgt erstellen:Verwenden des Befehls
func new --name <FUNCTION_NAME>und Auswählen der richtigen Triggervorlage an der Eingabeaufforderung.Kopieren Sie die
using-Anweisungen aus Ihrerrun.csx-Datei, und fügen Sie sie der neuen Datei hinzu. Sie benötigen keine#r-Direktiven.Fügen Sie für jede
#load-Anweisung in Ihrerrun.csx-Datei eine neueusing-Anweisung für den Namespace hinzu, den Sie für den freigegebenen Code verwendet haben.Definieren Sie in der neuen Datei unter dem Namespace, den Sie für das Projekt verwenden, eine Klasse für Ihre Funktion.
Erstellen Sie eine Methode mit dem Namen
RunHandleroder einem ähnlichen Namen. Diese neue Methode dient als neuer Einstiegspunkt für die Funktion.Kopieren Sie die statische Methode, die Ihre Funktion darstellt, zusammen mit allen Funktionen, die sie aufruft, aus
run.csx, und fügen Sie sie als zweite Methode in Ihre neue Klasse ein. Rufen Sie diese statische Methode aus der neuen Methode, die Sie im vorherigen Schritt erstellt haben, auf. Dieser Umleitungsschritt ist hilfreich, um etwaige Unterschiede bei der Fortsetzung des Upgrades zu erkennen. Sie können die ursprüngliche Methode unverändert beibehalten und lediglich ihre Eingaben aus dem neuen Kontext heraus steuern. Möglicherweise müssen Sie Parameter für die neue Methode erstellen, die Sie dann an den Aufruf der statischen Methode übergeben. Nachdem Sie sich vergewissert haben, dass die Migration wie beabsichtigt funktioniert hat, können Sie diese zusätzliche Umleitungsebene entfernen.Fügen Sie ihrer neuen Methode für jede Bindung in der
function.json-Datei das entsprechende Attribut hinzu. Unter Manuelles Hinzufügen von Bindungen anhand von Beispielen können Sie schnell einige Bindungsbeispiele finden.Fügen Sie Ihrem Projekt alle Erweiterungspakete hinzu, die für die Bindungen erforderlich sind, sofern dies noch nicht geschehen ist.
Erstellen Sie alle Anwendungseinstellungen, die für Ihre App erforderlich sind, in der Sammlung
Valuesder Datei local.settings.json neu.Vergewissern Sie sich, dass das Projekt lokal ausgeführt wird:
Führen Sie die App mithilfe von
func startüber die Befehlszeile aus. Weitere Informationen finden Sie unter Lokales Ausführen von Funktionen.Veröffentlichen Sie Ihr Projekt in einer neuen Funktions-App in Azure:
Erstellen Sie Ihre Azure-Ressourcen, und stellen Sie das Codeprojekt mithilfe des Befehls
func azure functionapp publish <APP_NAME>in Azure bereit. Weitere Informationen finden Sie unter Bereitstellen von Projektdateien.
Beispiel: Funktionskonvertierung
Dieser Abschnitt enthält ein Beispiel für die Migration einer einzelnen Funktion.
Die ursprüngliche Funktion im C#-Skript verfügt über zwei Dateien:
HelloWorld/function.jsonHelloWorld/run.csx
HelloWorld/function.json enthält Folgendes:
{
"bindings": [
{
"authLevel": "FUNCTION",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
}
]
}
HelloWorld/run.csx enthält Folgendes:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
string responseMessage = string.IsNullOrEmpty(name)
? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
: $"Hello, {name}. This HTTP triggered function executed successfully.";
return new OkObjectResult(responseMessage);
}
Nach der Migration zum isolierten Workermodell mit ASP.NET Core-Integration werden diese durch eine einzelne HelloWorld.cs-Datei ersetzt:
using System.Net;
using Microsoft.Azure.Functions.Worker;
using Microsoft.AspNetCore.Http;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Logging;
using Microsoft.AspNetCore.Routing;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
namespace MyFunctionApp
{
public class HelloWorld
{
private readonly ILogger _logger;
public HelloWorld(ILoggerFactory loggerFactory)
{
_logger = loggerFactory.CreateLogger<HelloWorld>();
}
[Function("HelloWorld")]
public async Task<IActionResult> RunHandler([HttpTrigger(AuthorizationLevel.Function, "get")] HttpRequest req)
{
return await Run(req, _logger);
}
// From run.csx
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
string responseMessage = string.IsNullOrEmpty(name)
? "This HTTP triggered function executed successfully. Pass a name in the query string or in the request body for a personalized response."
: $"Hello, {name}. This HTTP triggered function executed successfully.";
return new OkObjectResult(responseMessage);
}
}
}
Bindungskonfiguration und Beispiele
Dieser Abschnitt enthält Verweise und Beispiele zum Definieren von Triggern und Bindungen in C#-Skripts.
Blobtrigger
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf blobTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die das Blob im Funktionscode darstellt. |
| path | Der zu überwachende Container. Kann ein Blobnamensmuster sein. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt eine Blobtriggerdefinition in einer Datei function.json sowie Code, in dem die Bindung verwendet wird. Die Funktion schreibt ein Protokoll, wenn im samples-workitems-Container ein Blob hinzugefügt oder aktualisiert wird.
Bindungsdaten in der Datei function.json:
{
"disabled": false,
"bindings": [
{
"name": "myBlob",
"type": "blobTrigger",
"direction": "in",
"path": "samples-workitems/{name}",
"connection":"MyStorageAccountAppSetting"
}
]
}
Die Zeichenfolge {name} im Blobtriggerpfad samples-workitems/{name} erstellt einen {name}, den Sie im Funktionscode verwenden können, um auf den Dateinamen des auslösenden Blobs zuzugreifen. Weitere Informationen finden Sie unter Blobnamenmuster.
C#-Skriptcode für die Bindung an Stream:
public static void Run(Stream myBlob, string name, ILogger log)
{
log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name} \n Size: {myBlob.Length} Bytes");
}
C#-Skriptcode für die Bindung an CloudBlockBlob:
#r "Microsoft.WindowsAzure.Storage"
using Microsoft.WindowsAzure.Storage.Blob;
public static void Run(CloudBlockBlob myBlob, string name, ILogger log)
{
log.LogInformation($"C# Blob trigger function Processed blob\n Name:{name}\nURI:{myBlob.StorageUri}");
}
Blobeingabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf blob festgelegt sein. |
| direction | Muss auf in festgelegt sein. |
| name | Der Name der Variablen, die das Blob im Funktionscode darstellt. |
| path | Der Pfad des Blobs. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt Blobeingabe- und -ausgabebindungen in einer Datei function.json sowie C#-Skriptcode, der diese Bindungen verwendet. Die Funktion erstellt eine Kopie eines Textblobs. Sie wird durch eine Warteschlangennachricht ausgelöst, die den Namen des zu kopierenden Blobs enthält. Der Name des neuen Blobs lautet {Name des Originalblobs}-Copy.
In der Datei function.json wird die Metadateneigenschaft queueTrigger verwendet, um den Blobnamen in den Eigenschaften vom Typ path anzugeben:
{
"bindings": [
{
"queueName": "myqueue-items",
"connection": "MyStorageConnectionAppSetting",
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in"
},
{
"name": "myInputBlob",
"type": "blob",
"path": "samples-workitems/{queueTrigger}",
"connection": "MyStorageConnectionAppSetting",
"direction": "in"
},
{
"name": "myOutputBlob",
"type": "blob",
"path": "samples-workitems/{queueTrigger}-Copy",
"connection": "MyStorageConnectionAppSetting",
"direction": "out"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(string myQueueItem, string myInputBlob, out string myOutputBlob, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
myOutputBlob = myInputBlob;
}
Blobausgabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf blob festgelegt sein. |
| direction | Muss auf out festgelegt sein. |
| name | Der Name der Variablen, die das Blob im Funktionscode darstellt. |
| path | Der Pfad des Blobs. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Blobs hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt Blobeingabe- und -ausgabebindungen in einer Datei function.json sowie C#-Skriptcode, der diese Bindungen verwendet. Die Funktion erstellt eine Kopie eines Textblobs. Sie wird durch eine Warteschlangennachricht ausgelöst, die den Namen des zu kopierenden Blobs enthält. Der Name des neuen Blobs lautet {Name des Originalblobs}-Copy.
In der Datei function.json wird die Metadateneigenschaft queueTrigger verwendet, um den Blobnamen in den Eigenschaften vom Typ path anzugeben:
{
"bindings": [
{
"queueName": "myqueue-items",
"connection": "MyStorageConnectionAppSetting",
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in"
},
{
"name": "myInputBlob",
"type": "blob",
"path": "samples-workitems/{queueTrigger}",
"connection": "MyStorageConnectionAppSetting",
"direction": "in"
},
{
"name": "myOutputBlob",
"type": "blob",
"path": "samples-workitems/{queueTrigger}-Copy",
"connection": "MyStorageConnectionAppSetting",
"direction": "out"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(string myQueueItem, string myInputBlob, out string myOutputBlob, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
myOutputBlob = myInputBlob;
}
RabbitMQ-Trigger
Das folgende Beispiel zeigt eine RabbitMQ-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die diese Bindung verwendet. Die Funktion liest und protokolliert die RabbitMQ-Nachricht.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"name": "myQueueItem",
"type": "rabbitMQTrigger",
"direction": "in",
"queueName": "queue",
"connectionStringSetting": "rabbitMQConnectionAppSetting"
}
]
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
public static void Run(string myQueueItem, ILogger log)
{
log.LogInformation($"C# Script RabbitMQ trigger function processed: {myQueueItem}");
}
Warteschlangentrigger
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf queueTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Nur in der Datei function.json. Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die die Nutzlast des Warteschlangenelements im Funktionscode enthält. |
| queueName | Der Name der abzufragenden Warteschlange. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Queues hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt eine Warteschlangentriggerbindung in einer Datei vom Typ function.json sowie C#-Skriptcode, in dem die Bindung verwendet wird. Die Funktion fragt die Warteschlange myqueue-items ab und schreibt ein Protokoll, sobald ein Warteschlangenelement verarbeitet wird.
Die Datei function.json sieht wie folgt aus:
{
"disabled": false,
"bindings": [
{
"type": "queueTrigger",
"direction": "in",
"name": "myQueueItem",
"queueName": "myqueue-items",
"connection":"MyStorageConnectionAppSetting"
}
]
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.WindowsAzure.Storage"
using Microsoft.Extensions.Logging;
using Microsoft.WindowsAzure.Storage.Queue;
using System;
public static void Run(CloudQueueMessage myQueueItem,
DateTimeOffset expirationTime,
DateTimeOffset insertionTime,
DateTimeOffset nextVisibleTime,
string queueTrigger,
string id,
string popReceipt,
int dequeueCount,
ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem.AsString}\n" +
$"queueTrigger={queueTrigger}\n" +
$"expirationTime={expirationTime}\n" +
$"insertionTime={insertionTime}\n" +
$"nextVisibleTime={nextVisibleTime}\n" +
$"id={id}\n" +
$"popReceipt={popReceipt}\n" +
$"dequeueCount={dequeueCount}");
}
Ausgabe der Warteschlange
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf queue festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf out festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die die Warteschlange im Funktionscode darstellt. Legen Sie diesen Wert auf $return fest, um auf den Rückgabewert der Funktion zu verweisen. |
| queueName | Der Name der Warteschlange. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Azure Queues hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt eine HTTP-Triggerbindung in einer Datei vom Typ function.json sowie C#-Skriptcode, in dem die Bindung verwendet wird. Die Funktion erstellt ein Warteschlangenelement mit einer CustomQueueMessage-Objektnutzlast für jede empfangene HTTP-Anforderung.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"authLevel": "function",
"name": "input"
},
{
"type": "http",
"direction": "out",
"name": "$return"
},
{
"type": "queue",
"direction": "out",
"name": "$return",
"queueName": "outqueue",
"connection": "MyStorageConnectionAppSetting"
}
]
}
Der folgende C#-Skriptcode erstellt eine einzelne Warteschlangennachricht:
public class CustomQueueMessage
{
public string PersonName { get; set; }
public string Title { get; set; }
}
public static CustomQueueMessage Run(CustomQueueMessage input, ILogger log)
{
return input;
}
Mithilfe eines Parameters vom Typ ICollector oder IAsyncCollector können mehrere Nachrichten gleichzeitig gesendet werden. Der folgende C#-Skriptcode sendet mehrere Nachrichten – eine mit den HTTP-Anforderungsdaten und eine mit hartcodierten Werten:
public static void Run(
CustomQueueMessage input,
ICollector<CustomQueueMessage> myQueueItems,
ILogger log)
{
myQueueItems.Add(input);
myQueueItems.Add(new CustomQueueMessage { PersonName = "You", Title = "None" });
}
Tabelleneingabe
In diesem Abschnitt wird nur die Unterstützung für die Tabellen-API-Version der Erweiterung beschrieben.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf table festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen. |
| direction | Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen. |
| name | Der Name der Variablen, die die Tabelle oder Entität im Funktionscode darstellt. |
| tableName | Der Name der Tabelle. |
| partitionKey | Optional. Der Partitionsschlüssel der zu lesenden Tabellenentität. |
| rowKey | Optional. Der Zeilenschlüssel der zu lesenden Tabellenentität. Kann nicht mit take oder filter verwendet werden. |
| take | Optional. Die maximale Anzahl der zurückzugebenden Nachrichten. Kann nicht mit "rowKey" verwendet werden. |
| filter | Optional. Ein OData-Filterausdruck für die Entitäten, die aus der Tabelle zurückgegeben werden sollen. Kann nicht mit "rowKey" verwendet werden. |
| connection | Der Name einer App-Einstellung oder Einstellungssammlung, die angibt, wie eine Verbindung mit dem Tabellendienst hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt eine Tabelleneingabebindung in einer function.json-Datei sowie C#-Skriptcode, der die Bindung verwendet. Die Funktion verwendet einen Warteschlangentrigger zum Lesen einer einzelnen Tabellenzeile.
Die Datei function.json gibt jeweils einen Wert für partitionKey und rowKey zurück. Der rowKey-Wert {queueTrigger} gibt an, dass der Zeilenschlüssel aus der Warteschlangennachricht-Zeichenfolge stammt.
{
"bindings": [
{
"queueName": "myqueue-items",
"connection": "MyStorageConnectionAppSetting",
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in"
},
{
"name": "personEntity",
"type": "table",
"tableName": "Person",
"partitionKey": "Test",
"rowKey": "{queueTrigger}",
"connection": "MyStorageConnectionAppSetting",
"direction": "in"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Azure.Data.Tables"
using Microsoft.Extensions.Logging;
using Azure.Data.Tables;
public static void Run(string myQueueItem, Person personEntity, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
log.LogInformation($"Name in Person entity: {personEntity.Name}");
}
public class Person : ITableEntity
{
public string Name { get; set; }
public string PartitionKey { get; set; }
public string RowKey { get; set; }
public DateTimeOffset? Timestamp { get; set; }
public ETag ETag { get; set; }
}
Tabellenausgabe
In diesem Abschnitt wird nur die Unterstützung für die Tabellen-API-Version der Erweiterung beschrieben.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | 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. |
Das folgende Beispiel zeigt eine Tabellenausgabebindung in einer Datei function.json sowie C#-Skriptcode, der die Bindung verwendet. Die Funktion schreibt mehrere Tabellenentitäten.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"name": "input",
"type": "manualTrigger",
"direction": "in"
},
{
"tableName": "Person",
"connection": "MyStorageConnectionAppSetting",
"name": "tableBinding",
"type": "table",
"direction": "out"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(string input, ICollector<Person> tableBinding, ILogger log)
{
for (int i = 1; i < 10; i++)
{
log.LogInformation($"Adding Person entity {i}");
tableBinding.Add(
new Person() {
PartitionKey = "Test",
RowKey = i.ToString(),
Name = "Name" + i.ToString() }
);
}
}
public class Person
{
public string PartitionKey { get; set; }
public string RowKey { get; set; }
public string Name { get; set; }
}
Trigger mit Timer
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf timerTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die das Timerobjekt im Funktionscode darstellt. |
| schedule | Ein CRON-Ausdruck oder ein TimeSpan-Wert. TimeSpan kann nur für eine Funktionen-App verwendet werden, die in einem App Service-Plan ausgeführt wird. Sie können den Zeitplanausdruck in eine App-Einstellung einfügen und diese Eigenschaft auf den Namen der App-Einstellung festlegen, der wie in diesem Beispiel % -Zeichen als Wrapper verwendet: „%ScheduleAppSetting%“. |
| runOnStartup | Wenn true, wird die Funktion beim Starten der Laufzeit aufgerufen. Die Laufzeit startet beispielsweise, wenn die Funktionen-App nach dem Leerlauf aufgrund von Inaktivität reaktiviert wird, wenn die Funktionen-App aufgrund von Funktionsänderungen neu gestartet wird und wenn die Funktionen-App horizontal hochskaliert wird. Vorsichtig verwenden. runOnStartup sollte insbesondere in der Produktionsumgebung selten, wenn überhaupt, auf true festgelegt werden. |
| useMonitor | Legen Sie diese Eigenschaft auf true oder false fest, um anzugeben, ob der Zeitplan überwacht werden soll. Durch die Überwachung des Zeitplans werden Zeitplantermine beibehalten, mit deren Hilfe sichergestellt werden kann, dass der Zeitplan richtig eingehalten wird, selbst wenn Instanzen der Funktionen-App neu gestartet werden. Wenn diese Eigenschaft nicht explizit festgelegt wird, lautet der Standardwert true für Zeitpläne mit einem Wiederholungsintervall von mehr als oder gleich einer Minute. Bei Zeitplänen, die mehr als einmal pro Minute ausgelöst werden, lautet der Standardwert false. |
Das folgende Beispiel zeigt eine Triggerbindung mit Timer in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion schreibt ein Protokoll, das angibt, ob dieser Funktionsaufruf aufgrund eines versäumten Zeitplantermins erfolgt. Das TimerInfo-Objekt wird an die Funktion übergeben.
Bindungsdaten in der Datei function.json:
{
"schedule": "0 */5 * * * *",
"name": "myTimer",
"type": "timerTrigger",
"direction": "in"
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(TimerInfo myTimer, ILogger log)
{
if (myTimer.IsPastDue)
{
log.LogInformation("Timer is running late!");
}
log.LogInformation($"C# Timer trigger function executed at: {DateTime.Now}" );
}
HTTP-Trigger
Die folgende Tabelle gibt Aufschluss über die Triggerkonfigurationseigenschaften, die Sie in der Datei function.json festlegen:
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Erforderlich – muss auf httpTrigger festgelegt sein. |
| direction | Erforderlich – muss auf in festgelegt sein. |
| name | Erforderlich – der Variablenname, der im Funktionscode für die Anforderung oder den Anforderungstext verwendet wird. |
| authLevel | Bestimmt, welche Schlüssel (sofern erforderlich) in der Anforderung vorhanden sein müssen, um die Funktion aufzurufen. Unterstützte Werte sind unter Autorisierungsstufe aufgeführt. |
| methods | Ein Array der HTTP-Methoden, auf die diese Funktion antwortet. Wird dieses Array nicht angegeben, antwortet die Funktion auf alle HTTP-Methoden. Siehe Anpassen des HTTP-Endpunkts. |
| route | Definiert die Routenvorlage, mit der gesteuert wird, auf welche Anforderungs-URLs die Funktion antwortet. Wenn kein anderer Wert angegeben wird, lautet der Standardwert <functionname>. Weitere Informationen finden Sie unter Anpassen des HTTP-Endpunkts. |
| webHookType | Nur für die Laufzeit der Version 1.x unterstützt. Konfiguriert den HTTP-Trigger so, dass er als Webhookempfänger für den angegebenen Anbieter fungiert. Unterstützte Werte sind unter WebHook-Typ aufgeführt. |
Das folgende Beispiel zeigt eine Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion sucht in der Abfragezeichenfolge oder im Text der HTTP-Anforderung nach einem name-Parameter.
Die Datei function.json sieht wie folgt aus:
{
"disabled": false,
"bindings": [
{
"authLevel": "function",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
}
]
}
C#-Skriptcode für die Bindung an HttpRequest:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string name = req.Query["name"];
string requestBody = String.Empty;
using (StreamReader streamReader = new StreamReader(req.Body))
{
requestBody = await streamReader.ReadToEndAsync();
}
dynamic data = JsonConvert.DeserializeObject(requestBody);
name = name ?? data?.name;
return name != null
? (ActionResult)new OkObjectResult($"Hello, {name}")
: new BadRequestObjectResult("Please pass a name on the query string or in the request body");
}
Sie können anstelle von HttpRequest auch an ein benutzerdefiniertes Objekt binden. Dieses Objekt wird aus dem Text der Anforderung erstellt und als JSON analysiert. Analog dazu kann ein Typ an die Ausgabebindung der HTTP-Antwort übergeben und zusammen mit dem Statuscode 200 als Antworttext zurückgegeben werden.
using System.Net;
using System.Threading.Tasks;
using Microsoft.Extensions.Logging;
public static string Run(Person person, ILogger log)
{
return person.Name != null
? (ActionResult)new OkObjectResult($"Hello, {person.Name}")
: new BadRequestObjectResult("Please pass an instance of Person.");
}
public class Person {
public string Name {get; set;}
}
HTTP-Ausgabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| Eigenschaft | Beschreibung des Dataflows |
|---|---|
| type | Muss auf http festgelegt sein. |
| direction | Muss auf out festgelegt sein. |
| name | Der Variablenname, der im Funktionscode für die Antwort verwendet wird, oder $return für die Verwendung des Rückgabewerts. |
Event Hubs-Trigger
Die folgende Tabelle gibt Aufschluss über die Triggerkonfigurationseigenschaften, die Sie in der Datei function.json festlegen:
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf eventHubTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die das Ereigniselement im Funktionscode darstellt. |
| eventHubName | Functions 2.x und höher Der Name des Event Hubs. Wenn der Event Hub-Name auch in der Verbindungszeichenfolge enthalten ist, setzt dieser Wert diese Eigenschaft zur Laufzeit außer Kraft. Darauf kann über App-Einstellungen %eventHubName% verwiesen werden. In Version 1.x heißt diese Eigenschaft path. |
| consumerGroup | Eine optionale Eigenschaft, die zum Festlegen der Consumergruppe verwendet wird, mit der Ereignisse im Hub abonniert werden. Wird sie nicht angegeben, wird die Consumergruppe $Default verwendet. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Event Hubs hergestellt wird. Siehe Verbindungen. |
Das folgende Beispiel zeigt eine Event Hubs-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion protokolliert den Nachrichtentext des Event Hubs-Triggers.
Die folgenden Beispiele zeigen Event Hubs-Bindungsdaten in der Datei function.json für die Functions-Runtime ab Version 2.x.
{
"type": "eventHubTrigger",
"name": "myEventHubMessage",
"direction": "in",
"eventHubName": "MyEventHub",
"connection": "myEventHubReadConnectionAppSetting"
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
public static void Run(string myEventHubMessage, TraceWriter log)
{
log.Info($"C# function triggered to process a message: {myEventHubMessage}");
}
Verwenden Sie eine Bindung an ein EventData-Objekt, um Zugriff auf Ereignismetadaten im Funktionscode zu erhalten. Sie können auch mithilfe von Bindungsausdrücken in der Methodensignatur auf die gleichen Eigenschaften zugreifen. Im folgenden Beispiel werden beide Methoden zum Abrufen der gleichen Daten veranschaulicht:
#r "Microsoft.Azure.EventHubs"
using System.Text;
using System;
using Microsoft.ServiceBus.Messaging;
using Microsoft.Azure.EventHubs;
public void Run(EventData myEventHubMessage,
DateTime enqueuedTimeUtc,
Int64 sequenceNumber,
string offset,
TraceWriter log)
{
log.Info($"Event: {Encoding.UTF8.GetString(myEventHubMessage.Body)}");
log.Info($"EnqueuedTimeUtc={myEventHubMessage.SystemProperties.EnqueuedTimeUtc}");
log.Info($"SequenceNumber={myEventHubMessage.SystemProperties.SequenceNumber}");
log.Info($"Offset={myEventHubMessage.SystemProperties.Offset}");
// Metadata accessed by using binding expressions
log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
log.Info($"SequenceNumber={sequenceNumber}");
log.Info($"Offset={offset}");
}
Um Ereignisse in einem Batch zu empfangen, deklarieren Sie string oder EventData als ein Array:
public static void Run(string[] eventHubMessages, TraceWriter log)
{
foreach (var message in eventHubMessages)
{
log.Info($"C# function triggered to process a message: {message}");
}
}
Event Hubs-Ausgabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf eventHub festgelegt sein. |
| direction | Muss auf out festgelegt sein. Dieser Parameter wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen. |
| name | Der Variablenname, der in Funktionscode verwendet wird, der das Ereignis darstellt. |
| eventHubName | Functions 2.x und höher Der Name des Event Hubs. Wenn der Event Hub-Name auch in der Verbindungszeichenfolge enthalten ist, setzt dieser Wert diese Eigenschaft zur Laufzeit außer Kraft. In Functions 1.x heißt diese Eigenschaft path. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Event Hubs hergestellt wird. Weitere Informationen finden Sie unter Verbindungen. |
Das folgende Beispiel zeigt eine Event Hub-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion schreibt eine Nachricht in einen Event Hub.
Die folgenden Beispiele zeigen Event Hubs-Bindungsdaten in der Datei function.json für die Functions-Runtime ab Version 2.x.
{
"type": "eventHub",
"name": "outputEventHubMessage",
"eventHubName": "myeventhub",
"connection": "MyEventHubSendAppSetting",
"direction": "out"
}
Der folgende C#-Skriptcode erstellt eine Nachricht:
using System;
using Microsoft.Extensions.Logging;
public static void Run(TimerInfo myTimer, out string outputEventHubMessage, ILogger log)
{
String msg = $"TimerTriggerCSharp1 executed at: {DateTime.Now}";
log.LogInformation(msg);
outputEventHubMessage = msg;
}
Der folgende C#-Skriptcode erstellt mehrere Nachrichten:
public static void Run(TimerInfo myTimer, ICollector<string> outputEventHubMessage, ILogger log)
{
string message = $"Message created at: {DateTime.Now}";
log.LogInformation(message);
outputEventHubMessage.Add("1 " + message);
outputEventHubMessage.Add("2 " + message);
}
Event Grid-Trigger
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen. Im Attribut EventGridTrigger müssen keine Konstruktorparameter oder -eigenschaften festgelegt werden.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Erforderlich – muss auf eventGridTrigger festgelegt sein. |
| direction | Erforderlich – muss auf in festgelegt sein. |
| name | Erforderlich – der Variablenname, der im Funktionscode für den Parameter verwendet wird, der die Ereignisdaten empfängt. |
Das folgende Beispiel zeigt einen in der Datei function.json definierten Event Grid-Trigger.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"type": "eventGridTrigger",
"name": "eventGridEvent",
"direction": "in"
}
],
"disabled": false
}
Hier sehen Sie ein Beispiel für eine C#-Skriptfunktion mit einem Bindungsparameter vom Typ EventGridEvent:
#r "Azure.Messaging.EventGrid"
using Azure.Messaging.EventGrid;
using Microsoft.Extensions.Logging;
public static void Run(EventGridEvent eventGridEvent, ILogger log)
{
log.LogInformation(eventGridEvent.Data.ToString());
}
Hier sehen Sie ein Beispiel für eine C#-Skriptfunktion mit einem Bindungsparameter vom Typ JObject:
#r "Newtonsoft.Json"
using Newtonsoft.Json;
using Newtonsoft.Json.Linq;
public static void Run(JObject eventGridEvent, TraceWriter log)
{
log.Info(eventGridEvent.ToString(Formatting.Indented));
}
Event Grid-Ausgabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften für das C#-Skript, die Sie in der Datei function.json festlegen.
| Eigenschaft von „function.json“ | BESCHREIBUNG |
|---|---|
| type | Muss auf eventGrid festgelegt sein. |
| direction | Muss auf out festgelegt sein. Dieser Parameter wird automatisch festgelegt, wenn Sie die Bindung im Azure Portal erstellen. |
| name | Der Variablenname, der in Funktionscode verwendet wird, der das Ereignis darstellt. |
| topicEndpointUri | Der Name einer App-Einstellung, die den URI für das benutzerdefinierte Thema enthält, z. B. MyTopicEndpointUri. |
| topicKeySetting | Der Name einer App-Einstellung, die einen Zugriffsschlüssel für das benutzerdefinierte Thema enthält. |
Das folgende Beispiel zeigt die Event Grid-Ausgabebindungsdaten in der Datei function.json.
{
"type": "eventGrid",
"name": "outputEvent",
"topicEndpointUri": "MyEventGridTopicUriSetting",
"topicKeySetting": "MyEventGridTopicKeySetting",
"direction": "out"
}
Der folgende C#-Skriptcode erstellt ein einzelnes Ereignis:
#r "Microsoft.Azure.EventGrid"
using System;
using Microsoft.Azure.EventGrid.Models;
using Microsoft.Extensions.Logging;
public static void Run(TimerInfo myTimer, out EventGridEvent outputEvent, ILogger log)
{
outputEvent = new EventGridEvent("message-id", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0");
}
Der folgende C#-Skriptcode erstellt mehrere Ereignisse:
#r "Microsoft.Azure.EventGrid"
using System;
using Microsoft.Azure.EventGrid.Models;
using Microsoft.Extensions.Logging;
public static void Run(TimerInfo myTimer, ICollector<EventGridEvent> outputEvent, ILogger log)
{
outputEvent.Add(new EventGridEvent("message-id-1", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0"));
outputEvent.Add(new EventGridEvent("message-id-2", "subject-name", "event-data", "event-type", DateTime.UtcNow, "1.0"));
}
Service Bus-Trigger
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf serviceBusTrigger festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf in festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. |
| queueName | Der Name der zu überwachenden Warteschlange. Legen Sie diesen nur fest, wenn Sie eine Warteschlange überwachen (nicht für ein Thema). |
| topicName | Der Name des zu überwachenden Themas. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
| subscriptionName | Der Name des zu überwachenden Abonnements. Legen Sie diesen nur fest, wenn Sie ein Thema überwachen (nicht für eine Warteschlange). |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
| accessRights | Zugriffsberechtigungen für die Verbindungszeichenfolge. Verfügbare Werte sind manage und listen. Die Standardeinstellung ist manage, d.h. heißt, dass die connection die Berechtigung manage hat. Wenn Sie eine Verbindungszeichenfolge verwenden, die nicht über die Berechtigung Manage verfügt, legen Sie accessRights auf „listen“ fest. Andernfalls versucht die Functions-Runtime ggf. erfolglos Vorgänge auszuführen, die Verwaltungsrechte erfordern. In Version 2.x und höheren Versionen von Azure Functions ist diese Eigenschaft nicht verfügbar, da die aktuelle Version des Service Bus SDK Verwaltungsvorgänge nicht unterstützt. |
| isSessionsEnabled | true, wenn eine Verbindung mit einer true Warteschlange oder einem Abonnement hergestellt wird. Andernfalls false, wobei es sich um den Standardwert handelt. |
| autoComplete | true, wenn der Trigger nach der Verarbeitung automatisch „Abgeschlossen“ aufrufen soll oder ob der Funktionscode „Abgeschlossen“ manuell aufruft.Das Festlegen auf false wird nur in C# unterstützt.Wenn der Wert auf true festgelegt ist, wird die Nachricht automatisch durch den Triggervorgang abgeschlossen, sofern die Ausführung der Funktion erfolgreich war, andernfalls wird die Meldung verworfen.<br/Wenn der Wert auf false festgelegt ist, müssen Sie selbst die ServiceBusReceiver-Methoden aufrufen, um die Nachricht, die Sitzung oder den Batch abzuschließen, zu verwerfen oder in die Warteschlange für unzustellbare Nachrichten zu verschieben. Wenn eine Ausnahme ausgelöst (und keine der Methoden vom Typ ServiceBusReceiver aufgerufen) wird, bleibt die Sperre erhalten. Nachdem die Sperre abgelaufen ist, wird die Nachricht erneut in die Warteschlange eingereiht, wobei DeliveryCount erhöht und die Sperre automatisch erneuert wird.Diese Eigenschaft ist nur in Azure Functions ab Version 2.x und höher verfügbar. |
Das folgende Beispiel zeigt eine Service Bus-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion liest Nachrichtenmetadaten und protokolliert eine Service Bus-Warteschlangennachricht.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"queueName": "testqueue",
"connection": "MyServiceBusConnection",
"name": "myQueueItem",
"type": "serviceBusTrigger",
"direction": "in"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
public static void Run(string myQueueItem,
Int32 deliveryCount,
DateTime enqueuedTimeUtc,
string messageId,
TraceWriter log)
{
log.Info($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
log.Info($"EnqueuedTimeUtc={enqueuedTimeUtc}");
log.Info($"DeliveryCount={deliveryCount}");
log.Info($"MessageId={messageId}");
}
Service Bus-Ausgabe
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf serviceBus festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| direction | Muss auf out festgelegt sein. Diese Eigenschaft wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der Name der Variablen, die die Warteschlangen- oder Themanachricht im Funktionscode darstellt. Legen Sie diesen Wert auf „$return“ fest, um auf den Rückgabewert der Funktion zu verweisen. |
| queueName | Name der Warteschlange. Legen Sie diesen nur fest, wenn Warteschlangennachrichten gesendet werden (nicht für ein Thema). |
| topicName | Name des Themas. Legen Sie diesen nur fest, wenn Themanachrichten gesendet werden (nicht für eine Warteschlange). |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit Service Bus hergestellt wird Siehe Verbindungen. |
| accessRights (nur v1) | Zugriffsberechtigungen für die Verbindungszeichenfolge. Verfügbare Werte sind manage und listen. Die Standardeinstellung ist manage, d.h. heißt, dass die connection die Berechtigung manage hat. Wenn Sie eine Verbindungszeichenfolge verwenden, die nicht über die Berechtigung Manage verfügt, legen Sie accessRights auf „listen“ fest. Andernfalls versucht die Functions-Runtime ggf. erfolglos Vorgänge auszuführen, die Verwaltungsrechte erfordern. In Version 2.x und höheren Versionen von Azure Functions ist diese Eigenschaft nicht verfügbar, da die aktuelle Version des Service Bus SDK Verwaltungsvorgänge nicht unterstützt. |
Das folgende Beispiel zeigt eine Service Bus-Ausgabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion verwendet einen Timertrigger, um alle 15 Sekunden eine Warteschlangennachricht zu senden.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"schedule": "0/15 * * * * *",
"name": "myTimer",
"runsOnStartup": true,
"type": "timerTrigger",
"direction": "in"
},
{
"name": "outputSbQueue",
"type": "serviceBus",
"queueName": "testqueue",
"connection": "MyServiceBusConnection",
"direction": "out"
}
],
"disabled": false
}
Der folgende C#-Skriptcode erstellt eine einzelne Nachricht:
public static void Run(TimerInfo myTimer, ILogger log, out string outputSbQueue)
{
string message = $"Service Bus queue message created at: {DateTime.Now}";
log.LogInformation(message);
outputSbQueue = message;
}
Der folgende C#-Skriptcode erstellt mehrere Nachrichten:
public static async Task Run(TimerInfo myTimer, ILogger log, IAsyncCollector<string> outputSbQueue)
{
string message = $"Service Bus queue messages created at: {DateTime.Now}";
log.LogInformation(message);
await outputSbQueue.AddAsync("1 " + message);
await outputSbQueue.AddAsync("2 " + message);
}
Azure Cosmos DB v2-Trigger
In diesem Abschnitt wird nur die Unterstützung für Version 4.x oder höher der Erweiterung beschrieben.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf cosmosDBTrigger festgelegt sein. |
| direction | Muss auf in festgelegt sein. Dieser Parameter wird automatisch festgelegt, wenn Sie den Trigger im Azure Portal erstellen. |
| name | Der im Code der Funktion verwendete Variablenname, der die Liste der Dokumente mit Änderungen darstellt. |
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit dem zu überwachenden Azure Cosmos DB-Konto hergestellt werden soll. Weitere Informationen finden Sie unter Verbindungen. |
| databaseName | Der Name der Azure Cosmos DB-Datenbank mit dem überwachten Container. |
| containerName | Der Name des überwachten Containers. |
| leaseConnection | (Optional) Der Name einer App-Einstellung oder eines Einstellungscontainers, die bzw. der angibt, wie eine Verbindung mit dem Azure Cosmos DB-Konto hergestellt werden soll, das den Leasecontainer enthält. Wenn nicht festgelegt, wird der Wert connection verwendet. Dieser Parameter wird automatisch festgelegt, wenn die Bindung im Portal erstellt wird. Die Verbindungszeichenfolge für den Leasecontainer muss über Schreibberechtigungen verfügen. |
| leaseDatabaseName | (Optional) Der Name der Datenbank, in der der Container zum Speichern von Leases enthalten ist. Wenn nicht festgelegt, wird der Wert der databaseName-Einstellung verwendet. |
| leaseContainerName | (Optional) Der Name des Containers, der zum Speichern von Leases verwendet wird. Wenn nicht festgelegt, wird der Wert leases verwendet. |
| createLeaseContainerIfNotExists | (Optional) Bei Festlegung auf true wird der Leasecontainer automatisch erstellt, falls er noch nicht vorhanden ist. Der Standardwert ist false. Wenn Sie Microsoft Entra-Identitäten verwenden und den Wert true festlegen, ist das Erstellen von Containern kein zulässiger Vorgang, und Ihre Funktion kann nicht gestartet werden. |
| leasesContainerThroughput | (Optional) Definiert die Anzahl von Anforderungseinheiten, die zugewiesen werden, wenn der Leasecontainer erstellt wird. Diese Einstellung wird nur verwendet, wenn createLeaseContainerIfNotExists auf true festgelegt ist. Dieser Parameter wird automatisch festgelegt, wenn die Bindung im Portal erstellt wird. |
| leaseContainerPrefix | (Optional) Wird diese Option festgelegt, wird der Wert den im Leasecontainer für diese Funktion erstellten Leases als Präfix hinzugefügt. Die Verwendung eines Präfixes ermöglicht die Nutzung des gleichen Leasecontainers durch zwei separate Azure-Funktionen über unterschiedliche Präfixe. |
| feedPollDelay | (Optional:) die Verzögerung (in Millisekunden) zwischen den Abfragen an eine Partition nach neuen Änderungen im Feed, nachdem alle aktuellen Änderungen beseitigt wurden. Der Standardwert beträgt 5.000 Millisekunden (oder fünf Sekunden). |
| leaseAcquireInterval | (Optional) Wenn gesetzt, wird das Intervall in Millisekunden definiert, das eine Aufgabe anstößt, die berechnet, ob Partitionen unter den bekannten Hostinstanzen gleichmäßig verteilt sind. Der Standardwert ist 13000 (13 Sekunden). |
| leaseExpirationInterval | (Optional) Wenn gesetzt, wird das Intervall in Millisekunden definiert, für das die Lease für eine Lease, die eine Partition darstellt, ausgeführt wird. Wenn die Lease innerhalb dieses Intervalls nicht erneuert wird, läuft sie ab, und der Besitz der Partition wechselt zu einer anderen Instanz. Der Standardwert ist 60000 (60 Sekunden). |
| leaseRenewInterval | (Optional) Wenn gesetzt, wird das Erneuerungsintervall in Millisekunden für alle Leases für Partitionen definiert, die aktuell in einer Instanz vorhanden sind. Der Standardwert ist 17000 (17 Sekunden). |
| maxItemsPerInvocation | (Optional:) Diese Eigenschaft legt die Höchstzahl von Elementen fest, die pro Funktionsaufruf empfangen werden können. Wenn Vorgänge im überwachten Container über gespeicherte Prozeduren ausgeführt werden, wird der Transaktionsbereich beim Lesen von Elementen aus dem Änderungsfeed beibehalten. Dadurch kann die Anzahl der empfangenen Elemente höher als der angegebene Wert sein, sodass die von derselben Transaktion geänderten Elemente als Teil eines atomischen Batches zurückgegeben werden. |
| startFromBeginning | (Optional) Durch diese Option wird der Trigger angewiesen, Änderungen beginnend vom Anfang des Änderungsverlaufs des Containers anstatt ab der aktuellen Zeit zu lesen. Das Lesen von Anfang an funktioniert nur beim ersten Start des Triggers. Bei nachfolgenden Ausführungen sind die Prüfpunkte bereits gespeichert. Wenn die Leases bereits erstellt wurden, hat das Festlegen dieser Option auf true keine Auswirkungen. |
| startFromTime | (Optional) Dient zum Abrufen oder Festlegen des Zeitpunkts (Datum und Uhrzeit), ab dem der Lesevorgang für den Änderungsfeed initialisiert werden soll. Als Format wird ISO 8601 mit UTC-Kennzeichner empfohlen (also beispielsweise 2021-02-16T14:19:29Z). Diese Option wird nur zum Festlegen des anfänglichen Triggerzustands verwendet. Sobald der Trigger über einen Leasezustand verfügt, hat das Ändern dieses Werts keine Auswirkungen mehr. |
| preferredLocations | (Optional) Definiert bevorzugte Standorte (Regionen) für georeplizierte Datenbankkonten im Azure Cosmos DB-Dienst. Werte sollten durch Trennzeichen getrennt sein. Beispiel: „USA, Osten,USA, Süden-Mitte,Europa, Norden“. |
Das folgende Beispiel zeigt eine Azure Cosmos DB-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion schreibt Protokollmeldungen, wenn Azure Cosmos DB-Datensätze geändert oder hinzugefügt werden.
Bindungsdaten in der Datei function.json:
{
"type": "cosmosDBTrigger",
"name": "documents",
"direction": "in",
"leaseContainerName": "leases",
"connection": "<connection-app-setting>",
"databaseName": "Tasks",
"containerName": "Items",
"createLeaseContainerIfNotExists": true
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
using System.Collections.Generic;
using Microsoft.Extensions.Logging;
// Customize the model with your own desired properties
public class ToDoItem
{
public string id { get; set; }
public string Description { get; set; }
}
public static void Run(IReadOnlyList<ToDoItem> documents, ILogger log)
{
log.LogInformation("Documents modified " + documents.Count);
log.LogInformation("First document Id " + documents[0].id);
}
Azure Cosmos DB v2-Eingabe
In diesem Abschnitt wird nur die Unterstützung für Version 4.x oder höher der Erweiterung beschrieben.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| type | Muss auf cosmosDB festgelegt sein. |
| direction | Muss auf in festgelegt sein. |
| name | Der im Code der Funktion verwendete Variablenname, der die Liste der Dokumente mit Änderungen darstellt. |
| connection | Der Name einer App-Einstellung oder eines Einstellungscontainers, die bzw. der angibt, wie eine Verbindung mit dem zu überwachenden Azure Cosmos DB-Konto hergestellt werden soll. Weitere Informationen finden Sie unter Verbindungen. |
| databaseName | Der Name der Azure Cosmos DB-Datenbank mit dem überwachten Container. |
| containerName | Der Name des überwachten Containers. |
| partitionKey | Gibt den Wert des Partitionsschlüssels für die Suche an. Kann den Bindungsparameter enthalten. Für Suchvorgänge in partitionierten Containern ist dies erforderlich. |
| id | Die ID des abzurufenden Dokuments. Diese Eigenschaft unterstützt Bindungsausdrücke. Legen Sie nicht die beiden Eigenschaften id und sqlQuery fest. Wenn Sie keine der beiden Eigenschaften festlegen, wird der gesamte Container abgerufen. |
| sqlQuery | Eine SQL-Abfrage in Azure Cosmos DB zum Abrufen mehrerer Dokumente. Die Eigenschaft unterstützt Laufzeitbindungen, wie in diesem Beispiel: SELECT * FROM c where c.departmentId = {departmentId}. Legen Sie nicht die beiden Eigenschaften id und sqlQuery fest. Wenn Sie keine der beiden Eigenschaften festlegen, wird der gesamte Container abgerufen. |
| preferredLocations | (Optional) Definiert bevorzugte Standorte (Regionen) für georeplizierte Datenbankkonten im Azure Cosmos DB-Dienst. Werte sollten durch Trennzeichen getrennt sein. Beispiel: East US,South Central US,North Europe. |
Dieser Abschnitt enthält folgende Beispiele:
- Warteschlangentrigger: Suchen der ID in einer Zeichenfolge
- Warteschlangentrigger: Abrufen mehrerer Dokumente unter Verwendung von „SqlQuery“
- HTTP-Trigger: Suchen der ID in einer Abfragezeichenfolge
- HTTP-Trigger: Suchen der ID in Routendaten
- HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von „SqlQuery“
- HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von „DocumentClient“
Die Beispiele für einen HTTP-Trigger beziehen sich auf einen einfachen ToDoItem-Typ:
namespace CosmosDBSamplesV2
{
public class ToDoItem
{
public string Id { get; set; }
public string Description { get; set; }
}
}
Warteschlangentrigger: Suchen der ID in einer Zeichenfolge
Das folgende Beispiel zeigt eine Azure Cosmos DB-Eingabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion liest ein einzelnes Dokument und aktualisiert den Textwert des Dokuments.
Bindungsdaten in der Datei function.json:
{
"name": "inputDocument",
"type": "cosmosDB",
"databaseName": "MyDatabase",
"collectionName": "MyCollection",
"id" : "{queueTrigger}",
"partitionKey": "{partition key value}",
"connectionStringSetting": "MyAccount_COSMOSDB",
"direction": "in"
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
// Change input document contents using Azure Cosmos DB input binding
public static void Run(string myQueueItem, dynamic inputDocument)
{
inputDocument.text = "This has changed.";
}
Warteschlangentrigger: Abrufen mehrerer Dokumente unter Verwendung von SqlQuery
Das folgende Beispiel zeigt eine Azure Cosmos DB-Eingabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion ruft mehrere von einer SQL-Abfrage angegebene Dokumente mithilfe eines Warteschlangentriggers ab, um die Abfrageparameter anzupassen.
Der Warteschlangentrigger stellt den Parameter departmentId bereit. Die Warteschlangennachricht { "departmentId" : "Finance" } gibt dann alle Datensätze für die Finanzabteilung zurück.
Bindungsdaten in der Datei function.json:
{
"name": "documents",
"type": "cosmosDB",
"direction": "in",
"databaseName": "MyDb",
"collectionName": "MyCollection",
"sqlQuery": "SELECT * from c where c.departmentId = {departmentId}",
"connectionStringSetting": "CosmosDBConnection"
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(QueuePayload myQueueItem, IEnumerable<dynamic> documents)
{
foreach (var doc in documents)
{
// operate on each document
}
}
public class QueuePayload
{
public string departmentId { get; set; }
}
HTTP-Trigger: Suchen der ID in einer Abfragezeichenfolge
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die ein einzelnes Dokument abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst, die eine Abfragezeichenfolge verwendet, um die ID oder den Partitionsschlüsselwert anzugeben, der gesucht werden soll. Anhand dieser ID und dieses Partitionsschlüsselwerts wird ein ToDoItem-Dokument aus der angegebenen Datenbank und Sammlung abgerufen.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "cosmosDB",
"name": "toDoItem",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connectionStringSetting": "CosmosDBConnection",
"direction": "in",
"Id": "{Query.id}",
"PartitionKey" : "{Query.partitionKeyValue}"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
using Microsoft.Extensions.Logging;
public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
if (toDoItem == null)
{
log.LogInformation($"ToDo item not found");
}
else
{
log.LogInformation($"Found ToDo item, Description={toDoItem.Description}");
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Suchen der ID in Routendaten
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die ein einzelnes Dokument abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst, die Routendaten verwendet, um die ID und den Schlüsselwert anzugeben, der gesucht werden soll. Anhand dieser ID und dieses Partitionsschlüsselwerts wird ein ToDoItem-Dokument aus der angegebenen Datenbank und Sammlung abgerufen.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
],
"route":"todoitems/{partitionKeyValue}/{id}"
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "cosmosDB",
"name": "toDoItem",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connectionStringSetting": "CosmosDBConnection",
"direction": "in",
"id": "{id}",
"partitionKey": "{partitionKeyValue}"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
using Microsoft.Extensions.Logging;
public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
if (toDoItem == null)
{
log.LogInformation($"ToDo item not found");
}
else
{
log.LogInformation($"Found ToDo item, Description={toDoItem.Description}");
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von SqlQuery
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die eine Liste von Dokumenten abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst. Die Abfrage wird in der Attributeigenschaft SqlQuery angegeben.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "cosmosDB",
"name": "toDoItems",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connectionStringSetting": "CosmosDBConnection",
"direction": "in",
"sqlQuery": "SELECT top 2 * FROM c order by c._ts desc"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
using Microsoft.Extensions.Logging;
public static HttpResponseMessage Run(HttpRequestMessage req, IEnumerable<ToDoItem> toDoItems, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
foreach (ToDoItem toDoItem in toDoItems)
{
log.LogInformation(toDoItem.Description);
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von DocumentClient
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die eine Liste von Dokumenten abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst. Der Code verwendet eine von der Azure Cosmos DB-Bindung bereitgestellte DocumentClient-Instanz, um eine Liste von Dokumenten zu lesen. Die DocumentClient-Instanz kann auch für Schreibvorgänge verwendet werden.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "cosmosDB",
"name": "client",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connectionStringSetting": "CosmosDBConnection",
"direction": "inout"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.Documents.Client"
using System.Net;
using Microsoft.Azure.Documents.Client;
using Microsoft.Azure.Documents.Linq;
using Microsoft.Extensions.Logging;
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, DocumentClient client, ILogger log)
{
log.LogInformation("C# HTTP trigger function processed a request.");
Uri collectionUri = UriFactory.CreateDocumentCollectionUri("ToDoItems", "Items");
string searchterm = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "searchterm", true) == 0)
.Value;
if (searchterm == null)
{
return req.CreateResponse(HttpStatusCode.NotFound);
}
log.LogInformation($"Searching for word: {searchterm} using Uri: {collectionUri.ToString()}");
IDocumentQuery<ToDoItem> query = client.CreateDocumentQuery<ToDoItem>(collectionUri)
.Where(p => p.Description.Contains(searchterm))
.AsDocumentQuery();
while (query.HasMoreResults)
{
foreach (ToDoItem result in await query.ExecuteNextAsync())
{
log.LogInformation(result.Description);
}
}
return req.CreateResponse(HttpStatusCode.OK);
}
Azure Cosmos DB v2-Ausgabe
In diesem Abschnitt wird nur die Unterstützung für Version 4.x oder höher der Erweiterung beschrieben.
Die folgende Tabelle gibt Aufschluss über die Bindungskonfigurationseigenschaften, die Sie in der Datei function.json festlegen.
| function.json-Eigenschaft | BESCHREIBUNG |
|---|---|
| connection | Der Name einer App-Einstellung oder -Einstellungssammlung, die angibt, wie eine Verbindung mit dem zu überwachenden Azure Cosmos DB-Konto hergestellt werden soll. Weitere Informationen finden Sie unter Verbindungen. |
| databaseName | Der Name der Azure Cosmos DB-Datenbank mit dem überwachten Container. |
| containerName | Der Name des überwachten Containers. |
| createIfNotExists | Ein boolescher Wert, der angibt, ob der Container erstellt wird, wenn er nicht vorhanden ist. Der Standardwert ist FALSE, da neue Container mit reserviertem Durchsatz erstellt werden. Dies wirkt sich auf die Kosten aus. Weitere Informationen hierzu finden Sie in der Preisübersicht. |
| partitionKey | Wenn createIfNotExists den Wert „TRUE“ hat, wird der Partitionsschlüsselpfad für den erstellten Container definiert. Kann den Bindungsparameter enthalten. |
| containerThroughput | Wenn createIfNotExists den Wert „TRUE“ hat, wird der Durchsatz für den erstellten Container definiert. |
| preferredLocations | (Optional) Definiert bevorzugte Standorte (Regionen) für georeplizierte Datenbankkonten im Azure Cosmos DB-Dienst. Werte sollten durch Trennzeichen getrennt sein. Beispiel: East US,South Central US,North Europe. |
Dieser Abschnitt enthält folgende Beispiele:
- Warteschlangentrigger: Schreiben eines einzelnen Dokuments
- Warteschlangentrigger: Schreiben von Dokumenten unter Verwendung von IAsyncCollector
Warteschlangentrigger: Schreiben eines einzelnen Dokuments
Das folgende Beispiel zeigt eine Azure Cosmos DB-Ausgabebindung in einer function.json-Datei sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion verwendet eine Warteschlangeneingabebindung für eine Warteschlange, die JSON-Code im folgenden Format empfängt:
{
"name": "John Henry",
"employeeId": "123456",
"address": "A town nearby"
}
Die Funktion erstellt Azure Cosmos DB-Dokumente im folgenden Format für die einzelnen Datensätze:
{
"id": "John Henry-123456",
"name": "John Henry",
"employeeId": "123456",
"address": "A town nearby"
}
Bindungsdaten in der Datei function.json:
{
"name": "employeeDocument",
"type": "cosmosDB",
"databaseName": "MyDatabase",
"collectionName": "MyCollection",
"createIfNotExists": true,
"connectionStringSetting": "MyAccount_COSMOSDB",
"direction": "out"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Newtonsoft.Json"
using Microsoft.Azure.WebJobs.Host;
using Newtonsoft.Json.Linq;
using Microsoft.Extensions.Logging;
public static void Run(string myQueueItem, out object employeeDocument, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
dynamic employee = JObject.Parse(myQueueItem);
employeeDocument = new {
id = employee.name + "-" + employee.employeeId,
name = employee.name,
employeeId = employee.employeeId,
address = employee.address
};
}
Warteschlangentrigger: Schreiben von Dokumenten unter Verwendung von „IAsyncCollector“
Für das Erstellen mehrerer Dokumente können Sie eine Bindung mit ICollector<T> oder IAsyncCollector<T> erstellen, wobei T einer der unterstützten Typen ist.
Dieses Beispiel bezieht sich auf einen einfachen ToDoItem-Typ:
namespace CosmosDBSamplesV2
{
public class ToDoItem
{
public string id { get; set; }
public string Description { get; set; }
}
}
Die Datei „function.json“ sieht wie folgt aus:
{
"bindings": [
{
"name": "toDoItemsIn",
"type": "queueTrigger",
"direction": "in",
"queueName": "todoqueueforwritemulti",
"connectionStringSetting": "AzureWebJobsStorage"
},
{
"type": "cosmosDB",
"name": "toDoItemsOut",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connectionStringSetting": "CosmosDBConnection",
"direction": "out"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
using Microsoft.Extensions.Logging;
public static async Task Run(ToDoItem[] toDoItemsIn, IAsyncCollector<ToDoItem> toDoItemsOut, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed {toDoItemsIn?.Length} items");
foreach (ToDoItem toDoItem in toDoItemsIn)
{
log.LogInformation($"Description={toDoItem.Description}");
await toDoItemsOut.AddAsync(toDoItem);
}
}
Azure Cosmos DB v1-Trigger
Das folgende Beispiel zeigt eine Azure Cosmos DB-Triggerbindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion schreibt Protokollmeldungen, wenn Azure Cosmos DB-Datensätze geändert werden.
Bindungsdaten in der Datei function.json:
{
"type": "cosmosDBTrigger",
"name": "documents",
"direction": "in",
"leaseCollectionName": "leases",
"connectionStringSetting": "<connection-app-setting>",
"databaseName": "Tasks",
"collectionName": "Items",
"createLeaseCollectionIfNotExists": true
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.Documents.Client"
using System;
using Microsoft.Azure.Documents;
using System.Collections.Generic;
public static void Run(IReadOnlyList<Document> documents, TraceWriter log)
{
log.Info("Documents modified " + documents.Count);
log.Info("First document Id " + documents[0].Id);
}
Azure Cosmos DB v1-Eingabe
Dieser Abschnitt enthält folgende Beispiele:
- Warteschlangentrigger: Suchen der ID in einer Zeichenfolge
- Warteschlangentrigger: Abrufen mehrerer Dokumente unter Verwendung von „SqlQuery“
- HTTP-Trigger: Suchen der ID in einer Abfragezeichenfolge
- HTTP-Trigger: Suchen der ID in Routendaten
- HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von „SqlQuery“
- HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von „DocumentClient“
Die Beispiele für einen HTTP-Trigger beziehen sich auf einen einfachen ToDoItem-Typ:
namespace CosmosDBSamplesV1
{
public class ToDoItem
{
public string Id { get; set; }
public string Description { get; set; }
}
}
Warteschlangentrigger: Suchen der ID in einer Zeichenfolge
Das folgende Beispiel zeigt eine Azure Cosmos DB-Eingabebindung in einer function.json-Datei sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion liest ein einzelnes Dokument und aktualisiert den Textwert des Dokuments.
Bindungsdaten in der Datei function.json:
{
"name": "inputDocument",
"type": "documentDB",
"databaseName": "MyDatabase",
"collectionName": "MyCollection",
"id" : "{queueTrigger}",
"partitionKey": "{partition key value}",
"connection": "MyAccount_COSMOSDB",
"direction": "in"
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
// Change input document contents using Azure Cosmos DB input binding
public static void Run(string myQueueItem, dynamic inputDocument)
{
inputDocument.text = "This has changed.";
}
Warteschlangentrigger: Abrufen mehrerer Dokumente unter Verwendung von SqlQuery
Das folgende Beispiel zeigt eine Azure Cosmos DB-Eingabebindung in einer function.json-Datei sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion ruft mehrere von einer SQL-Abfrage angegebene Dokumente mithilfe eines Warteschlangentriggers ab, um die Abfrageparameter anzupassen.
Der Warteschlangentrigger stellt den Parameter departmentId bereit. Die Warteschlangennachricht { "departmentId" : "Finance" } gibt dann alle Datensätze für die Finanzabteilung zurück.
Bindungsdaten in der Datei function.json:
{
"name": "documents",
"type": "documentdb",
"direction": "in",
"databaseName": "MyDb",
"collectionName": "MyCollection",
"sqlQuery": "SELECT * from c where c.departmentId = {departmentId}",
"connection": "CosmosDBConnection"
}
Der C#-Skriptcode sieht wie folgt aus:
public static void Run(QueuePayload myQueueItem, IEnumerable<dynamic> documents)
{
foreach (var doc in documents)
{
// operate on each document
}
}
public class QueuePayload
{
public string departmentId { get; set; }
}
HTTP-Trigger: Suchen der ID in einer Abfragezeichenfolge
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die ein einzelnes Dokument abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst, die eine Abfragezeichenfolge verwendet, um die zu suchende ID anzugeben. Anhand dieser ID wird ein Dokument vom Typ ToDoItem aus der angegebenen Datenbank und Sammlung abgerufen.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "documentDB",
"name": "toDoItem",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connection": "CosmosDBConnection",
"direction": "in",
"Id": "{Query.id}"
}
],
"disabled": true
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
if (toDoItem == null)
{
log.Info($"ToDo item not found");
}
else
{
log.Info($"Found ToDo item, Description={toDoItem.Description}");
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Suchen der ID in Routendaten
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die ein einzelnes Dokument abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst, die eine Routendaten verwendet, um die zu suchende ID anzugeben. Anhand dieser ID wird ein Dokument vom Typ ToDoItem aus der angegebenen Datenbank und Sammlung abgerufen.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
],
"route":"todoitems/{id}"
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "documentDB",
"name": "toDoItem",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connection": "CosmosDBConnection",
"direction": "in",
"Id": "{id}"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
public static HttpResponseMessage Run(HttpRequestMessage req, ToDoItem toDoItem, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
if (toDoItem == null)
{
log.Info($"ToDo item not found");
}
else
{
log.Info($"Found ToDo item, Description={toDoItem.Description}");
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von SqlQuery
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die eine Liste von Dokumenten abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst. Die Abfrage wird in der Attributeigenschaft SqlQuery angegeben.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "documentDB",
"name": "toDoItems",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connection": "CosmosDBConnection",
"direction": "in",
"sqlQuery": "SELECT top 2 * FROM c order by c._ts desc"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System.Net;
public static HttpResponseMessage Run(HttpRequestMessage req, IEnumerable<ToDoItem> toDoItems, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
foreach (ToDoItem toDoItem in toDoItems)
{
log.Info(toDoItem.Description);
}
return req.CreateResponse(HttpStatusCode.OK);
}
HTTP-Trigger: Abrufen mehrerer Dokumente unter Verwendung von DocumentClient
Das folgende Beispiel zeigt eine C#-Skriptfunktion, die eine Liste von Dokumenten abruft. Die Funktion wird durch eine HTTP-Anforderung ausgelöst. Der Code verwendet eine von der Azure Cosmos DB-Bindung bereitgestellte DocumentClient-Instanz, um eine Liste von Dokumenten zu lesen. Die DocumentClient-Instanz kann auch für Schreibvorgänge verwendet werden.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"authLevel": "anonymous",
"name": "req",
"type": "httpTrigger",
"direction": "in",
"methods": [
"get",
"post"
]
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"type": "documentDB",
"name": "client",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connection": "CosmosDBConnection",
"direction": "inout"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.Documents.Client"
using System.Net;
using Microsoft.Azure.Documents.Client;
using Microsoft.Azure.Documents.Linq;
public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, DocumentClient client, TraceWriter log)
{
log.Info("C# HTTP trigger function processed a request.");
Uri collectionUri = UriFactory.CreateDocumentCollectionUri("ToDoItems", "Items");
string searchterm = req.GetQueryNameValuePairs()
.FirstOrDefault(q => string.Compare(q.Key, "searchterm", true) == 0)
.Value;
if (searchterm == null)
{
return req.CreateResponse(HttpStatusCode.NotFound);
}
log.Info($"Searching for word: {searchterm} using Uri: {collectionUri.ToString()}");
IDocumentQuery<ToDoItem> query = client.CreateDocumentQuery<ToDoItem>(collectionUri)
.Where(p => p.Description.Contains(searchterm))
.AsDocumentQuery();
while (query.HasMoreResults)
{
foreach (ToDoItem result in await query.ExecuteNextAsync())
{
log.Info(result.Description);
}
}
return req.CreateResponse(HttpStatusCode.OK);
}
Azure Cosmos DB v1-Ausgabe
Dieser Abschnitt enthält folgende Beispiele:
- Warteschlangentrigger: Schreiben eines einzelnen Dokuments
- Warteschlangentrigger: Schreiben von Dokumenten mit
IAsyncCollector
Warteschlangentrigger: Schreiben eines einzelnen Dokuments
Das folgende Beispiel zeigt eine Azure Cosmos DB-Ausgabebindung in einer function.json-Datei sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion verwendet eine Warteschlangeneingabebindung für eine Warteschlange, die JSON-Code im folgenden Format empfängt:
{
"name": "John Henry",
"employeeId": "123456",
"address": "A town nearby"
}
Die Funktion erstellt Azure Cosmos DB-Dokumente im folgenden Format für die einzelnen Datensätze:
{
"id": "John Henry-123456",
"name": "John Henry",
"employeeId": "123456",
"address": "A town nearby"
}
Bindungsdaten in der Datei function.json:
{
"name": "employeeDocument",
"type": "documentDB",
"databaseName": "MyDatabase",
"collectionName": "MyCollection",
"createIfNotExists": true,
"connection": "MyAccount_COSMOSDB",
"direction": "out"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Newtonsoft.Json"
using Microsoft.Azure.WebJobs.Host;
using Newtonsoft.Json.Linq;
public static void Run(string myQueueItem, out object employeeDocument, TraceWriter log)
{
log.Info($"C# Queue trigger function processed: {myQueueItem}");
dynamic employee = JObject.Parse(myQueueItem);
employeeDocument = new {
id = employee.name + "-" + employee.employeeId,
name = employee.name,
employeeId = employee.employeeId,
address = employee.address
};
}
Warteschlangentrigger: Schreiben von Dokumenten unter Verwendung von „IAsyncCollector“
Für das Erstellen mehrerer Dokumente können Sie eine Bindung mit ICollector<T> oder IAsyncCollector<T> erstellen, wobei T einer der unterstützten Typen ist.
Dieses Beispiel bezieht sich auf einen einfachen ToDoItem-Typ:
namespace CosmosDBSamplesV1
{
public class ToDoItem
{
public string Id { get; set; }
public string Description { get; set; }
}
}
Die Datei „function.json“ sieht wie folgt aus:
{
"bindings": [
{
"name": "toDoItemsIn",
"type": "queueTrigger",
"direction": "in",
"queueName": "todoqueueforwritemulti",
"connection": "AzureWebJobsStorage"
},
{
"type": "documentDB",
"name": "toDoItemsOut",
"databaseName": "ToDoItems",
"collectionName": "Items",
"connection": "CosmosDBConnection",
"direction": "out"
}
],
"disabled": false
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
public static async Task Run(ToDoItem[] toDoItemsIn, IAsyncCollector<ToDoItem> toDoItemsOut, TraceWriter log)
{
log.Info($"C# Queue trigger function processed {toDoItemsIn?.Length} items");
foreach (ToDoItem toDoItem in toDoItemsIn)
{
log.Info($"Description={toDoItem.Description}");
await toDoItemsOut.AddAsync(toDoItem);
}
}
Azure SQL-Trigger
Weitere Beispiele für den Azure SQL-Trigger sind im GitHub-Repository verfügbar.
Das Beispiel bezieht sich auf eine ToDoItem-Klasse und eine entsprechende Datenbanktabelle:
namespace AzureSQL.ToDo
{
public class ToDoItem
{
public Guid Id { get; set; }
public int? order { get; set; }
public string title { get; set; }
public string url { get; set; }
public bool? completed { get; set; }
}
}
CREATE TABLE dbo.ToDo (
[Id] UNIQUEIDENTIFIER PRIMARY KEY,
[order] INT NULL,
[title] NVARCHAR(200) NOT NULL,
[url] NVARCHAR(200) NOT NULL,
[completed] BIT NOT NULL
);
Änderungsnachverfolgung ist für die Datenbank und die Tabelle aktiviert:
ALTER DATABASE [SampleDatabase]
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
ALTER TABLE [dbo].[ToDo]
ENABLE CHANGE_TRACKING;
Der SQL-Trigger bindet an eine IReadOnlyList<SqlChange<T>>, eine Liste von SqlChange-Objekten mit jeweils zwei Eigenschaften:
- Element: Das Element, das geändert wurde. Der Typ des Elements sollte dem Tabellenschema entsprechen, wie in der
ToDoItem-Klasse zu sehen ist. - Vorgang: Ein Wert aus der
SqlChangeOperation-Enumeration. Die möglichen Werte sindInsert,UpdateundDelete.
Das folgende Beispiel zeigt einen SQL-Trigger in einer Datei „function.json“ und eine C#-Skriptfunktion, die aufgerufen wird, wenn Änderungen an der ToDo-Tabelle vorgenommen werden:
Das folgende Beispiel bindet Daten in der function.json-Datei:
{
"name": "todoChanges",
"type": "sqlTrigger",
"direction": "in",
"tableName": "dbo.ToDo",
"connectionStringSetting": "SqlConnectionString"
}
Im Folgenden finden Sie die C#-Skriptfunktion:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static void Run(IReadOnlyList<SqlChange<ToDoItem>> todoChanges, ILogger log)
{
log.LogInformation($"C# SQL trigger function processed a request.");
foreach (SqlChange<ToDoItem> change in todoChanges)
{
ToDoItem toDoItem = change.Item;
log.LogInformation($"Change operation: {change.Operation}");
log.LogInformation($"Id: {toDoItem.Id}, Title: {toDoItem.title}, Url: {toDoItem.url}, Completed: {toDoItem.completed}");
}
}
Azure SQL-Eingabe
Weitere Beispiele für die Azure SQL-Eingabebindung sind im GitHub-Repository verfügbar.
Dieser Abschnitt enthält folgende Beispiele:
Die Beispiele beziehen sich auf eine ToDoItem-Klasse und eine entsprechende Datenbanktabelle:
namespace AzureSQL.ToDo
{
public class ToDoItem
{
public Guid Id { get; set; }
public int? order { get; set; }
public string title { get; set; }
public string url { get; set; }
public bool? completed { get; set; }
}
}
CREATE TABLE dbo.ToDo (
[Id] UNIQUEIDENTIFIER PRIMARY KEY,
[order] INT NULL,
[title] NVARCHAR(200) NOT NULL,
[url] NVARCHAR(200) NOT NULL,
[completed] BIT NOT NULL
);
HTTP-Trigger, Zeile nach ID aus Abfragezeichenfolge abrufen
Das folgende Beispiel zeigt eine Azure SQL-Eingabebindung in einer function.json-Datei sowie eine C#-Skriptfunktion, welche die Bindung verwendet. Die Funktion wird durch eine HTTP-Anforderung ausgelöst, die eine Abfragezeichenfolge verwendet, um die ID anzugeben. Diese ID wird verwendet, um einen Datensatz ToDoItem mit der angegebenen Abfrage abzurufen.
Hinweis
Beim Wert für den HTTP-Abfragezeichenfolge-Parameter muss die Groß-/Kleinschreibung beachtet werden.
Bindungsdaten in der Datei function.json:
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"get"
]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"name": "todoItem",
"type": "sql",
"direction": "in",
"commandText": "select [Id], [order], [title], [url], [completed] from dbo.ToDo where Id = @Id",
"commandType": "Text",
"parameters": "@Id = {Query.id}",
"connectionStringSetting": "SqlConnectionString"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
using System.Collections.Generic;
public static IActionResult Run(HttpRequest req, ILogger log, IEnumerable<ToDoItem> todoItem)
{
return new OkObjectResult(todoItem);
}
HTTP-Trigger, Zeilen löschen
Das folgende Beispiel zeigt eine Azure SQL-Eingabebindung in einer function.json-Datei und eine C#-Funktion, welche die Bindung verwendet, um eine gespeicherte Prozedur mit einer Eingabe aus dem Abfrageparameter der HTTP-Anforderung auszuführen. In diesem Beispiel löscht die gespeicherte Prozedur einen einzelnen Datensatz oder alle Datensätze abhängig vom Wert des Parameters.
Die gespeicherte Prozedur dbo.DeleteToDo muss in der SQL-Datenbank erstellt werden.
CREATE PROCEDURE [dbo].[DeleteToDo]
@Id NVARCHAR(100)
AS
DECLARE @UID UNIQUEIDENTIFIER = TRY_CAST(@ID AS UNIQUEIDENTIFIER)
IF @UId IS NOT NULL AND @Id != ''
BEGIN
DELETE FROM dbo.ToDo WHERE Id = @UID
END
ELSE
BEGIN
DELETE FROM dbo.ToDo WHERE @ID = ''
END
SELECT [Id], [order], [title], [url], [completed] FROM dbo.ToDo
GO
Bindungsdaten in der Datei function.json:
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"get"
]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"name": "todoItems",
"type": "sql",
"direction": "in",
"commandText": "DeleteToDo",
"commandType": "StoredProcedure",
"parameters": "@Id = {Query.id}",
"connectionStringSetting": "SqlConnectionString"
}
using System;
using System.Collections.Generic;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
namespace AzureSQL.ToDo
{
public static class DeleteToDo
{
// delete all items or a specific item from querystring
// returns remaining items
// uses input binding with a stored procedure DeleteToDo to delete items and return remaining items
[FunctionName("DeleteToDo")]
public static IActionResult Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "delete", Route = "DeleteFunction")] HttpRequest req,
ILogger log,
[Sql(commandText: "DeleteToDo", commandType: System.Data.CommandType.StoredProcedure,
parameters: "@Id={Query.id}", connectionStringSetting: "SqlConnectionString")]
IEnumerable<ToDoItem> toDoItems)
{
return new OkObjectResult(toDoItems);
}
}
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
using System.Collections.Generic;
public static IActionResult Run(HttpRequest req, ILogger log, IEnumerable<ToDoItem> todoItems)
{
return new OkObjectResult(todoItems);
}
Azure SQL-Ausgabe
Weitere Beispiele für die Azure SQL-Ausgabebindung sind im GitHub-Repository verfügbar.
Dieser Abschnitt enthält folgende Beispiele:
Die Beispiele beziehen sich auf eine ToDoItem-Klasse und eine entsprechende Datenbanktabelle:
namespace AzureSQL.ToDo
{
public class ToDoItem
{
public Guid Id { get; set; }
public int? order { get; set; }
public string title { get; set; }
public string url { get; set; }
public bool? completed { get; set; }
}
}
CREATE TABLE dbo.ToDo (
[Id] UNIQUEIDENTIFIER PRIMARY KEY,
[order] INT NULL,
[title] NVARCHAR(200) NOT NULL,
[url] NVARCHAR(200) NOT NULL,
[completed] BIT NOT NULL
);
HTTP-Trigger: Schreiben von Datensätzen in eine Tabelle
Das folgende Beispiel zeigt eine SQL-Ausgabebindung in der Datei „function.json“ und eine C# Script-Funktion, die Datensätze einer Tabelle hinzufügt. Dabei werden in einer HTTP POST-Anforderung bereitgestellte Daten als JSON-Textkörper verwendet.
Das folgende Beispiel bindet Daten in der function.json-Datei:
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"name": "todoItem",
"type": "sql",
"direction": "out",
"commandText": "dbo.ToDo",
"connectionStringSetting": "SqlConnectionString"
}
Im Folgenden finden Sie C# Skript-Beispielcode:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string requestBody = new StreamReader(req.Body).ReadToEnd();
todoItem = JsonConvert.DeserializeObject<ToDoItem>(requestBody);
return new OkObjectResult(todoItem);
}
HTTP-Trigger: Schreiben in zwei Tabellen
Das folgende Beispiel zeigt eine SQL-Ausgabebindung in der Datei „function.json“ und eine C# Script-Funktion, die Datensätze zwei Tabellen (dbo.ToDo und dbo.RequestLog) hinzufügt. Dabei werden in einer HTTP POST-Anforderung bereitgestellte Daten als JSON-Textkörper sowie mehrere Ausgabebindungen verwendet.
Die zweite Tabelle, dbo.RequestLog, entspricht der folgenden Definition:
CREATE TABLE dbo.RequestLog (
Id int identity(1,1) primary key,
RequestTimeStamp datetime2 not null,
ItemCount int not null
)
Das folgende Beispiel bindet Daten in der function.json-Datei:
{
"authLevel": "anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"post"
]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"name": "todoItem",
"type": "sql",
"direction": "out",
"commandText": "dbo.ToDo",
"connectionStringSetting": "SqlConnectionString"
},
{
"name": "requestLog",
"type": "sql",
"direction": "out",
"commandText": "dbo.RequestLog",
"connectionStringSetting": "SqlConnectionString"
}
Im Folgenden finden Sie C# Skript-Beispielcode:
#r "Newtonsoft.Json"
using System.Net;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Primitives;
using Newtonsoft.Json;
public static IActionResult Run(HttpRequest req, ILogger log, out ToDoItem todoItem, out RequestLog requestLog)
{
log.LogInformation("C# HTTP trigger function processed a request.");
string requestBody = new StreamReader(req.Body).ReadToEnd();
todoItem = JsonConvert.DeserializeObject<ToDoItem>(requestBody);
requestLog = new RequestLog();
requestLog.RequestTimeStamp = DateTime.Now;
requestLog.ItemCount = 1;
return new OkObjectResult(todoItem);
}
public class RequestLog {
public DateTime RequestTimeStamp { get; set; }
public int ItemCount { get; set; }
}
RabbitMQ-Ausgabe
Das folgende Beispiel zeigt eine RabbitMQ-Ausgabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion liest in der Nachricht von einem HTTP-Trigger und gibt sie in der RabbitMQ-Warteschlange aus.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"authLevel": "function",
"name": "input",
"methods": [
"get",
"post"
]
},
{
"type": "rabbitMQ",
"name": "outputMessage",
"queueName": "outputQueue",
"connectionStringSetting": "rabbitMQConnectionAppSetting",
"direction": "out"
}
]
}
Der C#-Skriptcode sieht wie folgt aus:
using System;
using Microsoft.Extensions.Logging;
public static void Run(string input, out string outputMessage, ILogger log)
{
log.LogInformation(input);
outputMessage = input;
}
SendGrid-Ausgabe
Das folgende Beispiel zeigt eine SendGrid-Ausgabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet.
Bindungsdaten in der Datei function.json:
{
"bindings": [
{
"type": "queueTrigger",
"name": "mymsg",
"queueName": "myqueue",
"connection": "AzureWebJobsStorage",
"direction": "in"
},
{
"type": "sendGrid",
"name": "$return",
"direction": "out",
"apiKey": "SendGridAPIKeyAsAppSetting",
"from": "{FromEmail}",
"to": "{ToEmail}"
}
]
}
Der C#-Skriptcode sieht wie folgt aus:
#r "SendGrid"
using System;
using SendGrid.Helpers.Mail;
using Microsoft.Azure.WebJobs.Host;
public static SendGridMessage Run(Message mymsg, ILogger log)
{
SendGridMessage message = new SendGridMessage()
{
Subject = $"{mymsg.Subject}"
};
message.AddContent("text/plain", $"{mymsg.Content}");
return message;
}
public class Message
{
public string ToEmail { get; set; }
public string FromEmail { get; set; }
public string Subject { get; set; }
public string Content { get; set; }
}
SignalR-Trigger
Hier sehen Sie exemplarische Bindungsdaten in der Datei function.json:
{
"type": "signalRTrigger",
"name": "invocation",
"hubName": "SignalRTest",
"category": "messages",
"event": "SendMessage",
"parameterNames": [
"message"
],
"direction": "in"
}
Der Code lautet wie folgt:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using System;
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
using Microsoft.Extensions.Logging;
public static void Run(InvocationContext invocation, string message, ILogger logger)
{
logger.LogInformation($"Receive {message} from {invocationContext.ConnectionId}.");
}
SignalR-Eingabe
Das folgende Beispiel zeigt eine SignalR-Verbindungsinformations-Eingabebindung in der Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet, um die Verbindungsinformationen zurückzugeben.
Die Bindungsdaten in der Datei function.json:
Beispiel für „function.json“:
{
"type": "signalRConnectionInfo",
"name": "connectionInfo",
"hubName": "chat",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"direction": "in"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static SignalRConnectionInfo Run(HttpRequest req, SignalRConnectionInfo connectionInfo)
{
return connectionInfo;
}
Sie können die userId-Eigenschaft der Bindung mithilfe eines Bindungsausdrucks auf den Wert eines der beiden Header festlegen: {headers.x-ms-client-principal-id} oder {headers.x-ms-client-principal-name}.
Beispiel für „function.json“:
{
"type": "signalRConnectionInfo",
"name": "connectionInfo",
"hubName": "chat",
"userId": "{headers.x-ms-client-principal-id}",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"direction": "in"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static SignalRConnectionInfo Run(HttpRequest req, SignalRConnectionInfo connectionInfo)
{
// connectionInfo contains an access key token with a name identifier
// claim set to the authenticated user
return connectionInfo;
}
SignalR-Ausgabe
Die Bindungsdaten in der Datei function.json:
Beispiel für „function.json“:
{
"type": "signalR",
"name": "signalRMessages",
"hubName": "<hub_name>",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"direction": "out"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static Task Run(
object message,
IAsyncCollector<SignalRMessage> signalRMessages)
{
return signalRMessages.AddAsync(
new SignalRMessage
{
Target = "newMessage",
Arguments = new [] { message }
});
}
Sie können eine Nachricht ausschließlich an Verbindungen senden, die für einen Benutzer authentifiziert wurden, indem Sie die Benutzer-ID in der SignalR-Nachricht festlegen.
Beispiel für „function.json“:
{
"type": "signalR",
"name": "signalRMessages",
"hubName": "<hub_name>",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"direction": "out"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static Task Run(
object message,
IAsyncCollector<SignalRMessage> signalRMessages)
{
return signalRMessages.AddAsync(
new SignalRMessage
{
// the message will only be sent to this user ID
UserId = "userId1",
Target = "newMessage",
Arguments = new [] { message }
});
}
Sie können eine Nachricht ausschließlich an Verbindungen senden, die einer Gruppe hinzugefügt wurden, indem Sie den Gruppennamen in der SignalR-Nachricht festlegen.
Beispiel für „function.json“:
{
"type": "signalR",
"name": "signalRMessages",
"hubName": "<hub_name>",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"direction": "out"
}
Der C#-Skriptcode sieht wie folgt aus:
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static Task Run(
object message,
IAsyncCollector<SignalRMessage> signalRMessages)
{
return signalRMessages.AddAsync(
new SignalRMessage
{
// the message will be sent to the group with this name
GroupName = "myGroup",
Target = "newMessage",
Arguments = new [] { message }
});
}
SignalR Service ermöglicht den Benutzern das Hinzufügen zu Gruppen. Nachrichten können dann an eine Gruppe gesendet werden. Sie können dieSignalR Ausgabebindung verwenden, um die Gruppenmitgliedschaft eines Benutzers zu verwalten.
Im folgenden Beispiel wird ein Benutzer einer Gruppe hinzugefügt:
Beispiel für function.json
{
"type": "signalR",
"name": "signalRGroupActions",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"hubName": "chat",
"direction": "out"
}
Run.csx
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static Task Run(
HttpRequest req,
ClaimsPrincipal claimsPrincipal,
IAsyncCollector<SignalRGroupAction> signalRGroupActions)
{
var userIdClaim = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier);
return signalRGroupActions.AddAsync(
new SignalRGroupAction
{
UserId = userIdClaim.Value,
GroupName = "myGroup",
Action = GroupAction.Add
});
}
Im folgenden Beispiel wird ein Benutzer aus einer Gruppe entfernt:
Beispiel für function.json
{
"type": "signalR",
"name": "signalRGroupActions",
"connectionStringSetting": "<name of setting containing SignalR Service connection string>",
"hubName": "chat",
"direction": "out"
}
Run.csx
#r "Microsoft.Azure.WebJobs.Extensions.SignalRService"
using Microsoft.Azure.WebJobs.Extensions.SignalRService;
public static Task Run(
HttpRequest req,
ClaimsPrincipal claimsPrincipal,
IAsyncCollector<SignalRGroupAction> signalRGroupActions)
{
var userIdClaim = claimsPrincipal.FindFirst(ClaimTypes.NameIdentifier);
return signalRGroupActions.AddAsync(
new SignalRGroupAction
{
UserId = userIdClaim.Value,
GroupName = "myGroup",
Action = GroupAction.Remove
});
}
Twilio: Ausgabe
Das folgende Beispiel zeigt eine Twilio-Ausgabebindung in einer Datei function.json sowie eine C#-Skriptfunktion, die die Bindung verwendet. Die Funktion verwendet einen out-Parameter, um eine Textnachricht zu senden.
Die Bindungsdaten in der Datei function.json:
Beispiel für „function.json“:
{
"type": "twilioSms",
"name": "message",
"accountSidSetting": "TwilioAccountSid",
"authTokenSetting": "TwilioAuthToken",
"from": "+1425XXXXXXX",
"direction": "out",
"body": "Azure Functions Testing"
}
Der C#-Skriptcode:
#r "Newtonsoft.Json"
#r "Twilio"
#r "Microsoft.Azure.WebJobs.Extensions.Twilio"
using System;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using Microsoft.Azure.WebJobs.Extensions.Twilio;
using Twilio.Rest.Api.V2010.Account;
using Twilio.Types;
public static void Run(string myQueueItem, out CreateMessageOptions message, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
// In this example the queue item is a JSON string representing an order that contains the name of a
// customer and a mobile number to send text updates to.
dynamic order = JsonConvert.DeserializeObject(myQueueItem);
string msg = "Hello " + order.name + ", thank you for your order.";
// You must initialize the CreateMessageOptions variable with the "To" phone number.
message = new CreateMessageOptions(new PhoneNumber("+1704XXXXXXX"));
// A dynamic message can be set instead of the body in the output binding. In this example, we use
// the order information to personalize a text message.
message.Body = msg;
}
Sie können in asynchronem Code keine Ausgabeparameter verwenden. Ein Beispiel für asynchronen C#-Skriptcode:
#r "Newtonsoft.Json"
#r "Twilio"
#r "Microsoft.Azure.WebJobs.Extensions.Twilio"
using System;
using Microsoft.Extensions.Logging;
using Newtonsoft.Json;
using Microsoft.Azure.WebJobs.Extensions.Twilio;
using Twilio.Rest.Api.V2010.Account;
using Twilio.Types;
public static async Task Run(string myQueueItem, IAsyncCollector<CreateMessageOptions> message, ILogger log)
{
log.LogInformation($"C# Queue trigger function processed: {myQueueItem}");
// In this example the queue item is a JSON string representing an order that contains the name of a
// customer and a mobile number to send text updates to.
dynamic order = JsonConvert.DeserializeObject(myQueueItem);
string msg = "Hello " + order.name + ", thank you for your order.";
// You must initialize the CreateMessageOptions variable with the "To" phone number.
CreateMessageOptions smsText = new CreateMessageOptions(new PhoneNumber("+1704XXXXXXX"));
// A dynamic message can be set instead of the body in the output binding. In this example, we use
// the order information to personalize a text message.
smsText.Body = msg;
await message.AddAsync(smsText);
}
Aufwärmtrigger
Das folgende Beispiel zeigt einen Trigger für die Aufwärmphase in einer Datei vom Typ function.json und eine C#-Skriptfunktion, die für jede neue Instanz ausgeführt wird, wenn sie Ihrer App hinzugefügt wird:
Wird für Version 1.x der Functions-Runtime nicht unterstützt.
Die Datei function.json sieht wie folgt aus:
{
"bindings": [
{
"type": "warmupTrigger",
"direction": "in",
"name": "warmupContext"
}
]
}
public static void Run(WarmupContext warmupContext, ILogger log)
{
log.LogInformation("Function App instance is warm.");
}