Integrer Azure API Management (APIM) med Fabric API til GraphQL

Integration af Azure API Management (APIM) med Microsoft Fabrics API for GraphQL forbedrer markant din API's kapaciteter ved at tilbyde robuste skalerbarheds- og sikkerhedsfunktioner. APIM fungerer som en gateway i enterprise-kvalitet, der tilføjer avancerede funktioner, herunder identitetsstyring, hastighedsbegrænsning, respons-caching, trusselbeskyttelse og centraliseret overvågning – alt sammen uden at ændre din Fabric API-konfiguration.

Ved at route dine GraphQL-forespørgsler gennem APIM kan du skalere til at håndtere øget trafik, implementere avancerede sikkerhedspolitikker og få indsigt i API-brugsmønstre i hele din organisation.

Denne artikel guider dig gennem integrationen af APIM med Fabric API for GraphQL, konfiguration af managed identity authentication og implementering af caching- og hastighedsbegrænsningspolitikker.

Hvem bruger Azure API Management med GraphQL

APIM-integration er værdifuld til:

Enterprise-arkitekter, der eksponerer Fabric-data gennem en centraliseret, styret API-gateway for adgang på tværs af organisationen.
Fabric-administratorer implementerer rate limiting, caching og sikkerhedspolitikker for at beskytte Fabric-kapacitet og data
IT-sikkerhedsteams , der kræver avanceret autentificering, autorisation og trusselbeskyttelse for adgang til Fabric-data
Platformteams , der administrerer og styrer flere Fabric GraphQL API'er på tværs af afdelinger og forretningsenheder

Brug APIM-integration, når du har brug for enterprise-grade API-styringsfunktioner som hastighedsbegrænsning, caching, sikkerhedspolitikker og centraliseret styring for dine Fabric GraphQL API'er.

Forudsætninger

Før du begynder, skal du sikre dig, at du har:

Et Fabric API til GraphQL er allerede oprettet. Hvis ikke, se Opret et API for GraphQL eller brug Start med eksempel SQL-database i API'en for GraphQL-portalen
En Azure API Management-instans. For opsætningsinstruktioner, se Opret en API-administrationsinstans
Tilladelser til at oprette administrerede identiteter og konfigurere APIM-politikker

Føj en Fabric GraphQL-API til Azure API Management

Det første skridt i at integrere APIM med Fabric er at importere dit GraphQL API i Azure API Management. Denne proces opretter en proxy, der dirigerer anmodninger gennem APIM, mens forbindelsen til dine Fabric-datakilder opretholdes. Ved at importere API'en lægger du grundlaget for at tilføje virksomhedsfunktioner som autentificeringspolitikker, caching og hastighedsbegrænsning.

Importprocessen kræver to oplysninger fra dit Fabric GraphQL API: endpoint-URL'en (hvor APIM sender anmodninger) og skemafilen (som definerer API-strukturen og tilgængelige operationer).

Eksporter dine GraphQL API-detaljer

Først skal du indsamle de nødvendige oplysninger fra dit Fabric GraphQL API:

Åbn dit GraphQL API i Fabric-portalen
I båndet vælger du Kopier endpoint for at få din API's URL
Vælg Export schema for at downloade GraphQL-skemafilen til din lokale enhed

Importer API'en til APIM

Med din endpoint-URL og skemafil klar kan du nu registrere GraphQL API'en i APIM. Dette skaber en API-definition, som APIM bruger til at validere anmodninger, generere dokumentation og anvende politikker. Det skema, du uploader, definerer, hvilke forespørgsler og mutationer klienter kan udføre.

Navigér til din API Management-instans i Azure-portalen
Vælg API'er>+ Tilføj API
Vælg GraphQL-ikonet
I Create from GraphQL-skemaskærmen skal du angive:
- Visningsnavn: Et venligt navn til API'et
- Navn: API-identifikatoren
- GraphQL API-endpoint: Den endpoint-URL, du kopierede fra Fabric
Vælg Upload skema og vælg den skemafil, du har downloadet

