Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Functions führt Ihren App-Code mithilfe von sprachspezifischen Handlern aus. Diese sprachspezifischen Handler ermöglichen Funktionen standardmäßig die Unterstützung der meisten Schlüsselsprachen . Möglicherweise müssen Sie jedoch Code in einer anderen Sprache oder in einem anderen Paket ausführen.
Benutzerdefinierte Handler sind einfache Webserver, die Ereignisse aus dem Azure Functions-Hostprozess empfangen. Sie können benutzerdefinierte Handler verwenden, um alle Codeprojekte, die HTTP-Grundtypen unterstützen, in Azure Functions bereitzustellen.
Benutzerdefinierte Handler eignen sich am besten für Situationen, in denen Sie Folgendes ausführen möchten:
- Implementieren Sie eine Funktions-App in einer Sprache, die derzeit nicht sofort angeboten wird, z. B. Go oder Rust.
- Implementieren einer Funktions-App in einer derzeit nicht standardmäßig angebotenen Runtime wie Deno
- Stellen Sie einen Server bereit, der mit den standardmäßigen MCP-SDKs in Azure Functions erstellt wurde.
Mit benutzerdefinierten Handlern können Sie alle Trigger sowie Ein- und Ausgabebindungen über Erweiterungspakete verwenden.
Machen Sie sich mit den ersten Schritten mit benutzerdefinierten Azure Functions-Handlern mit Schnellstarts in Go und Rust vertraut.
Übersicht
Die folgende Abbildung zeigt die Beziehung zwischen dem Functions-Host und einem Webserver, der als benutzerdefinierter Handler implementiert ist.
- Jedes Ereignis löst eine Anforderung aus, die an den Functions-Host gesendet wird. Ein Ereignis ist jeder Trigger, den Azure Functions unterstützt.
- Der Functions-Host gibt eine Anforderungsnutzlast an den Webserver aus. Die Nutzlast enthält Trigger- und Eingabebindungsdaten sowie andere Metadaten für die Funktion.
- Der Webserver führt die einzelne Funktion aus und gibt eine Antwortnutzlast an den Functions-Host zurück.
- Der Functions-Host übergibt zur Verarbeitung Daten aus der Antwort an die Ausgabebindungen der Funktion.
Eine als benutzerdefinierter Handler implementierte Azure Functions-App muss die Dateien host.json, local.settings.json und function.json unter Berücksichtigung bestimmter Konventionen konfigurieren.
Bereitstellen von selbst gehosteten MCP-Servern
Mit benutzerdefinierten Handlern können Sie auch MCP-Server hosten, die Sie mithilfe von offiziellen MCP-SDKs in Azure Functions erstellen. Benutzerdefinierte Handler bieten eine einfache und optimierte Oberfläche zum Hosten Ihrer MCP-Server in Azure. Weitere Informationen finden Sie unter Selbst gehosteter Remote-MCP-Server in Azure Functions.
Hinweis
Die Möglichkeit, dass Azure Functions MCP-Server hosten, die Sie mit offiziellen MCP-SDKs erstellen, befindet sich derzeit in der Vorschau.
Anwendungsstruktur
Um einen benutzerdefinierten Handler zu implementieren, benötigt Ihre Anwendung die folgenden Aspekte:
- Eine Datei host.json im Stammverzeichnis Ihrer App.
- Eine Datei namens local.settings.json im Stammverzeichnis Ihrer App.
- Eine Datei function.json für jede Funktion (in einem Ordner, der mit dem Funktionsnamen übereinstimmt).
- Ein Befehl, ein Skript oder eine ausführbare Datei, die einen Webserver ausführt
Die folgende Abbildung zeigt, wie diese Dateien für eine Funktion namens „MyQueueFunction“ und für eine ausführbare Datei eines benutzerdefinierten Handlers (handler.exe) im Dateisystem aussehen
| /MyQueueFunction
| function.json
|
| host.json
| local.settings.json
| handler.exe
Konfiguration
Sie konfigurieren die Anwendung über die dateienhost.json und local.settings.json .
host.json
host.json leitet den Funktionenhost an, an den Anforderungen gesendet werden sollen, indem er auf einen Webserver zeigt, der HTTP-Ereignisse verarbeiten kann.
Definieren Sie einen benutzerdefinierten Handler, indem Sie die host.json Datei mit Details zum Ausführen des Webservers über den customHandler Abschnitt konfigurieren.
{
"version": "2.0",
"customHandler": {
"description": {
"defaultExecutablePath": "handler.exe"
}
}
}
Der Abschnitt customHandler verweist auf ein Ziel (wie durch defaultExecutablePathdefiniert). Das Ausführungsziel kann ein Befehl, eine ausführbare Datei oder eine Datei sein, in der der Webserver implementiert ist.
Verwenden Sie das Array arguments, um Argumente an die ausführbare Datei zu übergeben. Argumente unterstützen die Erweiterung von Umgebungsvariablen (Anwendungseinstellungen) mithilfe %% der Schreibweise.
Mit workingDirectory können Sie außerdem das von der ausführbaren Datei verwendete Arbeitsverzeichnis ändern.
{
"version": "2.0",
"customHandler": {
"description": {
"defaultExecutablePath": "app/handler.exe",
"arguments": [
"--database-connection-string",
"%DATABASE_CONNECTION_STRING%"
],
"workingDirectory": "app"
}
}
}
Bindungsunterstützung
Standardtrigger sind zusammen mit Eingabe- und Ausgabebindungen verfügbar, indem Sie in der Datei host.json auf Erweiterungspakete verweisen.
local.settings.json
local.settings.json definiert Anwendungseinstellungen, die bei lokaler Ausführung der Funktions-App verwendet werden. Da es geheime Schlüssel enthalten kann, schließen Sie local.settings.json aus der Quellcodeverwaltung aus. Verwenden Sie in Azure stattdessen Anwendungseinstellungen.
Legen Sie FUNCTIONS_WORKER_RUNTIME in Custom für benutzerdefinierte Handler auf fest.
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "Custom"
}
}
Funktionsmetadaten
Wenn Sie einen benutzerdefinierten Handler verwenden, sind die function.json Inhalte identisch mit dem, wenn Sie eine Funktion in einem anderen Kontext definieren. Die einzige Anforderung besteht darin, dass Sie function.json Dateien in einem Ordner platzieren müssen, der mit dem Funktionsnamen übereinstimmt.
In der folgenden Instanz von function.json wird eine Funktion konfiguriert, die über einen Warteschlangentrigger und über eine Warteschlangen-Ausgabebindung verfügt. Da sie sich in einem Ordner namens MyQueueFunction befindet, definiert sie eine Funktion namens MyQueueFunction.
MyQueueFunction/function.json
{
"bindings": [
{
"name": "myQueueItem",
"type": "queueTrigger",
"direction": "in",
"queueName": "messages-incoming",
"connection": "AzureWebJobsStorage"
},
{
"name": "$return",
"type": "queue",
"direction": "out",
"queueName": "messages-outgoing",
"connection": "AzureWebJobsStorage"
}
]
}
Anforderungsnutzlast
Wenn der Funktionshost eine Warteschlangennachricht empfängt, sendet er eine HTTP-Postanforderung an den benutzerdefinierten Handler mit einer Nutzlast im Textkörper.
Der folgende Code zeigt eine Beispielanforderungsnutzlast. Die Nutzlast umfasst eine JSON-Struktur mit zwei Elementen: Data und Metadata.
Das Data-Element enthält Schlüssel, die Eingabe- und Triggernamen entsprechen, wie im Bindungsarray in der Datei function.json definiert.
Das Metadata-Element umfasst Metadaten, die aus der Ereignisquelle generiert werden.
{
"Data": {
"myQueueItem": "{ message: \"Message sent\" }"
},
"Metadata": {
"DequeueCount": 1,
"ExpirationTime": "2019-10-16T17:58:31+00:00",
"Id": "800ae4b3-bdd2-4c08-badd-f08e5a34b865",
"InsertionTime": "2019-10-09T17:58:31+00:00",
"NextVisibleTime": "2019-10-09T18:08:32+00:00",
"PopReceipt": "AgAAAAMAAAAAAAAAAgtnj8x+1QE=",
"sys": {
"MethodName": "QueueTrigger",
"UtcNow": "2019-10-09T17:58:32.2205399Z",
"RandGuid": "24ad4c06-24ad-4e5b-8294-3da9714877e9"
}
}
}
Antwortnutzlast
Gemäß der Konvention werden Funktionsantworten als Schlüssel-Wert-Paare formatiert. Unterstützte Schlüssel sind:
|
|
Datentyp | Bemerkungen |
|---|---|---|
Outputs |
Objekt (object) | Enthält Antwortwerte gemäß Definition des bindings-Arrays in function.json.Wenn beispielsweise eine Funktion mit einer Warteschlangenausgabebindung namens "myQueueOutput" konfiguriert ist, enthält sie Outputs einen Schlüssel namens myQueueOutput, den der benutzerdefinierte Handler auf die Nachrichten festlegt, die er an die Warteschlange sendet. |
Logs |
array | Nachrichten, die in den Funktionsaufrufprotokollen angezeigt werden. Bei Ausführung in Azure werden Meldungen in Application Insights angezeigt. |
ReturnValue |
Zeichenfolge | Wird verwendet, um eine Antwort bereitzustellen, wenn eine Ausgabe als $return in der Datei function.json konfiguriert wird. |
Diese Tabelle zeigt ein Beispiel für ein Antwort-Payload.
{
"Outputs": {
"res": {
"body": "Message enqueued"
},
"myQueueOutput": [
"queue message 1",
"queue message 2"
]
},
"Logs": [
"Log message 1",
"Log message 2"
],
"ReturnValue": "{\"hello\":\"world\"}"
}
Beispiele
Sie können benutzerdefinierte Handler in jeder Sprache implementieren, die den Empfang von HTTP-Ereignissen unterstützt. Die folgenden Beispiele zeigen, wie Sie einen benutzerdefinierten Handler mithilfe der Programmiersprache Go implementieren.
Funktion mit Bindungen
Dieses Beispiel zeigt eine Funktion mit dem Namen order , die eine Anforderung mit einer POST Nutzlast akzeptiert, die eine Produktbestellung darstellt. Wenn Sie einen Auftrag an die Funktion senden, wird eine Nachricht im Warteschlangenspeicher erstellt und eine HTTP-Antwort zurückgegeben.
Implementierung
In einem Ordner mit dem Namen order konfiguriert die Datei function.json die durch HTTP ausgelöste Funktion.
order/function.json
{
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": ["post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
},
{
"type": "queue",
"name": "message",
"direction": "out",
"queueName": "orders",
"connection": "AzureWebJobsStorage"
}
]
}
Diese Funktion wird als eine durch HTTP ausgelöste Funktion definiert, die eine HTTP-Antwort zurückgibt und eine Queue Storage-Nachricht ausgibt.
Im Stammverzeichnis der App ist die Datei host.json für die Ausführung einer ausführbaren Datei namens handler.exe (handler für Linux oder macOS) konfiguriert.
{
"version": "2.0",
"customHandler": {
"description": {
"defaultExecutablePath": "handler.exe"
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.*, 5.0.0)"
}
}
Hierbei handelt es sich um die an die Functions-Runtime gesendete HTTP-Anforderung.
POST http://127.0.0.1:7071/api/order HTTP/1.1
Content-Type: application/json
{
"id": 1005,
"quantity": 2,
"color": "black"
}
Die Functions-Laufzeit sendet die folgende HTTP-Anforderung an den benutzerdefinierten Handler:
POST http://127.0.0.1:<FUNCTIONS_CUSTOMHANDLER_PORT>/order HTTP/1.1
Content-Type: application/json
{
"Data": {
"req": {
"Url": "http://localhost:7071/api/order",
"Method": "POST",
"Query": "{}",
"Headers": {
"Content-Type": [
"application/json"
]
},
"Params": {},
"Body": "{\"id\":1005,\"quantity\":2,\"color\":\"black\"}"
}
},
"Metadata": {
}
}
Hinweis
Zur besseren Übersichtlichkeit wurden einige Teile der Nutzlast entfernt.
handler.exe ist das kompilierte Go-Programm für den benutzerdefinierten Handler, das einen Webserver ausführt und auf Funktionsaufrufanforderungen des Functions-Hosts reagiert.
package main
import (
"encoding/json"
"fmt"
"log"
"net/http"
"os"
)
type InvokeRequest struct {
Data map[string]json.RawMessage
Metadata map[string]interface{}
}
type InvokeResponse struct {
Outputs map[string]interface{}
Logs []string
ReturnValue interface{}
}
func orderHandler(w http.ResponseWriter, r *http.Request) {
var invokeRequest InvokeRequest
d := json.NewDecoder(r.Body)
d.Decode(&invokeRequest)
var reqData map[string]interface{}
json.Unmarshal(invokeRequest.Data["req"], &reqData)
outputs := make(map[string]interface{})
outputs["message"] = reqData["Body"]
resData := make(map[string]interface{})
resData["body"] = "Order enqueued"
outputs["res"] = resData
invokeResponse := InvokeResponse{outputs, nil, nil}
responseJson, _ := json.Marshal(invokeResponse)
w.Header().Set("Content-Type", "application/json")
w.Write(responseJson)
}
func main() {
customHandlerPort, exists := os.LookupEnv("FUNCTIONS_CUSTOMHANDLER_PORT")
if !exists {
customHandlerPort = "8080"
}
mux := http.NewServeMux()
mux.HandleFunc("/order", orderHandler)
fmt.Println("Go server Listening on: ", customHandlerPort)
log.Fatal(http.ListenAndServe(":"+customHandlerPort, mux))
}
In diesem Beispiel führt der benutzerdefinierte Handler einen Webserver aus, um HTTP-Ereignisse zu verarbeiten, und wartet über FUNCTIONS_CUSTOMHANDLER_PORT auf Anforderungen.
Obwohl der Funktionshost die ursprüngliche HTTP-Anforderung /api/orderempfängt, ruft er den benutzerdefinierten Handler mithilfe des Funktionsnamens (dessen Ordnername) auf. In diesem Beispiel ist die Funktion am Pfad /order definiert. Der Host sendet dem benutzerdefinierten Handler eine HTTP-Anforderung am Pfad /order.
Wenn Sie POST Anforderungen an diese Funktion senden, sind die Triggerdaten und Funktionsmetadaten über den HTTP-Anforderungskörper verfügbar. Sie können auf den ursprünglichen HTTP-Anforderungstext in der Nutzlast Data.req.Body zugreifen.
Die Antwort der Funktion wird in Form von Schlüssel-Wert-Paaren formatiert. Das Element Outputs enthält dabei einen JSON-Wert, bei dem die Schlüssel den in der Datei function.json definierten Ausgaben entsprechen.
Hier sehen Sie ein Beispiel für eine Nutzlast, die von diesem Handler an den Functions-Host zurückgegeben wird:
{
"Outputs": {
"message": "{\"id\":1005,\"quantity\":2,\"color\":\"black\"}",
"res": {
"body": "Order enqueued"
}
},
"Logs": null,
"ReturnValue": null
}
Wenn Sie das Element message der Ausgabe auf die Bestelldaten aus der Anforderung festlegen, gibt die Funktion diese Bestelldaten an die konfigurierte Warteschlange aus. Der Functions-Host gibt auch die in res konfigurierte HTTP-Antwort an den Aufrufer zurück.
Reine HTTP-Funktion
Für HTTP-ausgelöste Funktionen ohne zusätzliche Bindungen oder Ausgaben möchten Sie möglicherweise, dass der Handler direkt mit der HTTP-Anforderung und -Antwort anstelle der benutzerdefinierten Handleranforderungs- und Antwortnutzlasten arbeitet. Sie können dieses Verhalten in host.json mithilfe der enableProxyingHttpRequest Einstellung konfigurieren, die das Reaktionsstreaming unterstützt.
Wichtig
Der Hauptzweck des Features für benutzerdefinierte Handler besteht darin, Sprachen und Laufzeiten zu aktivieren, die derzeit keine erstklassige Unterstützung für Azure Functions haben. Sie können Webanwendungen zwar mit benutzerdefinierten Handlern ausführen, Aber Azure Functions ist kein Standardmäßiger Reverseproxy. Einige Komponenten der HTTP-Anforderung, z. B. bestimmte Header und Routen, sind möglicherweise eingeschränkt. Ihre Anwendung kann auch einen übermäßigen Kaltstart erleben.
Zur Vermeidung dieser Punkte empfiehlt es sich gegebenenfalls, Ihre Web-Apps in Azure App Service auszuführen.
Im folgenden Beispiel wird veranschaulicht, wie eine durch HTTP ausgelöste Funktion ohne zusätzliche Bindungen oder Ausgaben konfiguriert wird. Das in diesem Beispiel implementierte Szenario enthält eine Funktion namens hello, die eine GET- oder POST-Anforderungen annimmt.
Implementierung
In einem Ordner namens hello konfiguriert die Datei function.json die durch HTTP ausgelöste Funktion.
hello/function.json
{
"bindings": [
{
"type": "httpTrigger",
"authLevel": "anonymous",
"direction": "in",
"name": "req",
"methods": ["get", "post"]
},
{
"type": "http",
"direction": "out",
"name": "res"
}
]
}
Die Funktion ist so konfiguriert, dass sie sowohl als GET auch POST Anforderungen akzeptiert, und der Ergebniswert wird über ein Argument mit dem Namen resbereitgestellt.
Im Stammverzeichnis der App ist die Datei host.json für die Ausführung von handler.exe konfiguriert, und enableProxyingHttpRequest ist auf true festgelegt.
{
"version": "2.0",
"customHandler": {
"description": {
"defaultExecutablePath": "handler.exe"
},
"enableProxyingHttpRequest": true
}
}
Es folgt eine POST-Anforderung an den Functions-Host. Der Functions-Host sendet dann die Anforderung an den benutzerdefinierten Handler.
POST http://127.0.0.1:7071/api/hello HTTP/1.1
Content-Type: application/json
{
"message": "Hello World!"
}
Die Datei "handler.go " implementiert eine Webserver- und HTTP-Funktion.
package main
import (
"fmt"
"io/ioutil"
"log"
"net/http"
"os"
)
func helloHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json")
if r.Method == "GET" {
w.Write([]byte("hello world"))
} else {
body, _ := ioutil.ReadAll(r.Body)
w.Write(body)
}
}
func main() {
customHandlerPort, exists := os.LookupEnv("FUNCTIONS_CUSTOMHANDLER_PORT")
if !exists {
customHandlerPort = "8080"
}
mux := http.NewServeMux()
mux.HandleFunc("/api/hello", helloHandler)
fmt.Println("Go server Listening on: ", customHandlerPort)
log.Fatal(http.ListenAndServe(":"+customHandlerPort, mux))
}
In diesem Beispiel erstellt der benutzerdefinierte Handler einen Webserver zum Verarbeiten von HTTP-Ereignissen und empfängt Anfragen über die FUNCTIONS_CUSTOMHANDLER_PORT.
Zur Behandlung von GET-Anforderungen wird eine Zeichenfolge zurückgegeben, und POST-Anforderungen haben Zugriff auf den Anforderungstext.
Die Route für die Bestellfunktion lautet in diesem Fall /api/hello und ist somit identisch mit der ursprünglichen Anforderung.
Hinweis
Der FUNCTIONS_CUSTOMHANDLER_PORT ist nicht der öffentlich zugängliche Port, der zum Aufrufen der Funktion verwendet wird. Der Functions-Host verwendet diesen Port, um den benutzerdefinierten Handler aufzurufen.
Wird bereitgestellt
Sie können einen benutzerdefinierten Handler für jede Azure Functions-Hostingoption bereitstellen. Wenn ihr Handler Betriebssystem- oder Plattformabhängigkeiten (z. B. eine Sprachlaufzeit) erfordert, müssen Sie möglicherweise einen benutzerdefinierten Container verwenden.
Wenn Sie eine Funktions-App in Azure für benutzerdefinierte Handler erstellen, wählen Sie .NET Core als Stapel aus.
Führen Sie den folgenden Befehl aus, um eine benutzerdefinierte Handler-App mithilfe von Azure Functions Core Tools bereitzustellen.
func azure functionapp publish $functionAppName
Hinweis
Vergewissern Sie sich, dass alle Dateien, die zum Ausführen des benutzerdefinierten Handlers erforderlich sind, im Ordner vorhanden sind und in die Bereitstellung einbezogen werden. Falls Ihr benutzerdefinierter Handler eine ausführbare Binärdatei ist oder plattformspezifische Abhängigkeiten aufweist, stellen Sie sicher, dass diese Dateien der Zielbereitstellungsplattform entsprechen.
Beschränkungen
- Der Webserver des benutzerdefinierten Handlers muss innerhalb von 60 Sekunden starten.
Beispiele
Beispiele zum Implementieren von Funktionen in einer Vielzahl verschiedener Sprachen finden Sie in den benutzerdefinierten Handlerbeispielen für GitHub-Repositorys.
Problembehandlung und Support
Ablaufverfolgungsprotokollierung
Wenn Ihr benutzerdefinierter Handlerprozess nicht gestartet werden kann oder Probleme bei der Kommunikation mit dem Funktionshost auftreten, erhöhen Sie die Protokollebene der Funktions-App auf Trace, um weitere Diagnosemeldungen vom Host zu erhalten.
Konfigurieren Sie zum Ändern des Standardprotokolliergrads der Funktions-App die Einstellung logLevel im Abschnitt logging der Datei host.json.
{
"version": "2.0",
"customHandler": {
"description": {
"defaultExecutablePath": "handler.exe"
}
},
"logging": {
"logLevel": {
"default": "Trace"
}
}
}
Der Funktionenhost gibt zusätzliche Protokollmeldungen aus, einschließlich Informationen im Zusammenhang mit dem benutzerdefinierten Handlerprozess. Verwenden Sie die Protokolle, um Probleme beim Starten Ihres benutzerdefinierten Handlerprozesses oder beim Aufrufen von Funktionen in Ihrem benutzerdefinierten Handler zu untersuchen.
Lokal werden Protokolle in der Konsole ausgegeben.
In Azure können Sie Application Insights-Ablaufverfolgungen abfragen, um die Protokollmeldungen anzuzeigen. Falls von Ihrer App eine große Menge an Protokollen erzeugt wird, wird nur ein Teil der Protokollmeldungen an Application Insights gesendet. Deaktivieren Sie das Sampling, um sicherzustellen, dass alle Meldungen protokolliert werden.
Isoliertes Testen eines benutzerdefinierten Handlers
Benutzerdefinierte Handler-Apps sind Webserverprozesse, daher kann es hilfreich sein, sie selbst zu starten und Funktionsaufrufe zu testen, indem sie simulierte HTTP-Anforderungen senden. Stellen Sie zum Senden von HTTP-Anforderungen mit Nutzlasten sicher, dass Sie ein Tool auswählen, das Ihre Daten schützt. Weitere Informationen finden Sie unter HTTP-Testtools.
Diese Strategie können Sie auch in Ihren CI/CD-Pipelines verwenden, um automatisierte Tests für Ihren benutzerdefinierten Handler durchzuführen.
Ausführungsumgebung
Benutzerdefinierte Handler werden in der gleichen Umgebung ausgeführt wie eine typische Azure Functions-App. Testen Sie Ihren Handler, um sich zu vergewissern, dass die Umgebung alle für die Ausführung erforderlichen Abhängigkeiten enthält. Für Apps, die zusätzliche Abhängigkeiten erfordern, müssen Sie diese möglicherweise mithilfe eines benutzerdefinierten Containerimages ausführen, das im Azure Functions Premium-Plan gehostet wird.
Support
Sollten Sie Hilfe im Zusammenhang mit einer Funktions-App mit benutzerdefinierten Handlern benötigen, können Sie eine Anfrage über die reguläre Supportkanäle stellen. Aufgrund der vielzahl möglicher Sprachen, die zum Erstellen von benutzerdefinierten Handlern-Apps verwendet werden, ist die Unterstützung jedoch nicht unbegrenzt.
Support wird bereitgestellt, wenn der Functions-Host Probleme beim Start oder bei der Kommunikation mit dem benutzerdefinierten Handlerprozess hat. Für Probleme, die speziell für die inneren Arbeiten Ihres benutzerdefinierten Handlerprozesses spezifisch sind, z. B. Probleme mit der ausgewählten Sprache oder dem ausgewählten Framework, kann unser Supportteam in diesem Kontext keine Unterstützung bereitstellen.
Nächste Schritte
Erste Schritte beim Entwickeln einer Azure Functions-App in Go oder Rust mit dem Schnellstart für benutzerdefinierte Handler.