Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’intégration de Gestion des API Azure (APIM) à l’API Microsoft Fabric pour GraphQL peut améliorer considérablement les fonctionnalités de votre API en fournissant une scalabilité et des fonctionnalités de sécurité robustes, telles que la gestion des identités, la limitation de débit et la mise en cache. Nous vous guiderons tout au long du processus d'installation et de configuration de ces fonctionnalités.
Ajouter une API Fabric GraphQL à Gestion des API Azure
Pour cette section, nous partons du principe que vous disposez d’une API GraphQL dans l’instance Fabric et APIM déjà opérationnelle. Si ce n’est pas le cas, vous pouvez suivre les instructions sur la création d’une API GraphQL dans Fabric ou cliquer sur Démarrer avec un exemple de base de données SQL dans le portail API pour GraphQL pour commencer à partir d’une nouvelle API.
Pour commencer à récupérer votre point de terminaison d’API à partir du portail Fabric, accédez à votre élément GraphQL et cliquez sur le bouton Copier le point de terminaison dans le ruban. Vous devez également enregistrer votre schéma GraphQL dans un fichier, que vous pouvez accomplir en cliquant sur le bouton Exporter le schéma et en l’enregistrant dans un fichier de votre appareil local :
Accédez maintenant à votre instance Gestion des API dans le portail Azure, puis sélectionnez API>+ Ajouter une API.
Choisissez l’icône GraphQL et, dans l’écran Création d’APIM à partir du schéma GraphQL , renseignez les champs requis tels que le nom d’affichage, le nom et le point de terminaison de l’API GraphQL. Sélectionnez Charger le schéma et utilisez le fichier de schéma que vous avez téléchargé précédemment :
Utilisation d’identités managées avec APIM et API pour GraphQL dans Fabric
Ensuite, nous devons configurer une stratégie pour l’authentification à l’aide d’une identité managée pour gérer l’authentification pour cette API. Vous pouvez créer une identité managée dans le portail Azure ou à l’aide de l’un des outils disponibles pour le faire.
Maintenant que nous avons des informations d’identification d’identité managée que nous pouvons utiliser pour l’authentification, nous devons lui accorder des autorisations pour l’élément GraphQL dans Fabric. Par souci de simplicité, nous ajoutons l’identité managée (dans cet exemple, apim-id) en tant que membre de l’espace de travail où se trouvent à la fois l’API GraphQL et sa source de données :
Si vous préférez activer l’accès directement aux éléments Fabric tels que l’API elle-même et les sources de données attachées à l’API comme une base de données LakeHouse ou SQL, vous devez accorder les autorisations appropriées pour l’identité managée sur chaque élément, en particulier si elles ont été attachées à l’API à l’aide de l’authentification unique (Sign-On SSO). Vous trouverez plus d’informations dans le résumé des autorisations.
Une fois que vous avez accordé vos autorisations d’informations d’identification à votre espace de travail, l’API Fabric GraphQL et/ou les sources de données associées, vous devez indiquer à APIM que vous souhaitez tirer parti de ces informations d’identification pour effectuer l’authentification. Revenez à la console APIM, accédez auxidentités managées> et ajoutez la même identité managée affectée par l’utilisateur que vous utilisez pour accéder à l’API Fabric GraphQL.
Accédez ensuite à l’onglet « Stratégies d’API » dans l’API GraphQL que vous avez créée précédemment, puis modifiez la stratégie de traitement entrant en ajoutant les entrées suivantes ci-dessous <inbound><base/>:
<authentication-managed-identity
resource="https://analysis.windows.net/powerbi/api"
client-id="MANAGED IDENTITY CLIENT ID GOES HERE"
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>
Veillez à remplacer l’ID client dans l’extrait de code ci-dessus par l’ID client de votre identité managée. Enregistrez la stratégie pour continuer.
À présent, revenez à l’API, accédez à l’onglet Test et confirmez que vous pouvez émettre des requêtes et/ou des mutations vers vos données Fabric via GraphQL :
Test de la connexion réussie entre APIM et Fabric GraphQL
Mise en cache
Les API et opérations dans Gestion des API Azure peuvent être configurées pour mettre en cache la réponse. La mise en cache des réponses peut réduire considérablement la latence pour les appelants d’API et la charge backend pour les fournisseurs d’API. APIM prend en charge la mise en cache intégrée, ou vous pouvez choisir d’utiliser votre propre instance Redis. Dans les deux cas, vous devez définir votre stratégie de mise en cache. Ici, nous avons modifié la stratégie précédente avec une configuration de mise en cache simple qui fonctionnerait pour la plupart des scénarios :
<policies>
<inbound>
<base />
<authentication-managed-identity
resource="https://analysis.windows.net/powerbi/api"
client-id="MANAGED IDENTITY CLIENT ID GOES HERE"
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>
<cache-lookup-value
key="@(context.Request.Body.As<String>(preserveContent: true))"
variable-name="cachedResponse"
default-value="not_exists" />
</inbound>
<!-- Control if and how the requests are forwarded to services -->
<backend>
<choose>
<when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") == "not_exists")">
<forward-request />
</when>
</choose>
</backend>
<!-- Customize the responses -->
<outbound>
<base />
<choose>
<when condition="@(context.Variables.GetValueOrDefault<string>("cachedResponse") != "not_exists")">
<set-body>@(context.Variables.GetValueOrDefault<string>("cachedResponse"))</set-body>
</when>
<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>
<!-- Handle exceptions and customize error responses -->
<on-error>
<base />
</on-error>
</policies>
Vous pouvez confirmer que les demandes sont mises en cache en traçant une requête d’API GraphQL ou une mutation dans le portail APIM :
Pour les scénarios de mise en cache avancés, reportez-vous à la documentation APIM sur la mise en cache.
Limitation du débit
Vous pouvez limiter le nombre d’appels d’API qu’un client peut effectuer dans une période spécifique. Voici un exemple d’entrée de stratégie de limitation de débit que vous pouvez ajouter ci-dessous <inbound><base/> qui applique pas plus de 2 appels toutes les 60 secondes pour un utilisateur donné :
<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" />
Après avoir envoyé plus de 2 appels d’API en une minute, vous recevrez un message d’erreur :
{
"statusCode": 429,
"message": "Rate limit is exceeded. Try again in 58 seconds."
}
Pour plus d’informations sur la configuration des stratégies de limitation de débit dans APIM, consultez la documentation.
L’intégration de l’API Microsoft Fabric pour GraphQL à Gestion des API Azure réunit le meilleur des deux mondes : les fonctionnalités de données enrichies de Fabric et les fonctionnalités de passerelle de niveau entreprise d’APIM. En configurant des identités managées, vous activez l’authentification sécurisée auprès de Fabric. Avec la mise en cache personnalisée et les stratégies de limitation de débit, vous bénéficiez d’un contrôle précis sur les performances, le coût et l’expérience utilisateur, adaptés aux caractéristiques uniques des API GraphQL.
Cette configuration fournit non seulement davantage d’options pour sécuriser vos données Fabric, mais également la scalabilité et l’observabilité requises pour prendre en charge les charges de travail de production entre les équipes et les locataires.