Konfigurér styret identitetsautentificering

Nu hvor dit GraphQL API er registreret i APIM, skal du konfigurere, hvordan APIM autentificeres med Fabric. Administrerede identiteter tilbyder en sikker, adgangskodefri autentificeringsmetode, der eliminerer behovet for at gemme legitimationsoplysninger i din APIM-konfiguration. Azure styrer automatisk identitetslivscyklussen og håndterer token-indsamling, hvilket gør denne tilgang både mere sikker og lettere at vedligeholde end traditionelle autentificeringsmetoder.

Autentificeringsopsætningen omfatter tre hovedtrin: oprettelse af den administrerede identitet i Azure, tilladelse til at få adgang til dit Fabric-arbejdsområde og datakilder, samt konfiguration af APIM til at bruge denne identitet, når der foretages anmodninger til Fabric.

Opret og tildel en administreret identitet

Først skal du oprette den administrerede identitet, som APIM bruger til at autentificere:

Opret en brugertildelt administreret identitet i Azure Portal.
Bemærk klient-ID'et på den administrerede identitet – du skal bruge klient-ID'et til policy-konfigurationen.

Giv de administrerede identitetstilladelser i Fabric

Efter oprettelsen af den administrerede identitet skal du give den tilladelser til at få adgang til dine Fabric-ressourcer. Den administrerede identitet skal have adgang til både GraphQL API-elementet selv og de datakilder, den forbinder til (såsom søhuse eller lagre). At tilføje identiteten som arbejdsområdemedlem er den simpleste tilgang, fordi det giver adgang til alle elementer i arbejdsområdet på én gang.

Åbn Fabric-arbejdsområdet, der indeholder dit GraphQL API
Vælg Administrer adgang
Tilføj den administrerede identitet (for eksempel apim-id) med mindst Bidragyder-rollen

Tips

