Självstudie: Skapa en .NET mellannivåtjänst med REST-API:et Kör DAX-frågor

I den här självstudien använder du Microsoft.Samples.XMLA.ExecuteQueries – ett .NET-webb-API som tillhandahåller DAX-frågor via XMLA-slutpunkten med hjälp av ADOMD.NET – och ändrar det så att det använder Execute DAX Queries REST API, vilket returnerar resultat i Apache Arrow IPC-format. Exemplet innehåller ramverket på mellannivå (routning, hastighetsbegränsning, hälsoavsökning). Den här självstudien visar hur du ersätter den underliggande XMLA/ADOMD-query-körningen med REST API-anrop och hantering av svar med Arrow IPC.

Förutsättningar

• .NET 8 SDK eller senare.
• En Power BI-arbetsyta i Premium- eller Fabric-kapacitet med minst en semantisk modell.
• En Microsoft Entra appregistrering med en klienthemlighet.
• Tjänstens huvudnamn har lagts till som medlem i arbetsytan med rollen Deltagare (eller högre).
• Följande klientinställningar är aktiverade:
  • Kör fråge-REST API:et för dataset och Tillåt tjänsthuvudprincipaler att använda Power BI-API:er (under Developer settings).
  • Tillåt XMLA-slutpunkter och Analysera i Excel med lokala semantiska modeller (under Integreringsinställningar).

Mer information om exempeltjänstarkitekturen finns i exempel README.

Innan du börjar

Exempeltjänsten använder XMLA-slutpunkten med ADOMD.NET. Den här guiden konverteras för att använda REST API:et 'Execute DAX Queries', vilket returnerar resultat i Apache Arrow IPC-format. Med båda metoderna kan du köra DAX-frågor mot Power BI semantiska modeller, men de skiljer sig åt på viktiga sätt.

Välj REST-API:et Execute DAX Queries när du skapar en ny tjänst eller dina nedströmskonsumenter kan dra nytta av Arrow IPC (till exempel analyspipelines, Python-notebooks eller kolumndatabaser). Behåll XMLA/ADOMD om du behöver MDX-stöd eller förlitar dig på funktioner på sessionsnivå som beräknade medlemmar som är begränsade till en session.

1 – Klona och verifiera exemplet

Klona lagringsplatsen och bekräfta att den kompileras:

git clone https://github.com/dbrownems/Microsoft.Samples.XMLA.ExecuteQueries.git
cd Microsoft.Samples.XMLA.ExecuteQueries
dotnet build

Lösningen innehåller två projekt: mellannivåtjänsten (Microsoft.Samples.XMLA.ExecuteQueries) och en belastningstestklient (Tester). Du behöver inte köra den ursprungliga tjänsten mot en live-arbetsyta – kontrollera bara att bygget lyckas innan du gör ändringar.

2 – Uppdatera NuGet-beroenden

I projektet Microsoft.Samples.XMLA.ExecuteQueries tar du bort ADOMD.NET-paketet och lägger till paket för Pil-API:et:

cd Microsoft.Samples.XMLA.ExecuteQueries
dotnet remove package Microsoft.AnalysisServices.AdomdClient.NetCore.retail.amd64
dotnet add package Apache.Arrow
dotnet add package Microsoft.Identity.Client

Behåll Microsoft.PowerBI.Api-paketet om du vill återanvända modelltyperna för begäran/svar. annars tar du bort den och definierar dina egna DTU:er.

3 – Ersätt ADOMD-anslutningspooler med MSAL-tokencachelagring

Exemplet använder AdomdConnectionPool.cs för att samla XMLA-anslutningar. Pil-API:et är en tillståndslös REST-slutpunkt, så du ersätter anslutningspooler med cachelagring av MSAL-token.

Skapa en ny fil TokenService.cs:

using Microsoft.Identity.Client;

public class TokenService
{
    private readonly IConfidentialClientApplication _app;
    private readonly string[] _scopes =
        { "https://analysis.windows.net/powerbi/api/.default" };

    public TokenService(IConfiguration config)
    {
        _app = ConfidentialClientApplicationBuilder
            .Create(config["PowerBI:ClientId"])
            .WithClientSecret(config["PowerBI:ClientSecret"])
            .WithAuthority(AzureCloudInstance.AzurePublic,
                config["PowerBI:TenantId"])
            .Build();
    }

    public async Task<string> GetAccessTokenAsync()
    {
        var result = await _app
            .AcquireTokenForClient(_scopes).ExecuteAsync();
        return result.AccessToken;
    }
}

MSAL cachelagrar token automatiskt – efterföljande anrop returnerar den cachelagrade token tills den upphör att gälla.

Ta bort AdomdConnectionPool.cs och AdomdExtensions.cs. De behövs inte längre.

4 – Uppdatera frågehanteraren för att anropa Pil-API:et

I Handlers.cs ersätter du exekveringen av ADOMD-frågan med ett HTTP-anrop till slutpunkten för att köra DAX-frågor.

Ta bort alla ADOMD-referenser (AdomdConnectionPool, AdomdConnection, AdomdCommand, WrappedConnection). Ändra hanterarens inmatade beroenden till TokenService och HttpClient i stället för anslutningspooler och arbetsytesökningar.

Skapa REST API-URL:en från arbetsytan och datauppsättnings-GUID:erna som redan är tillgängliga i routningsparametrarna:

var url = $"https://api.powerbi.com/v1.0/myorg/groups/{workspaceId}"
        + $"/datasets/{datasetId}/executeDaxQueries";

PUBLICERA DAX-frågan med en JSON-begärandetext:

var token = await tokenService.GetAccessTokenAsync();

