Liaisons de sortie Azure Data Explorer pour Azure Functions (préversion)
Lorsqu’une fonction s’exécute, la liaison de sortie Azure Data Explorer ingère des données dans Azure Data Explorer.
Pour plus d’informations sur les détails d’installation et de configuration, consultez la vue d’ensemble.
Exemples
Une fonction C# peut être créée à l’aide de l’un des modes C# suivants :
- Modèle worker isolé : fonction C# compilée exécutée dans un processus worker isolé du runtime. Le processus Worker isolé est requis pour prendre en charge les fonctions C# exécutées sur les versions LTS et non-LTS de .NET et de .NET Framework.
- Modèle In-process : fonction C# compilée exécutée dans le même processus que le runtime Functions.
- Script C# : principalement utilisé lors de la création de fonctions C# dans le portail Azure.
Important
La prise en charge du modèle in-process prendra fin le 10 novembre 2026. Pour continuer à bénéficier d’une prise en charge complète, nous vous recommandons vivement de migrer vos applications vers le modèle Worker isolé.
D’autres exemples pour la liaison de sortie Azure Data Explorer sont disponibles dans le référentiel GitHub.
Cette section contient les exemples suivants :
- Déclencheur HTTP, écriture d’un enregistrement
- Déclencheur HTTP, écriture d’enregistrements avec mappage
Les exemples font référence à une classe Product
et à une table de base de données correspondante :
public class Product
{
[JsonProperty(nameof(ProductID))]
public long ProductID { get; set; }
[JsonProperty(nameof(Name))]
public string Name { get; set; }
[JsonProperty(nameof(Cost))]
public double Cost { get; set; }
}
.create-merge table Products (ProductID:long, Name:string, Cost:double)
Déclencheur HTTP, écriture d’un enregistrement
L’exemple suivant illustre une fonction C# qui ajoute un enregistrement à une base de données. La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON.
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Extensions.Kusto;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Azure.WebJobs.Extensions.Kusto.SamplesOutOfProc.OutputBindingSamples.Common;
namespace Microsoft.Azure.WebJobs.Extensions.Kusto.SamplesOutOfProc.OutputBindingSamples
{
public static class AddProduct
{
[Function("AddProduct")]
[KustoOutput(Database: "productsdb", Connection = "KustoConnectionString", TableName = "Products")]
public static async Task<Product> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "addproductuni")]
HttpRequestData req)
{
Product? prod = await req.ReadFromJsonAsync<Product>();
return prod ?? new Product { };
}
}
}
Déclencheur HTTP, écriture d’enregistrements avec mappage
L’exemple suivant illustre une fonction C# qui ajoute une collection d’enregistrements à une base de données. La fonction utilise un mappage qui transforme un Product
en Item
.
Pour transformer des données de Product
en Item
, la fonction utilise une référence de mappage :
.create-merge table Item (ItemID:long, ItemName:string, ItemCost:float)
-- Create a mapping that transforms an Item to a Product
.create-or-alter table Product ingestion json mapping "item_to_product_json" '[{"column":"ProductID","path":"$.ItemID"},{"column":"Name","path":"$.ItemName"},{"column":"Cost","path":"$.ItemCost"}]'
namespace Microsoft.Azure.WebJobs.Extensions.Kusto.SamplesOutOfProc.OutputBindingSamples.Common
{
public class Item
{
public long ItemID { get; set; }
public string? ItemName { get; set; }
public double ItemCost { get; set; }
}
}
using Microsoft.Azure.Functions.Worker;
using Microsoft.Azure.Functions.Worker.Extensions.Kusto;
using Microsoft.Azure.Functions.Worker.Http;
using Microsoft.Azure.WebJobs.Extensions.Kusto.SamplesOutOfProc.OutputBindingSamples.Common;
namespace Microsoft.Azure.WebJobs.Extensions.Kusto.SamplesOutOfProc.OutputBindingSamples
{
public static class AddProductsWithMapping
{
[Function("AddProductsWithMapping")]
[KustoOutput(Database: "productsdb", Connection = "KustoConnectionString", TableName = "Products", MappingRef = "item_to_product_json")]
public static async Task<Item> Run(
[HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "addproductswithmapping")]
HttpRequestData req)
{
Item? item = await req.ReadFromJsonAsync<Item>();
return item ?? new Item { };
}
}
}
D’autres exemples pour la liaison d’entrée Azure Data Explorer Java sont disponibles dans le référentiel GitHub.
Cette section contient les exemples suivants :
- Déclencheur HTTP, écrire un enregistrement dans une table
- Déclencheur HTTP, écriture dans deux tables
Les exemples font référence à une classe Products
(dans un fichier distinct Product.java
) et à une table de base de données correspondante Products
(définie plus tôt) :
package com.microsoft.azure.kusto.common;
import com.fasterxml.jackson.annotation.JsonProperty;
public class Product {
@JsonProperty("ProductID")
public long ProductID;
@JsonProperty("Name")
public String Name;
@JsonProperty("Cost")
public double Cost;
public Product() {
}
public Product(long ProductID, String name, double Cost) {
this.ProductID = ProductID;
this.Name = name;
this.Cost = Cost;
}
}
Déclencheur HTTP, écrire un enregistrement dans une table
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans une fonction Java qui ajoute un enregistrement de produit dans une table. La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON. La fonction prend une dépendance supplémentaire envers la bibliothèque com.fasterxml.jackson.core pour analyser le corps JSON.
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.13.4.1</version>
</dependency>
package com.microsoft.azure.kusto.outputbindings;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.microsoft.azure.functions.HttpMethod;
import com.microsoft.azure.functions.HttpRequestMessage;
import com.microsoft.azure.functions.HttpResponseMessage;
import com.microsoft.azure.functions.HttpStatus;
import com.microsoft.azure.functions.OutputBinding;
import com.microsoft.azure.functions.annotation.AuthorizationLevel;
import com.microsoft.azure.functions.annotation.FunctionName;
import com.microsoft.azure.functions.annotation.HttpTrigger;
import com.microsoft.azure.functions.kusto.annotation.KustoOutput;
import com.microsoft.azure.kusto.common.Product;
import java.io.IOException;
import java.util.Optional;
import static com.microsoft.azure.kusto.common.Constants.*;
public class AddProduct {
@FunctionName("AddProduct")
public HttpResponseMessage run(@HttpTrigger(name = "req", methods = {
HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS, route = "addproductuni") HttpRequestMessage<Optional<String>> request,
@KustoOutput(name = "product", database = "productsdb", tableName = "Products", connection = KUSTOCONNSTR) OutputBinding<Product> product)
throws IOException {
if (request.getBody().isPresent()) {
String json = request.getBody().get();
ObjectMapper mapper = new ObjectMapper();
Product p = mapper.readValue(json, Product.class);
product.setValue(p);
return request.createResponseBuilder(HttpStatus.OK).header("Content-Type", "application/json").body(product)
.build();
} else {
return request.createResponseBuilder(HttpStatus.NO_CONTENT).header("Content-Type", "application/json")
.build();
}
}
}
Déclencheur HTTP, écriture dans deux tables
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans une fonction Java qui ajoute des enregistrements dans deux tables différentes (Product
et ProductChangeLog
). La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON et de multiples liaisons de sortie. La fonction prend une dépendance supplémentaire envers la bibliothèque com.fasterxml.jackson.core pour analyser le corps JSON.
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.13.4.1</version>
</dependency>
La seconde table, ProductsChangeLog
, correspond à la définition suivante :
.create-merge table ProductsChangeLog (ProductID:long, CreatedAt:datetime)
et la classe Java dans ProductsChangeLog.java
:
package com.microsoft.azure.kusto.common;
import com.fasterxml.jackson.annotation.JsonProperty;
public class ProductsChangeLog {
@JsonProperty("ProductID")
public long ProductID;
@JsonProperty("CreatedAt")
public String CreatedAt;
public ProductsChangeLog() {
}
public ProductsChangeLog(long ProductID, String CreatedAt) {
this.ProductID = ProductID;
this.CreatedAt = CreatedAt;
}
}
package com.microsoft.azure.kusto.outputbindings;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.microsoft.azure.functions.HttpMethod;
import com.microsoft.azure.functions.HttpRequestMessage;
import com.microsoft.azure.functions.HttpResponseMessage;
import com.microsoft.azure.functions.HttpStatus;
import com.microsoft.azure.functions.OutputBinding;
import com.microsoft.azure.functions.annotation.AuthorizationLevel;
import com.microsoft.azure.functions.annotation.FunctionName;
import com.microsoft.azure.functions.annotation.HttpTrigger;
import com.microsoft.azure.functions.kusto.annotation.KustoOutput;
import com.microsoft.azure.kusto.common.Product;
import com.microsoft.azure.kusto.common.ProductsChangeLog;
import static com.microsoft.azure.kusto.common.Constants.*;
import java.io.IOException;
import java.time.Clock;
import java.time.Instant;
import java.util.Optional;
public class AddMultiTable {
@FunctionName("AddMultiTable")
public HttpResponseMessage run(@HttpTrigger(name = "req", methods = {
HttpMethod.POST}, authLevel = AuthorizationLevel.ANONYMOUS, route = "addmultitable") HttpRequestMessage<Optional<String>> request,
@KustoOutput(name = "product", database = "productsdb", tableName = "Products", connection = KUSTOCONNSTR) OutputBinding<Product> product,
@KustoOutput(name = "productChangeLog", database = "productsdb", tableName = "ProductsChangeLog",
connection = KUSTOCONNSTR) OutputBinding<ProductsChangeLog> productChangeLog)
throws IOException {
if (request.getBody().isPresent()) {
String json = request.getBody().get();
ObjectMapper mapper = new ObjectMapper();
Product p = mapper.readValue(json, Product.class);
product.setValue(p);
productChangeLog.setValue(new ProductsChangeLog(p.ProductID, Instant.now(Clock.systemUTC()).toString()));
return request.createResponseBuilder(HttpStatus.OK).header("Content-Type", "application/json").body(product)
.build();
} else {
return request.createResponseBuilder(HttpStatus.NO_CONTENT).header("Content-Type", "application/json")
.build();
}
}
}
D’autres exemples pour la liaison de sortie Azure Data Explorer sont disponibles dans le référentiel GitHub.
Cette section contient les exemples suivants :
- Déclencheur HTTP, écriture d’enregistrements dans une table
- Déclencheur HTTP, écriture dans deux tables
Les exemples font référence à une table de base de données.
Les exemples font référence aux tables Products
et ProductsChangeLog
(définies précédemment).
Déclencheur HTTP, écriture d’enregistrements dans une table
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans un fichier function.json et une fonction JavaScript qui ajoute des enregistrements à une table. La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON.
L’exemple suivant montre une liaison de données dans le fichier function.json :
{
"bindings": [
{
"authLevel": "function",
"name": "req",
"direction": "in",
"type": "httpTrigger",
"methods": [
"post"
],
"route": "addproduct"
},
{
"name": "$return",
"type": "http",
"direction": "out"
},
{
"name": "product",
"type": "kusto",
"database": "productsdb",
"direction": "out",
"tableName": "Products",
"connection": "KustoConnectionString"
}
],
"disabled": false
}
La section configuration décrit ces propriétés.
L’extrait suivant contient un exemple de code JavaScript :
// Insert the product, which will insert it into the Products table.
module.exports = async function (context, req) {
// Note that this expects the body to be a JSON object or array of objects which have a property
// matching each of the columns in the table to insert to.
context.bindings.product = req.body;
return {
status: 201,
body: req.body
};
}
Déclencheur HTTP, écriture dans deux tables
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans un fichier function.json et une fonction JavaScript qui ajoute des enregistrements à deux tables différentes (Products
et ProductsChangeLog
). La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON et de multiples liaisons de sortie.
La seconde table, ProductsChangeLog
, correspond à la définition suivante :
.create-merge table ProductsChangeLog (ProductID:long, CreatedAt:datetime)
L’exemple suivant montre une liaison de données dans le fichier function.json :
{
"bindings": [
{
"authLevel": "function",
"name": "req",
"direction": "in",
"type": "httpTrigger",
"methods": [
"post"
],
"route": "addmultitable"
},
{
"name": "res",
"type": "http",
"direction": "out"
},
{
"name": "product",
"type": "kusto",
"database": "productsdb",
"direction": "out",
"tableName": "Products",
"connection": "KustoConnectionString"
},
{
"name": "productchangelog",
"type": "kusto",
"database": "productsdb",
"direction": "out",
"tableName": "ProductsChangeLog",
"connection": "KustoConnectionString"
}
],
"disabled": false
}
La section configuration décrit ces propriétés.
L’extrait suivant contient un exemple de code JavaScript :
module.exports = async function (context, req) {
context.log('JavaScript HTTP trigger and Kusto output binding function processed a request.');
context.log(req.body);
if (req.body) {
var changeLog = {ProductID:req.body.ProductID, CreatedAt: new Date().toISOString()};
context.bindings.product = req.body;
context.bindings.productchangelog = changeLog;
context.res = {
body: req.body,
mimetype: "application/json",
status: 201
}
} else {
context.res = {
status: 400,
body: "Error reading request body"
}
}
}
D’autres exemples pour la liaison de sortie Azure Data Explorer sont disponibles dans le référentiel GitHub.
Cette section contient les exemples suivants :
- Déclencheur HTTP, écriture d’enregistrements dans une table
- Déclencheur HTTP, écriture dans deux tables
Les exemples font référence aux tables Products
et ProductsChangeLog
(définies précédemment).
Déclencheur HTTP, écriture d’enregistrements dans une table
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans un fichier function.json et une fonction Python qui ajoute des enregistrements à une table. La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON.
L’exemple suivant montre une liaison de données dans le fichier function.json :
{
"scriptFile": "__init__.py",
"bindings": [
{
"authLevel": "Anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"post"
],
"route": "addproductuni"
},
{
"type": "http",
"direction": "out",
"name": "$return"
},
{
"name": "product",
"type": "kusto",
"database": "sdktestsdb",
"direction": "out",
"tableName": "Products",
"connection": "KustoConnectionString"
}
]
}
La section configuration décrit ces propriétés.
L’extrait suivant contient un exemple de code Python :
import azure.functions as func
from Common.product import Product
def main(req: func.HttpRequest, product: func.Out[str]) -> func.HttpResponse:
body = str(req.get_body(),'UTF-8')
product.set(body)
return func.HttpResponse(
body=body,
status_code=201,
mimetype="application/json"
)
Déclencheur HTTP, écriture dans deux tables
L’exemple suivant montre une liaison de sortie Azure Data Explorer dans un fichier function.json et une fonction JavaScript qui ajoute des enregistrements à deux tables différentes (Products
et ProductsChangeLog
). La fonction utilise des données fournit dans une requête HTTP POST en tant que corps JSON et de multiples liaisons de sortie. La seconde table, ProductsChangeLog
, correspond à la définition suivante :
.create-merge table ProductsChangeLog (ProductID:long, CreatedAt:datetime)
L’exemple suivant montre une liaison de données dans le fichier function.json :
{
"scriptFile": "__init__.py",
"bindings": [
{
"authLevel": "Anonymous",
"type": "httpTrigger",
"direction": "in",
"name": "req",
"methods": [
"post"
],
"route": "addmultitable"
},
{
"type": "http",
"direction": "out",
"name": "$return"
},
{
"name": "product",
"type": "kusto",
"database": "sdktestsdb",
"direction": "out",
"tableName": "Products",
"connection": "KustoConnectionString"
},
{
"name": "productchangelog",
"type": "kusto",
"database": "sdktestsdb",
"direction": "out",
"tableName": "ProductsChangeLog",
"connection": "KustoConnectionString"
}
]
}
La section configuration décrit ces propriétés.
L’extrait suivant contient un exemple de code Python :
import json
from datetime import datetime
import azure.functions as func
from Common.product import Product
def main(req: func.HttpRequest, product: func.Out[str],productchangelog: func.Out[str]) -> func.HttpResponse:
body = str(req.get_body(),'UTF-8')
# parse x:
product.set(body)
id = json.loads(body)["ProductID"]
changelog = {
"ProductID": id,
"CreatedAt": datetime.now().isoformat(),
}
productchangelog.set(json.dumps(changelog))
return func.HttpResponse(
body=body,
status_code=201,
mimetype="application/json"
)
Attributs
La bibliothèque C# utilise l’attribut KustoAttribute pour déclarer les liaisons Azure Data Explorer sur la fonction, qui a les propriétés suivantes.
Propriété d’attribut | Description |
---|---|
Base de données | Obligatoire. La base de données sur laquelle la requête doit être exécutée. |
Connexion | Obligatoire. Le nom de la variable qui contient la chaîne de connexion, résolu par le biais de variables d’environnement ou de paramètres d’application de fonction. Par défaut, la recherche sur la variable KustoConnectionString est effectuée. Au moment de l’exécution, cette variable est recherchée par rapport à l’environnement. La documentation sur la chaîne de connexion se trouve dans Chaînes de connexion Kusto. Par exemple : "KustoConnectionString": "Data Source=https://your_cluster.kusto.windows.net;Database=your_Database;Fed=True;AppClientId=your_AppId;AppKey=your_AppKey;Authority Id=your_TenantId . |
TableName | Obligatoire. Table dans laquelle ingérer les données. |
-mappingRef | facultatif. Attribut pour passer une référence de mappage déjà définie dans le cluster. |
ManagedServiceIdentity | facultatif. Une identité managée peut être utilisée pour se connecter à Azure Data Explorer. Pour utiliser une identité managée par le système, utilisez « system ». Tous les autres noms d’identité sont interprétés comme une identité managée par l’utilisateur. |
DataFormat | facultatif. Le format de données par défaut est multijson/json . Il peut être défini sur les formats texte pris en charge dansdatasource l’énumération de formats. Les exemples sont validés et fournis pour les formats CSV et JSON. |
Annotations
La bibliothèque du runtime de fonctions Java utilise l’annotation @KustoInput
(com.microsoft.azure.functions.kusto.annotation.KustoOutput
).
Élément | Description |
---|---|
name | Obligatoire. Nom de la variable qui représente les résultats de la requête dans le code de la fonction. |
database | Obligatoire. La base de données sur laquelle la requête doit être exécutée. |
connection | Obligatoire. Le nom de la variable qui contient la chaîne de connexion, résolu par le biais de variables d’environnement ou de paramètres d’application de fonction. Par défaut, la recherche sur la variable KustoConnectionString est effectuée. Au moment de l’exécution, cette variable est recherchée par rapport à l’environnement. La documentation sur la chaîne de connexion se trouve dans Chaînes de connexion Kusto. Par exemple : "KustoConnectionString": "Data Source=https://your_cluster.kusto.windows.net;Database=your_Database;Fed=True;AppClientId=your_AppId;AppKey=your_AppKey;Authority Id=your_TenantId . |
tableName | Obligatoire. Table dans laquelle ingérer les données. |
mappingRef | facultatif. Attribut pour passer une référence de mappage déjà définie dans le cluster. |
dataFormat | facultatif. Le format de données par défaut est multijson/json . Il peut être défini sur les formats texte pris en charge dansdatasource l’énumération de formats. Les exemples sont validés et fournis pour les formats CSV et JSON. |
managedServiceIdentity | Une identité managée peut être utilisée pour se connecter à Azure Data Explorer. Pour utiliser une identité managée par le système, utilisez « system ». Tous les autres noms d’identité sont interprétés comme une identité managée par l’utilisateur. |
Configuration
Le tableau suivant décrit les propriétés de configuration de liaison que vous définissez dans le fichier function.json.
Propriété function.json | Description |
---|---|
type | Obligatoire. Cette propriété doit être définie sur kusto . |
direction | Obligatoire. Cette propriété doit être définie sur out . |
name | Obligatoire. Nom de la variable qui représente les résultats de la requête dans le code de la fonction. |
database | Obligatoire. La base de données sur laquelle la requête doit être exécutée. |
connection | Obligatoire. Nom de la variable qui contient la chaîne de connexion, résolu par le biais de variables d’environnement ou de paramètres d’application de fonction. Par défaut, la recherche sur la variable KustoConnectionString est effectuée. Au moment de l’exécution, cette variable est recherchée par rapport à l’environnement. La documentation sur la chaîne de connexion se trouve dans Chaînes de connexion Kusto. Par exemple : "KustoConnectionString": "Data Source=https://your_cluster.kusto.windows.net;Database=your_Database;Fed=True;AppClientId=your_AppId;AppKey=your_AppKey;Authority Id=your_TenantId . |
tableName | Obligatoire. Table dans laquelle ingérer les données. |
mappingRef | facultatif. Attribut pour passer une référence de mappage déjà définie dans le cluster. |
dataFormat | facultatif. Le format de données par défaut est multijson/json . Il peut être défini sur les formats texte pris en charge dansdatasource l’énumération de formats. Les exemples sont validés et fournis pour les formats CSV et JSON. |
managedServiceIdentity | Une identité managée peut être utilisée pour se connecter à Azure Data Explorer. Pour utiliser une identité managée par le système, utilisez « system ». Tous les autres noms d’identité sont interprétés comme une identité managée par l’utilisateur. |
Lorsque vous développez en local, ajoutez vos paramètres d’application dans le fichier local.settings.json de la collection Values
.
Utilisation
Le constructeur de l’attribut accepte la base de données et les attributs TableName
, MappingRef
et DataFormat
ainsi que le nom du paramètre de connexion. La commande KQL peut être une instruction KQL ou une fonction KQL. Le nom du paramètre de la chaîne de connexion correspond au paramètre d’application (dans local.settings.json
pour le développement local) qui contient les chaînes de connexion Kusto. Par exemple, "KustoConnectionString": "Data Source=https://your_cluster.kusto.windows.net;Database=your_Database;Fed=True;AppClientId=your_AppId;AppKey=your_AppKey;Authority Id=your_TenantId
. Les requêtes exécutées par la liaison d’entrée sont paramétrées. Les valeurs fournies dans les paramètres KQL sont utilisées au moment de l’exécution.
Étapes suivantes
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : pendant toute l’année 2024, nous allons éliminer progressivement Problèmes GitHub comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, voir :Soumettre et afficher des commentaires pour