For mere detaljeret kontrol kan du give tilladelser direkte til individuelle Fabric-elementer (API'en og dets datakilder) i stedet for adgang på arbejdsområde-niveau. Granulær kontrol er især vigtigt, hvis dit API bruger single sign-on (SSO) autentificering. For mere information, se Oversigt over Autentificering og tilladelser.

Konfigurer APIM til at bruge den administrerede identitet

Med tilladelser givet i Fabric skal du fortælle APIM, hvilken managed identity der skal bruges. Denne association gør det muligt for APIM at autentificere som denne identitet, når der foretages forespørgsler til din Fabric GraphQL API.

I Azure-portalen skal du navigere til din APIM-instans
Gå til Security>Managed Identities
Tilføj den brugertildelte administrerede identitet, du oprettede tidligere

Tilføj autentificeringspolitik

Det sidste autentificeringstrin er at tilføje en APIM-politik, der indhenter et adgangstoken ved hjælp af den administrerede identitet og inkluderer det i forespørgsler til Fabric. Denne politik kører på hver anmodning og håndterer automatisk token-indsamling og fornyelse. Politikken bruger elementet authentication-managed-identity til at hente et token til Fabric API-ressourcen og tilføjer det derefter til autorisationsheaderen.

I din GraphQL API i APIM, vælg fanen API Policies
Rediger indgående behandlingspolitikken

Tilføj følgende XML under <inbound><base/>:

<authentication-managed-identity 
    resource="https://analysis.windows.net/powerbi/api" 
    client-id="YOUR-MANAGED-IDENTITY-CLIENT-ID" 
    output-token-variable-name="token-variable" 
    ignore-error="false" />
<set-header name="Authorization" exists-action="override">
    <value>@("Bearer " + (string)context.Variables["token-variable"])</value>
</set-header>

Erstat YOUR-MANAGED-IDENTITY-CLIENT-ID klient-ID'et med din administrerede identitet
Gem policen

Test forbindelsen

Før du tilføjer caching og hastighedsbegrænsning, skal du sikre dig, at autentificeringsopsætningen fungerer korrekt. Test nu sikrer, at eventuelle problemer, du støder på senere, ikke er relateret til autentificeringskonfiguration.

I APIM skal du navigere til dit GraphQL API
Gå til fanen Test.
Udfør en prøveforespørgsel eller mutation for at bekræfte, at forbindelsen virker

Konfigurér respons-caching

Response caching reducerer betydeligt latenstiden for API-kaldere og mindsker backend-belastningen på dine Fabric-datakilder. APIM understøtter indbygget caching eller eksterne Redis-instanser. For GraphQL API'er bruger caching anmodningskroppen (GraphQL-forespørgslen) som cache-nøgle, hvilket sikrer, at identiske forespørgsler returnerer cachede svar.

Fordele ved at cache GraphQL-svar:

Reduceret latenstid: Cachede svar returneres øjeblikkeligt uden at forespørge Fabric
Lavere kapacitetsforbrug: Færre forespørgsler til Fabric reducerer brugen af CU (kapacitetsenhed)
Bedre skalerbarhed: Håndter flere samtidige brugere uden at øge belastningen i backend

Tilføj caching-politik

For at implementere caching ændrer du den eksisterende autentificeringspolitik for at tilføje cache-opslag og lagringslogik. Politikken tjekker for cachede svar, før anmodninger videresendes til Fabric, og gemmer succesfulde svar til fremtidig brug. Dette komplette politikeksempel viser, hvordan autentificering og caching arbejder sammen:

<policies>
    <inbound>
        <base />
        <!-- Authenticate with managed identity -->
        <authentication-managed-identity 
            resource="https://analysis.windows.net/powerbi/api" 
            client-id="YOUR-MANAGED-IDENTITY-CLIENT-ID" 
            output-token-variable-name="token-variable" 
            ignore-error="false" />
        <set-header name="Authorization" exists-action="override">
            <value>@("Bearer " + (string)context.Variables["token-variable"])</value>
        </set-header>
        <!-- Check if response is cached -->
        <cache-lookup-value 
            key="@(context.Request.Body.As<String>(preserveContent: true))" 
            variable-name="cachedResponse" 
            default-value="not_exists" />
    </inbound>
    <backend>
        <!-- Only forward request if not cached -->
        <choose>
            <when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") == "not_exists")">
                <forward-request />
            </when>
        </choose>
    </backend>
    <outbound>
        <base />
        <choose>
            <!-- Return cached response if it exists -->
            <when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") != "not_exists")">
                <set-body>@(context.Variables.GetValueOrDefault<string>("cachedResponse"))</set-body>
            </when>
            <!-- Cache successful responses for 60 seconds -->
            <when condition="@((context.Response.StatusCode == 200) && (context.Variables.GetValueOrDefault<string>("cachedResponse") == "not_exists"))">
                <cache-store-value 
                    key="@(context.Request.Body.As<String>(preserveContent: true))" 
                    value="@(context.Response.Body.As<string>(preserveContent: true))" 
                    duration="60" />
            </when>
        </choose>
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

Sådan fungerer denne politik:

Indgående: Autentificerer med managed identity og tjekker, om svaret er cachet baseret på GraphQL-forespørgslen
Backend: Springer videresendelsen af forespørgslen til Fabric, hvis der findes et cachet svar
Udgående: Returnerer cachede svar eller cacher nye succesfulde svar i 60 sekunder

Kontroller at caching virker

For at bekræfte, at forespørgsler caches:

I APIM skal du køre den samme GraphQL-forespørgsel to gange
Spor API-kaldet for at se cache-hits

Optimer cache-varighed

Eksemplet bruger en cache-varighed på 60 sekunder. Justér varigheden baseret på dine krav til dataaktualitet:

Højfrekvente opdateringer: Brug kortere varigheder (10-30 sekunder) til hyppigt skiftende data
Statiske eller referencedata: Brug længere varigheder (5-60 minutter) til data, der ændrer sig sjældent
Krav i realtid: Cache ikke forespørgsler, der altid skal returnere de nyeste data

For avancerede caching-scenarier, herunder cache-invalidering og ekstern Redis-konfiguration, se APIM caching-politikker.

Begræns hastighed

Du kan begrænse antallet af API-kald, som en klient kan foretage i en bestemt tidsperiode. Her er en eksempelratebegrænsningspolitik, du kan tilføje nedenfor <inbound><base/> , som håndhæver højst to kald hver 60. sekund for en given bruger:

<rate-limit-by-key 
    calls="2" 
    renewal-period="60" 
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization"))" 
    increment-condition="@(context.Response.StatusCode == 200)" 
    remaining-calls-variable-name="remainingCallsPerUser" />

Efter at have sendt mere end to API-kald på et minut, vil du modtage en fejlmeddelelse:

{
    "statusCode": 429,
    "message": "Rate limit is exceeded. Try again in 58 seconds."
}

For mere information om, hvordan du konfigurerer hastighedsbegrænsningspolitikker i APIM, se dokumentationen.

Bedste praksis

Når du integrerer APIM med Fabric API for GraphQL, skal du følge disse anbefalinger:

Sikkerhed

Brug administrerede identiteter: Foretræk administrerede identiteter frem for API-nøgler eller forbindelsesstrenge til autentificering
Implementér least privilege: Giv kun de minimumstilladelser, der er nødvendige for den administrerede identitet
Aktivér kun HTTPS: Konfigurer APIM til at afvise HTTP-forespørgsler og håndhæve HTTPS
Valider input: Brug APIM-politikker til at validere GraphQL-forespørgsler, før de videresender til Fabric

Ydeevne

Cache ofte tilgået data: Identificer almindelige forespørgsler og sæt passende cache-varigheder
Overvåg cache-hitrater: Brug APIM-analyser til at spore cache-effektivitet
Optimer hastighedsgrænser: Balancer brugeroplevelsen med kapacitetsbeskyttelse
Brug regional deployment: Deploy APIM i samme region som din Fabric-kapacitet

Overvågning og styring

Aktiver diagnostik: Konfigurer APIM-diagnostiklogging til at spore API-brug
Opsæt advarsler: Opret advarsler for overtrædelser af prisgrænsen og fejl
Versionér dine API'er: Brug APIM-versionering til at håndtere eventuelle fejlbehæftede ændringer
Dokumentér dine API'er: Brug APIM's udviklerportal til at levere API-dokumentation

Omkostningsoptimering

Grænser for den rette størrelse: Sæt grænser, der passer til dit kapacitetsniveau
Overvåg kapacitetsforbrug: Spor både APIM- og Fabric-kapacitetsforbrug
Brug caching strategisk: Balancer friskhedskrav med kapacitetsbesparelser
Gennemgå brugsmønstre: Analyser regelmæssigt, hvilke forespørgsler der bruger flest ressourcer

Resumé

Integration af Microsoft Fabric API for GraphQL med Azure API Management samler Fabrics kraftfulde datakapaciteter med APIM's enterprise-grade API-gateway-funktioner. Denne kombination giver:

Forbedret sikkerhed: Administreret identitetsautentificering, trusselsbeskyttelse og politikbaseret adgangskontrol
Forbedret skalerbarhed: Respons-caching, hastighedsbegrænsning og belastningsfordeling på tværs af flere backends
Bedre ydeevne: Reduceret latenstid gennem caching og optimeret anmodningsrouting
Centraliseret styring: Samlet overvågning, versionsstyring og administration på tværs af flere API'er
Omkostningskontrol: Hastighedsbegrænsning og caching reducerer forbruget af Fabric-kapacitet

Ved at følge konfigurationstrinene og bedste praksis i denne artikel kan du opbygge et robust, sikkert og skalerbart API-lag, der understøtter produktionsarbejdsbelastninger på tværs af din organisation.

Feedback

Var denne side nyttig?

Last updated on 2026-01-20