using var request = new HttpRequestMessage(HttpMethod.Post, url);
request.Headers.Authorization =
    new AuthenticationHeaderValue("Bearer", token);
request.Content = new StringContent(
    JsonSerializer.Serialize(new { query, queryTimeout = 120 }),
    Encoding.UTF8, "application/json");

var response = await httpClient.SendAsync(
    request, HttpCompletionOption.ResponseHeadersRead);
response.EnsureSuccessStatusCode();

Använd HttpCompletionOption.ResponseHeadersRead så att svarstexten strömmar utan buffring – detta är viktigt för stora resultatuppsättningar.

5 – Hantera pilens IPC-svar

API:et Utför DAX-frågor returnerar en eller flera Arrow IPC-strömmar som sammanfogats i svarstexten. Varje ström innehåller schemametadata som anger dess syfte:

• Dataresultat – frågeresultatet (inga särskilda metadataflaggor).
• Felresultat – IsError=true i schemametadata, med FaultCode och FaultString värden.
• Körningsmått – IsExecMetrics=true (om du begärde mått via parametern executionMetrics ).

Ersätt DataResult.cs med logik som hanterar pilsvaret. Om din mellannivå bara vidarebefordrar Pil-IPC till underordnade konsumenter kan du strömma byteen utan deserialisering:

context.Response.ContentType = "application/vnd.apache.arrow.stream";
await response.Content.CopyToAsync(context.Response.Body);

Om du behöver granska resultat eller konvertera format kan du deserialisera pilströmmen med ArrowStreamReader:

using var stream = await response.Content.ReadAsStreamAsync();
using var reader = new ArrowStreamReader(stream);

while (true)
{
    var batch = await reader.ReadNextRecordBatchAsync();
    if (batch == null) break;
    // Process batch — convert to JSON, filter rows, etc.
}

Kontrollera schemametadata för att identifiera felsvar:

var metadata = reader.Schema.Metadata;
if (metadata.TryGetValue("IsError", out var isError)
    && isError == "true")
{
    var faultCode = metadata.GetValueOrDefault(
        "FaultCode", "Unknown");
    var faultString = metadata.GetValueOrDefault(
        "FaultString", "Unknown error");
    // Return error to caller
}

6 – Förenkla konfigurationen av arbetsytan

appsettings.json Exemplet konfigurerar XMLA-slutpunkter och sökningar för datauppsättningsnamn eftersom ADOMD ansluter med katalognamn. Pil-REST-API:et använder arbetsyte- och datauppsättnings-GUID direkt från begärande-URL:en, så konfigurationen är enklare.

Uppdatera appsettings.json med autentiseringsuppgifterna för tjänstens huvudnamn och ta bort de XMLA-specifika fälten:

{
  "PowerBI": {
    "TenantId": "YOUR_TENANT_ID",
    "ClientId": "YOUR_APP_CLIENT_ID",
    "ClientSecret": "YOUR_CLIENT_SECRET"
  }
}

Avsnittet Workspaces med XmlaEndpoint och Datasets matriser behövs inte längre. Du kan ta bort Workspace.cs och Dataset.cs, eller återanvända Datasets listan som en tillåten lista för styrning (begränsa vilka datauppsättningar som tjänsten kan fråga).

7 – Registrera tjänster och uppdatera routning

I Program.csersätter du ADOMD-poolen och arbetsyteregistreringarna med de nya tjänsterna:

builder.Services.AddSingleton<TokenService>();
builder.Services.AddHttpClient();

Uppdatera rutten så att den matchar slutpunktsmönstret för att köra DAX-frågor:

app.MapPost(
    "/v1.0/myorg/groups/{workspaceId:Guid}"
    + "/datasets/{datasetId:Guid}/executeDaxQueries",
    Handlers.ExecuteDaxQueriesInGroup);

Den befintliga hastighetsbegränsaren, hälsoavsökningen och begäranderäknaren från exemplet är fortfarande användbara såsom de är.

8 – Testa tjänsten

Kör tjänsten:

dotnet run --project Microsoft.Samples.XMLA.ExecuteQueries

Skicka en DAX-fråga från en annan terminal:

curl -X POST https://localhost:3000/v1.0/myorg/groups/YOUR_WORKSPACE_ID/datasets/YOUR_DATASET_ID/executeDaxQueries \
  -H "Content-Type: application/json" \
  -d '{"query": "EVALUATE TOPN(5, '\''DimProduct'\'')"}'

Svaret är en binär Arrow IPC-ström. Spara den i en fil och inspektera med Python:

curl -s -o result.arrow https://localhost:3000/v1.0/myorg/groups/YOUR_WORKSPACE_ID/datasets/YOUR_DATASET_ID/executeDaxQueries \
  -H "Content-Type: application/json" \
  -d '{"query": "EVALUATE TOPN(5, '\''DimProduct'\'')"}'

python -c "
import pyarrow as pa
reader = pa.ipc.open_stream('result.arrow')
table = reader.read_all()
print(table.schema)
print(table.to_pandas())
"

Sammanfattning av ändringarna

Rensa resurser

När du är klar med testningen:

1. Stoppa den lokala tjänsten (tryck på Ctrl+C i terminalen).
2. Om du har skapat en Microsoft Entra appregistrering enbart för den här självstudien går du till Azure-portalen och tar bort den.
3. Ta bort tjänstens huvudnamn från Power BI-arbetsytan om det inte längre behövs.

Relaterat innehåll

• Förstå Execute DAX Queries API:et
• Kom igång med REST API:et Utföra DAX-frågor
• Tutorial: Databearbetning med Python för stora datamängder inom datavetenskap
• Bästa praxis för REST-API för att köra DAX-frågor
• Microsoft.Samples.XMLA.ExecuteQueries-exempel (GitHub)