Partager via


Intégrer Azure Functions à Azure Data Explorer à l’aide de liaisons d’entrée et de sortie (préversion)

Important

Ce connecteur peut être utilisé dans l’analyse en temps réel dans Microsoft Fabric. Utilisez les instructions de cet article avec les exceptions suivantes :

Azure Functions vous permettent d’exécuter du code serverless dans le cloud selon une planification ou en réponse à un événement. Avec les liaisons d’entrée et de sortie Azure Data Explorer pour Azure Functions, vous pouvez intégrer Azure Data Explorer à vos workflows pour ingérer des données et exécuter des requêtes sur votre cluster.

Prérequis

Essayer l’intégration avec notre exemple de projet

Utilisation des liaisons Azure Data Explorer pour Azure Functions

Pour plus d’informations sur l’utilisation des liaisons Azure Data Explorer pour Azure Functions, consultez les rubriques suivantes :

Scénarios d’utilisation de liaisons Azure Data Explorer pour Azure Functions

Les sections suivantes décrivent certains scénarios courants d’utilisation des liaisons Azure Data Explorer pour Azure Functions.

Liaisons d’entrée

Les liaisons d’entrée exécutent une requête Langage de requête Kusto (KQL) ou une fonction KQL, éventuellement avec des paramètres, et retourne la sortie à la fonction.

Les sections suivantes décrivent comment utiliser des liaisons d’entrée dans certains scénarios courants.

Scénario 1 : Point de terminaison HTTP pour interroger des données à partir d’un cluster

L’utilisation de liaisons d’entrée s’applique dans les situations où vous devez exposer des données Azure Data Explorer via une API REST. Dans ce scénario, vous utilisez un déclencheur HTTP Azure Functions pour interroger des données dans votre cluster. Le scénario est particulièrement utile dans les situations où vous devez fournir un accès par programme aux données Azure Data Explorer pour des applications ou des services externes. En exposant vos données via une API REST, les applications peuvent facilement les consommer sans avoir à se connecter directement à votre cluster.

Le code définit une fonction avec un déclencheur HTTP et une liaison d’entrée Azure Data Explorer. La liaison d’entrée spécifie la requête à exécuter sur la table Products de la base de données productsdb . La fonction utilise la colonne productId comme prédicat transmis en tant que paramètre.

{
    [FunctionName("GetProduct")]
    public static async Task<IActionResult> RunAsync(
        [HttpTrigger(AuthorizationLevel.User, "get", Route = "getproducts/{productId}")]
        HttpRequest req,
        [Kusto(Database:"productsdb" ,
        KqlCommand = "declare query_parameters (productId:long);Products | where ProductID == productId" ,
        KqlParameters = "@productId={productId}",
        Connection = "KustoConnectionString")]
        IAsyncEnumerable<Product> products)
    {
        IAsyncEnumerator<Product> enumerator = products.GetAsyncEnumerator();
        var productList = new List<Product>();
        while (await enumerator.MoveNextAsync())
        {
            productList.Add(enumerator.Current);
        }
        await enumerator.DisposeAsync();
        return new OkObjectResult(productList);
    }
}

La fonction peut ensuite être appelée, comme suit :

curl https://myfunctionapp.azurewebsites.net/api/getproducts/1

Scénario 2 : déclencheur planifié pour exporter des données à partir d’un cluster

Le scénario suivant s’applique dans les situations où les données doivent être exportées selon une planification basée sur le temps.

Le code définit une fonction avec un déclencheur de minuteur qui exporte une agrégation de données de ventes de la base de données productsdb vers un fichier CSV dans Stockage Blob Azure.

public static async Task Run([TimerTrigger("0 0 1 * * *")] TimerInfo myTimer,
    [Kusto(ConnectionStringSetting = "KustoConnectionString",
            DatabaseName = "productsdb",
            Query = "ProductSales | where OrderDate >= ago(1d) | summarize Sales = sum(ProductSales) by ProductName | top 10 by Sales desc")] IEnumerable<dynamic> queryResults,
[Blob("salescontainer/productsblob.csv", FileAccess.Write, Connection = "BlobStorageConnection")] CloudBlockBlob outputBlob,
ILogger log)
{
    // Write the query results to a CSV file
    using (var stream = new MemoryStream())
    using (var writer = new StreamWriter(stream))
    using (var csv = new CsvWriter(writer, CultureInfo.InvariantCulture))
    {
        csv.WriteRecords(queryResults);
        writer.Flush();
        stream.Position = 0;
        await outputBlob.UploadFromStreamAsync(stream);
    }
}

Liaisons de sortie

Les liaisons de sortie prennent une ou plusieurs lignes et les insèrent dans une table Azure Data Explorer.

Les sections suivantes décrivent comment utiliser des liaisons de sortie dans certains scénarios courants.

Scénario 1 : point de terminaison HTTP pour ingérer des données dans un cluster

Le scénario suivant s’applique dans les situations où les requêtes HTTP entrantes doivent être traitées et ingérées dans votre cluster. À l’aide d’une liaison de sortie, les données entrantes de la demande peuvent être écrites dans des tables Azure Data Explorer.

Le code définit une fonction avec un déclencheur HTTP et une liaison de sortie Azure Data Explorer. Cette fonction prend une charge utile JSON dans le corps de la requête HTTP et l’écrit dans la table products de la base de données productsdb .

public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Anonymous, "post", Route = "addproductuni")]
    HttpRequest req, ILogger log,
    [Kusto(Database:"productsdb" ,
    TableName ="products" ,
    Connection = "KustoConnectionString")] out Product product)
{
    log.LogInformation($"AddProduct function started");
    string body = new StreamReader(req.Body).ReadToEnd();
    product = JsonConvert.DeserializeObject<Product>(body);
    string productString = string.Format(CultureInfo.InvariantCulture, "(Name:{0} ID:{1} Cost:{2})",
                product.Name, product.ProductID, product.Cost);
    log.LogInformation("Ingested product {}", productString);
    return new CreatedResult($"/api/addproductuni", product);
}

La fonction peut ensuite être appelée, comme suit :

curl -X POST https://myfunctionapp.azurewebsites.net/api/addproductuni -d '{"Name":"Product1","ProductID":1,"Cost":100,"ActivatedOn":"2023-01-02T00:00:00"}'

Scénario 2 : Ingérer des données à partir de RabbitMQ ou d’autres systèmes de messagerie pris en charge sur Azure

Le scénario suivant s’applique dans les situations où les données d’un système de messagerie doivent être ingérées dans votre cluster. À l’aide d’une liaison de sortie, les données entrantes du système de messagerie peuvent être ingérées dans des tables Azure Data Explorer.

Le code définit une fonction avec des messages, des données au format JSON, entrants via un déclencheur RabbitMQ qui sont ingérés dans la table products de la base de données productsdb .

public class QueueTrigger
{
    [FunctionName("QueueTriggerBinding")]
    [return: Kusto(Database: "productsdb",
                TableName = "products",
                Connection = "KustoConnectionString")]
    public static Product Run(
        [RabbitMQTrigger(queueName: "bindings.products.queue", ConnectionStringSetting = "rabbitMQConnectionAppSetting")] Product product,
        ILogger log)
    {
        log.LogInformation($"Dequeued product {product.ProductID}");
        return product;
    }
}

Pour plus d’informations sur les fonctions, consultez Azure Functions documentation. L’extension Azure Data Explorer est disponible sur :