Créer les déclencheurs et liaisons
Un déclencheur définit la façon dont une fonction est appelée. Chaque fonction est associée à un seul déclencheur. Les déclencheurs sont associés à des données, qui sont souvent fournies comme la charge utile de la fonction.
La liaison d’une fonction permet de connecter de façon déclarative une autre ressource à la fonction. Les liaisons peuvent être connectées en tant que liaisons d’entrée, liaisons de sortie, ou les deux. Les données issues des liaisons sont fournies à la fonction en tant que paramètres.
Vous pouvez combiner différentes liaisons selon vos besoins. Les liaisons sont facultatives, et une même fonction peut avoir plusieurs liaisons d’entrée ou de sortie.
Les déclencheurs et les liaisons vous évitent d’avoir à coder en dur l’accès aux autres services. Votre fonction reçoit des données (par exemple, le contenu d’un message de la file d’attente) dans les paramètres de fonction. Vous envoyez des données (par exemple pour créer un message de la file d’attente) en utilisant la valeur de retour de la fonction.
Lorsque vous développez vos fonctions localement, vous devez prendre en compte les comportements de déclenchement et de liaison. Pour les déclencheurs HTTP, vous pouvez appeler le point de terminaison HTTP sur l’ordinateur local, à l’aide de http://localhost/. Pour les fonctions non déclenchées par HTTP, de nombreuses options à exécuter localement existent :
- Le moyen le plus simple de tester des liaisons pendant le développement local consiste à utiliser des chaînes de connexion qui ciblent les services Azure en direct. Vous pouvez cibler les services en direct en ajoutant les paramètres de chaîne de connexion appropriés dans le tableau
Valuesdu fichier local.settings.json. Lorsque vous effectuez cette opération, les exécutions locales pendant les tests utilisent des données de service en direct. Pour cette raison, nous vous conseillons de configurer des services distincts pour le développement et pour les tests, puis de basculer vers d’autres services pendant la production. - Pour les déclencheurs basés sur le stockage, vous pouvez utiliser l’émulateur Azurite local lors du test de fonctions avec des liaisons stockage Azure (Stockage File d’attente, Stockage Blob et Stockage Table), sans avoir à se connecter aux services de stockage distants.
- Vous pouvez exécuter manuellement des fonctions de déclencheur non HTTP au moyen de points de terminaison spéciaux d’administrateur. Pour plus d’informations, consultez Exécuter manuellement une fonction non déclenchée par HTTP.
Définitions de liaisons et de déclencheurs
Les déclencheurs et les liaisons sont définis différemment en fonction du langage de développement et du modèle d’exécution.
| Langage | Configurer des déclencheurs et des liaisons en… |
|---|---|
| Bibliothèque de classes C# | décorant les méthodes et les paramètres avec des attributs C# (mode in-process ou worker isolé) |
| Java | Décoration des méthodes et des paramètres avec des annotations Java |
| JavaScript/TypeScript | Modèle de programmation v4 : définir des entrées/sorties dans le code à l’aide de @azure/functions ; v3 : configurer chaque fonction dans un fichier function.json |
| Python | Modèle de programmation v2 : définir des entrées/sorties avec des décorateurs ; v1 : configurer dans function.json |
| PowerShell | configurer dans function.json |
Note
Dans les modèles modernes (Node.js v4 et Python v2), vous créez une configuration de déclencheur et de liaison dans le code et le runtime génère la function.jsoncorrespondante. Les anciens modèles (Node.js v3, Python v1, PowerShell) utilisent function.json directement. Vous ne pouvez pas combiner de modèles de programmation dans la même application de fonction.
Pour les langages qui s’appuient sur function.json (par exemple, Node.js v3, Python v1 et PowerShell), le portail fournit une interface utilisateur permettant d’ajouter des liaisons dans l’onglet Intégration . Vous pouvez également modifier le fichier directement dans le portail dans l’onglet Code + test de votre fonction. Pour les modèles code-first comme Node.js v4 et Python v2, configurez les liaisons dans le code de votre projet local ; le portail reflète la configuration, mais peut ne pas prendre en charge les modifications directes.
Dans .NET et Java, le type de paramètre définit le type des données d’entrée. Par exemple, utilisez string pour établir une liaison au texte d’un déclencheur de file d’attente, un tableau d’octets à lire au format binaire et un type personnalisé pour désérialiser vers un objet. Dans la mesure où les fonctions des bibliothèques de classes .NET et les fonctions Java ne s’appuient pas sur function.json pour les définitions de liaison, elles ne peuvent pas être créées et modifiées dans le portail. La modification de code C# dans le portail est basée sur un script C#, qui utilise function.json au lieu d’utiliser des attributs.
Pour les langages typés dynamiquement, tels que JavaScript (à l’aide du modèle v3) ou PowerShell, utilisez la dataType propriété dans le fichier function.json . Par exemple, pour lire le contenu d’une requête HTTP au format binaire, définissez dataType sur binary :
{
"dataType": "binary",
"type": "httpTrigger",
"name": "req",
"direction": "in"
}
Les autres options pour dataType sont stream et string.
Sens de la liaison
Tous les déclencheurs et liaisons ont une propriété Direction dans le fichier function.json :
- Pour les déclencheurs, le sens est toujours
in - Les liaisons d’entrée et de sortie utilisent
inetout - Certaines liaisons prennent en charge un sens spécial
inout. Si vous utilisezinout, seule l’option Éditeur avancé est disponible sous l’onglet Intégrer du portail.
Lorsque vous utilisez des attributs dans une bibliothèque de classes pour configurer des déclencheurs et des liaisons, la direction est fournie dans un constructeur d’attribut ou déduite du type du paramètre.
Exemples de déclencheurs et de liaisons des fonctions Azure
Si vous souhaitez écrire un message dans Azure Queue Storage chaque fois qu'une requête HTTP est reçue. Vous pouvez implémenter cela avec un déclencheur HTTP et une liaison de sortie vers une file d’attente de stockage. L’approche de configuration dépend de votre langage et de votre modèle de programmation.
Voici un fichier function.json hérité pour ce scénario (applicable à Node.js v3, Python v1 ou PowerShell).
{
"disabled": false,
"bindings": [
{
"type": "httpTrigger",
"direction": "in",
"name": "req",
"authLevel": "function",
"methods": ["get","post"]
},
{
"type": "queue",
"direction": "out",
"name": "outqueue",
"queueName": "outqueue",
"connection": "AzureWebJobsStorage"
}
]
}
Le premier élément du bindings tableau est le déclencheur HTTP. Les propriétés type et direction identifient le déclencheur. La name propriété identifie le paramètre de fonction qui reçoit la requête HTTP et methods répertorie les verbes HTTP pris en charge.
Le deuxième élément du tableau bindings est la liaison de sortie vers une file d’attente de stockage. Les propriétés type et direction identifient la liaison. La name propriété spécifie comment la fonction fournit le nouveau message de file d’attente, identifie queueName la file d’attente et connection fait référence au paramètre d’application qui contient la chaîne de connexion de stockage.
Note
La désactivation d’une fonction via la disabled propriété dans function.json est un comportement hérité. Préférez utiliser le paramètre AzureWebJobs.<FunctionName>.Disabled=trued’application .
Exemple C# (travailleur isolé)
Cet exemple montre une fonction déclenchée par HTTP qui écrit un message dans une file d’attente de stockage à l’aide d’une liaison de sortie définie par des attributs. Pour plus d’informations, consultez le guide du worker isolé C#.
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Http;
public static class HttpToQueue
{
[Function("HttpToQueue")]
public static MultiResponse Run(
[HttpTrigger(AuthorizationLevel.Function, "get", "post")] HttpRequestData req)
{
var message = "Processed request";
return new MultiResponse
{
Messages = new[] { message },
HttpResponse = req.CreateResponse(System.Net.HttpStatusCode.OK)
};
}
}
public class MultiResponse
{
[QueueOutput("outqueue", Connection = "AzureWebJobsStorage")]
public string[] Messages { get; set; }
public HttpResponseData HttpResponse { get; set; }
}
exemple de Node.js (modèle de programmation v4)
Dans le modèle de programmation v4 Node.js, vous configurez les entrées et les sorties dans le code à l'aide de @azure/functions. Pour plus d’informations, consultez Node.js guide du développeur (v4).
import { app, output } from "@azure/functions";
const queueOutput = output.storageQueue({
queueName: "outqueue",
connection: "AzureWebJobsStorage"
});
app.http("HttpToQueue", {
methods: ["GET", "POST"],
authLevel: "function",
extraOutputs: [queueOutput],
handler: async (request, context) => {
const body = await request.text();
context.extraOutputs.set(queueOutput, body || "Processed request");
return { status: 200, body: "Queued" };
}
});
Exemple python (modèle de programmation v2)
Dans le modèle de programmation Python v2, vous utilisez des décorateurs pour définir des liaisons. Le runtime génère function.json pour vous. Pour plus d’informations, consultez le guide du développeur Python .
import azure.functions as func
app = func.FunctionApp()
@app.route(route="HttpToQueue", auth_level=func.AuthLevel.FUNCTION)
@app.queue_output(arg_name="msg", queue_name="outqueue", connection="AzureWebJobsStorage")
def HttpToQueue(req: func.HttpRequest, msg: func.Out[str]) -> func.HttpResponse:
body = req.get_body().decode("utf-8") if req.get_body() else "Processed request"
msg.set(body)
return func.HttpResponse("Queued", status_code=200)
Note
Dans Node.js v4 et Python v2, le runtime génère function.json à partir de votre code. Évitez de modifier function.json directement dans le portail pour ces modèles ; apportez des modifications dans le code et republiez.