Implémenter le back-end Microsoft Fabric

Article
12/03/2024

Cet exemple de référentiel de développement de charges de travail Microsoft Fabric est un point de départ pour la génération d’applications qui nécessitent une intégration à divers services ainsi que pour l’intégration une architecture de lakehouse. Cet article vous aide à préparer l’environnement, et à configurer les composants nécessaires pour commencer. L’article décrit les composants clés et leurs rôles dans l’architecture.

Serveur frontal

Le front-end est responsable de la gestion de l’expérience utilisateur (UX) et du comportement. Il communique avec le portail front-end Fabric via un iFrame pour faciliter une interaction transparente.

Pour plus d’informations, consultez Front-end du kit de développement de charges de travail Microsoft Fabric.

BackEnd

Le serveur principal stocke les données et les métadonnées. Il utilise les opérations CRUD (créer, lire, mettre à jour et supprimer) pour créer des éléments de charge de travail et des métadonnées, et exécute des travaux pour remplir les données du stockage. La communication entre le front-end et le back-end est établie via des API publiques.

Azure Relay et DevGateway

Azure Relay permet la communication entre l’environnement de développement local et le back-end Fabric en mode développeur. En mode développeur, la charge de travail fonctionne sur l’ordinateur du développeur.

L’utilitaire DevGateway a deux rôles :

Il gère le côté charge de travail du canal Azure Relay, et gère l’inscription de l’instance locale de la charge de travail auprès de Fabric dans le contexte d’une capacité spécifique. DevGateway rend la charge de travail accessible dans tous les espaces de travail affectés à cette capacité. L’utilitaire gère la désinscription quand le canal s’arrête.
Il fonctionne avec Azure Relay pour canaliser les appels d’API de charge de travail de Fabric vers la charge de travail.

Les appels d’API de contrôle de charge de travail sont effectués directement de la charge de travail vers Fabric. Le canal Azure Relay n’est pas nécessaire pour les appels.

Intégration du Lakehouse

L’architecture du kit de développement de charges de travail s’intègre de manière transparente à une architecture de lakehouse pour les opérations telles que l’enregistrement, la lecture et l’extraction de données. L’interaction est facilitée par Azure Relay et le kit SDK Fabric pour garantir une communication sécurisée et authentifiée. Pour plus d’informations, consultez utilisation des données client.

Authentification et sécurité

Microsoft Entra ID est utilisé pour l’authentification sécurisée, ce qui garantit que toutes les interactions au sein de l’architecture sont autorisées et sécurisées.

La Vue d’ensemble du kit de développement donne un aperçu de notre architecture. Pour plus d’informations sur la configuration des projets, les recommandations d’authentification et la façon de démarrer, consultez les articles suivants :

Diagramme montrant la façon dont le kit SDK Fabric s’intègre à Fabric.

Le front-end (FE) établit la communication avec le portail Fabric FE via un iFrame. Le portail interagit à son tour avec le back-end Fabric en effectuant des appels à ses API publiques exposées.

Pour les interactions entre la zone de développement BE et Fabric BE, Azure Relay sert de conduit. De plus, la zone de développement back-end s’intègre parfaitement à Lakehouse. La communication est facilitée à l’aide d’Azure Relay et du kit de développement logiciel (SDK) de Fabric installés sur la zone de développement BE.

L’authentification pour toutes les communications au sein de ces composants est assurée via Microsoft Entra. Microsoft Entra fournit un environnement sécurisé et authentifié pour les interactions entre le serveur frontal, le back-end, Azure Relay, le Kit de développement logiciel (SDK) Fabric et Lakehouse.

Prérequis

Kit de développement logiciel (SDK) .NET 7.0
Visual Studio 2022

Vérifiez que le gestionnaire de package NuGet est intégré dans votre installation Visual Studio. Cet outil est nécessaire pour simplifier la gestion des bibliothèques externes et des packages essentiels pour notre projet.

Gestion des packages NuGet

<NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> et <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile> : Ces propriétés spécifient le chemin d’accès aux fichiers NuSpec utilisés pour créer le package NuGet pour les modes Débogage et Mise en production. Le fichier NuSpec contient des métadonnées sur le package, telles que son ID, sa version, ses dépendances et d’autres informations pertinentes.
<GeneratePackageOnBuild>true</GeneratePackageOnBuild> : quand elle a la valeur true, cette propriété indique au processus de génération de générer automatiquement un package NuGet durant chaque génération. Cette propriété est utile pour vous assurer que le package est toujours à jour avec les dernières modifications apportées au projet.
<IsPackable>true</IsPackable> : quand elle a la valeur true, cette propriété indique que le projet peut être placé dans un package NuGet. Le fait de pouvoir être compressé est une propriété essentielle pour les projets destinés à produire des packages NuGet durant le processus de génération.

Le package NuGet généré pour le mode débogage se trouve dans le répertoire src\bin\Debug après le processus de génération.

Quand vous travaillez en mode cloud, vous pouvez changer la configuration de build de Visual Studio en Version, et générer votre package. Le package généré se trouve dans le répertoire src\bin\Release. Pour plus d’informations, consultez le Guide d’utilisation du mode cloud.

Les dépendances

L’exemple Boilerplate de back-end dépend des packages Azure SDK suivants :
- Azure.Core
- Azure.Identity
- Azure. Stockage. Files.DataLake
- La plateforme d’identités Microsoft

Pour configurer le Gestionnaire de package NuGet, spécifiez le chemin d’accès dans la section Sources de package avant de commencer le processus de génération.

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
    <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
    <BuildDependsOn>PreBuild</BuildDependsOn>
    <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
    <IsPackable>true</IsPackable>
  </PropertyGroup>
  
  <PropertyGroup Condition="'$(Configuration)' == 'Release'">
    <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>
  </PropertyGroup>

  <PropertyGroup Condition="'$(Configuration)' == 'Debug'">
    <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Azure.Core" Version="1.38.0" />
    <PackageReference Include="Azure.Identity" Version="1.11.0" />
    <PackageReference Include="Azure.Storage.Files.DataLake" Version="12.14.0" />
    <PackageReference Include="Microsoft.AspNet.WebApi.Client" Version="5.2.9" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="7.0.5" />
    <PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="7.0.0" />
    <PackageReference Include="Microsoft.Identity.Client" Version="4.60.3" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols" Version="6.30.1" />
    <PackageReference Include="Microsoft.IdentityModel.Protocols.OpenIdConnect" Version="6.30.1" />
    <PackageReference Include="Microsoft.IdentityModel.Tokens" Version="6.30.1" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0" />
  </ItemGroup>

  <ItemGroup>
    <Folder Include="Properties\ServiceDependencies\" />
  </ItemGroup>

  <Target Name="PreBuild" BeforeTargets="PreBuildEvent">
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\RemoveErrorFile.ps1 -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ManifestValidator.ps1 -inputDirectory .\Packages\manifest\ -inputXml WorkloadManifest.xml -inputXsd WorkloadDefinition.xsd -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ItemManifestValidator.ps1 -inputDirectory .\Packages\manifest\ -inputXsd ItemDefinition.xsd -outputDirectory ValidationScripts\" />
    <Exec Command="powershell.exe -ExecutionPolicy Bypass -File ValidationScripts\ValidateNoDefaults.ps1 -outputDirectory ValidationScripts\" />
    <Error Condition="Exists('ValidationScripts\ValidationErrors.txt')" Text="Validation errors with either manifests or default values" File="ValidationScripts\ValidationErrors.txt" />
  </Target>

</Project>

Démarrage

Pour configurer l’exemple de projet de charge de travail sur votre machine locale :

Clonez le référentiel : exécutez git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.
Dans Visual Studio 2022, ouvrez la solution.
Configurez une inscription d’application en suivant les instructions du tutoriel sur l’authentification. Vérifiez que vos projets front-end et back-end disposent de la configuration nécessaire décrite dans l’article. Microsoft Entra est utilisé pour l’authentification sécurisée afin de vérifier que toutes les interactions au sein de l’architecture sont autorisées et sécurisées.
Mettez à jour l’URL de base de Microsoft OneLake DFS. En fonction de votre environnement Fabric, vous pouvez éventuellement mettre à jour la valeur de OneLakeDFSBaseURL dans le dossier src\Constants. La valeur par défaut est onelake.dfs.fabric.microsoft.com, mais vous pouvez mettre à jour l’URL pour refléter votre environnement. Pour plus d’informations sur les chemins d’accès DFS, consultez la documentation OneLake.
Préparez la configuration de la charge de travail.
1. Copiez workload-dev-mode.json de src/Config vers C:.
2. Dans le fichier workload-dev-mode.json, mettez à jour les champs suivants en fonction de votre configuration :
  - WorkspaceGuid : ID de votre espace de travail. Vous pouvez trouver cette valeur dans l’URL du navigateur quand vous sélectionnez un espace de travail dans Fabric. Par exemple : https://app.powerbi.com/groups/<WorkspaceID>/.
  - ManifestPackageFilePath : l’emplacement du package de manifeste. Quand vous générez la solution, elle enregistre le package de manifeste dans src\bin\Debug. Davantage d’informations sur le package de manifeste sont fournies plus loin dans l’article.
  - WorkloadEndpointURL : URL du point de terminaison de la charge de travail.
3. Dans le fichier Packages/manifest/WorkloadManifest.xml, mettez à jour les champs suivants en fonction de votre configuration :
  - <AppId> : ID client (ID d’application) de l’application Microsoft Entra de la charge de travail.
  - <RedirectUri> : URI de redirection. Vous trouverez cette valeur dans l’inscription d’application que vous avez créée, sous Authentification.
  - <ResourceId> : participant des jetons Microsoft Entra entrants. Vous trouverez cette information dans l’inscription d’application que vous avez créée, sous Exposer une API.
4. Dans le fichier src/appsettings.json, mettez à jour les champs suivants en fonction de votre configuration :
  - PublisherTenantId : ID du client de l’éditeur de la charge de travail.
  - ClientId : ID client (ID d’application) de l’application Microsoft Entra de la charge de travail.
  - ClientSecret : secret de l’application Microsoft Entra de la charge de travail.
  - Audience : participant des jetons Microsoft Entra entrants. Vous trouverez cette information dans l’inscription d’application que vous avez créée, sous Exposer une API. Ce paramètre est également appelé URI d’ID d’application.
Générez un package de manifeste.

Pour générer un fichier de package de manifeste, générez Fabric_Extension_BE_Boilerplate. La génération est un processus en trois étapes qui permet de générer le fichier de package de manifeste. Ce processus s’effectue selon les étapes suivantes :
1. Déclenche ManifestValidator.ps1 sur WorkloadManifest.xml dans Packages\manifest/, et déclenche ItemManifestValidator.ps1 sur tous les fichiers XML d’éléments (par exemple Item1.xml) dans Packages\manifest/. En cas d’échec de la validation, un fichier d’erreur est généré. Vous pouvez voir les scripts de validation dans ValidationScripts/.
2. Si un fichier d’erreur existe, la génération échoue avec l’erreur Erreurs de validation avec les manifestes ou les valeurs par défaut. Pour voir le fichier d’erreur dans Visual Studio, double-cliquez sur l’erreur dans les résultats de la validation.
3. Une fois la validation réussie, placez les fichiers WorkloadManifest.xml et Item1.xml dans un package nommé ManifestPackage.1.0.0.nupkg. Le package obtenu se trouve dans src\bin\Debug.
Copiez le fichier ManifestPackage.1.0.0.nupkg dans le chemin d’accès défini au sein du fichier config workload-dev-mode.json.
Program.cs sert de point d’entrée et de script de démarrage pour votre application. Dans ce fichier, vous pouvez configurer différents services, initialiser l’application et démarrer l’hôte web.
Générez pour vous assurer que votre projet peut accéder aux dépendances requises pour la compilation et l’exécution.
Téléchargez DevGateway à partir du Centre de téléchargement Microsoft
Exécutez l’application Microsoft.Fabric.Workload.DevGateway.exe, puis connectez-vous avec un compte d’utilisateur disposant de privilèges administratifs sur l’espace de travail spécifié dans le champ WorkspaceGuid de workload-dev-mode.json.

Après l’authentification, les charges de travail externes établissent une communication avec le back-end Fabric via Azure Relay. Ce processus implique l’inscription du relais et la gestion des communications, qui sont facilitées par le nœud de proxy désigné. Le package qui contient le manifeste de charge de travail est chargé et publié.

À ce stade, Fabric détecte la charge de travail, et incorpore la capacité qui lui est allouée.

Vous pouvez effectuer un monitoring des erreurs potentielles dans la console.

Si aucune erreur ne s’affiche, la connexion est établie, l’inscription est exécutée correctement, et le manifeste de charge de travail est systématiquement chargé.
Dans Visual Studio, remplacez votre projet de démarrage par le projet Boilerplate, puis sélectionnez Exécuter.

Utiliser l’exemple de projet Boilerplate

Génération de code

Nous utilisons l’exemple Boilerplate C# ASP.NET Core de charge de travail pour montrer comment créer une charge de travail à l’aide des API REST. L’exemple commence par générer des stubs serveur et des classes de contrat en fonction de la spécification Swagger de l’API de charge de travail. Vous pouvez générer le code à l’aide de l’un des nombreux outils de génération de code Swagger. L’exemple Boilerplate utilise NSwag. L’exemple contient le script de ligne de commande GenerateServerStub.cmd, qui inclut dans un wrapper le générateur de code NSwag. Le script prend un paramètre unique, qui est un chemin d’accès complet au répertoire d’installation NSwag. Il vérifie également la présence du fichier de définition Swagger (swagger.json) et du fichier config (nswag.json) dans le dossier.

L’exécution de ce script produit un fichier C# nommé WorkloadAPI_Generated.cs. Le contenu de ce fichier peut être logiquement divisé en trois parties, comme expliqué dans les sections suivantes.

contrôleurs stub ASP.NET Core

Les classes ItemLifecycleController et JobsController sont des implémentations fines des contrôleurs ASP.NET Core pour deux sous-ensembles de l’API de charge de travail : la gestion de cycle de vie des éléments et les travaux. Ces classes se connectent au pipeline HTTP ASP.NET Core. Elles servent de points d’entrée pour les méthodes d’API définies dans la spécification Swagger. Les classes transfèrent les appels à l’implémentation « réelle » fournie par la charge de travail.

Voici un exemple de la méthode CreateItem :

/// <summary>
/// Called by Microsoft Fabric for creating a new item.
/// </summary>
/// <remarks>
/// Upon item creation Fabric performs some basic validations, creates the item with 'provisioning' state and calls this API to notify the workload. The workload is expected to perform required validations, store the item metadata, allocate required resources, and update the Fabric item metadata cache with item relations and ETag. To learn more see [Microsoft Fabric item update flow](https://updateflow).
/// <br/>
/// <br/>This API should accept [SubjectAndApp authentication](https://subjectandappauthentication).
/// <br/>
/// <br/>##Permissions
/// <br/>Permissions are checked by Microsoft Fabric.
/// </remarks>
/// <param name="workspaceId">The workspace ID.</param>
/// <param name="itemType">The item type.</param>
/// <param name="itemId">The item ID.</param>
/// <param name="createItemRequest">The item creation request.</param>
/// <returns>Successfully created.</returns>
[Microsoft.AspNetCore.Mvc.HttpPost, Microsoft.AspNetCore.Mvc.Route("workspaces/{workspaceId}/items/{itemType}/{itemId}")]
public System.Threading.Tasks.Task CreateItem(System.Guid workspaceId, string itemType, System.Guid itemId, [Microsoft.AspNetCore.Mvc.FromBody] CreateItemRequest createItemRequest)
{

 return _implementation.CreateItemAsync(workspaceId, itemType, itemId, createItemRequest);
}

Accéder à l’implémentation des interfaces

IItemLifecycleController et IJobsController sont des interfaces pour les implémentations « réelles » mentionnées ci-dessus. Ils définissent les mêmes méthodes que les contrôleurs implémentent.

Définition des classes de contrat

Les classes de contrat C# sont des classes utilisées par les API.

Implémentation

L’étape suivante, après la génération du code, consiste à implémenter les interfaces IItemLifecycleController et IJobsController. Dans l’exemple Boilerplate, ItemLifecycleControllerImpl et JobsControllerImpl implémentent ces interfaces.

Par exemple, ce code est l’implémentation de l’API CreateItem :

/// <inheritdoc/>
public async Task CreateItemAsync(Guid workspaceId, string itemType, Guid itemId, CreateItemRequest createItemRequest)
{
 var authorizationContext = await _authenticationService.AuthenticateControlPlaneCall(_httpContextAccessor.HttpContext);
 var item = _itemFactory.CreateItem(itemType, authorizationContext);
 await item.Create(workspaceId, itemId, createItemRequest);
}

Gérer une charge utile d’élément

Plusieurs méthodes d’API acceptent divers types de « charge utile » dans le corps de la demande, ou retournent des charges utiles dans le cadre de la réponse. Par exemple, CreateItemRequest a la propriété creationPayload.

"CreateItemRequest": {
 "description": "Create item request content.",
 "type": "object",
 "additionalProperties": false,
 "required": [ "displayName" ],
 "properties": {
 "displayName": {
  "description": "The item display name.",
  "type": "string",
  "readOnly": false
 },
 "description": {
  "description": "The item description.",
  "type": "string",
  "readOnly": false
 },
 "creationPayload": {
  "description": "Creation payload specific to the workload and item type, passed by the item editor or as Fabric Automation API parameter.",
  "$ref": "#/definitions/CreateItemPayload",
  "readOnly": false
 }
 }
}

Les types de ces propriétés de charge utile sont définis dans la spécification Swagger. Il existe un type dédié pour chaque type de charge utile. Ces types ne définissent aucune propriété spécifique. Ils permettent d’inclure n’importe quelle propriété.

Voici un exemple du type CreateItemPayload :

"CreateItemPayload": {
 "description": "Creation payload specific to the workload and item type.",
 "type": "object",
 "additionalProperties": true
}

Les classes de contrat C# générées sont définies en tant que partial. Elles disposent d’un dictionnaire dont les propriétés sont définies.

Voici un exemple :

/// <summary>
/// Creation payload specific to the workload and item type.
/// </summary>
[System.CodeDom.Compiler.GeneratedCode("NJsonSchema", "13.20.0.0 (NJsonSchema v10.9.0.0 (Newtonsoft.Json v13.0.0.0))")]
public partial class CreateItemPayload
{
 private System.Collections.Generic.IDictionary<string, object> _additionalProperties;

 [Newtonsoft.Json.JsonExtensionData]
 public System.Collections.Generic.IDictionary<string, object> AdditionalProperties
 {
  get { return _additionalProperties ?? (_additionalProperties = new System.Collections.Generic.Dictionary<string, object>()); }
  set { _additionalProperties = value; }
 }
}

Le code peut utiliser ce dictionnaire pour lire et retourner des propriétés. Toutefois, une meilleure approche consiste à définir des propriétés spécifiques en utilisant les types et les noms correspondants. Vous pouvez utiliser la déclaration partial sur les classes générées pour définir efficacement les propriétés.

Par exemple, le fichier CreateItemPayload.cs contient une définition complémentaire de la classe CreateItemPayload.

Dans cet exemple, la définition ajoute la propriété Item1Metadata :

namespace Fabric_Extension_BE_Boilerplate.Contracts.FabricAPI.Workload
{
    /// <summary>
    /// Extend the generated class by adding item-type-specific fields.
    /// In this sample every type will have a dedicated property. Alternatively, polymorphic serialization could be used.
    /// </summary>
    public partial class CreateItemPayload
    {
        [Newtonsoft.Json.JsonProperty("item1Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item1Metadata Item1Metadata { get; init; }
    }
}

Toutefois, si la charge de travail prend en charge plusieurs types d’éléments, la classe CreateItemPayload doit pouvoir gérer différents types de charges utiles de création, à raison d’une charge utile par type d’élément. Vous avez le choix entre deux options. La méthode la plus simple, utilisée dans l’exemple Boilerplate, consiste à définir plusieurs propriétés facultatives, chacune représentant la charge utile de création d’un type d’élément différent. Chaque requête n’a alors qu’un seul de ces jeux de propriétés, selon le type d’élément créé. Vous pouvez également implémenter la sérialisation polymorphe, mais cette option n’est pas illustrée dans l’exemple, car elle n’offre aucun avantage significatif.

Par exemple, pour prendre en charge deux types d’éléments, la définition de classe doit être étendue comme dans l’exemple suivant :

namespace Fabric_Extension_BE_Boilerplate.Contracts.FabricAPI.Workload
{
    public partial class CreateItemPayload
    {
        [Newtonsoft.Json.JsonProperty("item1Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item1Metadata Item1Metadata { get; init; }

        [Newtonsoft.Json.JsonProperty("item2Metadata", Required = Newtonsoft.Json.Required.Default, NullValueHandling = Newtonsoft.Json.NullValueHandling.Ignore)]
        public Item2Metadata Item2Metadata { get; init; }
    } 
}

Remarque

La charge utile envoyée à la charge de travail est générée par le client. Il peut s’agir de l’iFrame de l’éditeur d’éléments ou de l’API REST d’automatisation de Fabric. Le client est responsable de l’envoi de la charge utile correcte et de la correspondance du type d’élément. La charge de travail est responsable de la vérification. Fabric traite cette charge utile comme un objet opaque et le transfère uniquement du client à la charge de travail. De même, pour une charge utile retournée par la charge de travail au client, il incombe à la charge de travail et au client de gérer correctement la charge utile.

Par exemple, ce code montre comment l’implémentation de item1 dans l’exemple Boilerplate gère la charge utile :

protected override void SetDefinition(CreateItemPayload payload)
{
 if (payload == null)
 {
  Logger.LogInformation("No payload is provided for {0}, objectId={1}", ItemType, ItemObjectId);
  _metadata = Item1Metadata.Default.Clone();
  return;
 }

 if (payload.Item1Metadata == null)
 {
  throw new InvalidItemPayloadException(ItemType, ItemObjectId);
 }

 if (payload.Item1Metadata.Lakehouse == null)
 {
  throw new InvalidItemPayloadException(ItemType, ItemObjectId)
   .WithDetail(ErrorCodes.ItemPayload.MissingLakehouseReference, "Missing Lakehouse reference");
 }

 _metadata = payload.Item1Metadata.Clone();
}

Résoudre les problèmes et déboguer

Les sections suivantes expliquent comment résoudre les problèmes de déploiement, et déboguer le code correspondant.

Problèmes connus et résolutions

Obtenez des informations sur les problèmes connus et les moyens de les résoudre.

Clé secrète client manquante

Erreur :

Microsoft.Identity.Client.MsalServiceException : un problème de configuration empêche l’authentification. Sélectionnez l’onglet « Détails » pour le message d’erreur. Vous pouvez modifier la configuration dans le portail inscription d’application. Pour plus d'informations, consultez https://aka.ms/msal-net-invalid-client.

Exception d’origine : AADSTS7000215 : une clé secrète client non valide a été fournie. Vérifiez que le secret envoyé dans la requête correspond bien à la valeur de la clé secrète client, et non à l’ID de clé secrète client pour un secret ajouté au paramètre app_guid de l’application.

Résolution : vérifiez que vous disposez de la clé secrète client appropriée définie dans appsettings.json.

Erreur :

Microsoft.Identity.Client.MsalUiRequiredException : AADSTS65001 : l’utilisateur ou l’administrateur n’a pas consenti à utiliser l’application ayant l’ID <example ID>. Envoyez une demande d’autorisation interactive pour cet utilisateur et cette ressource.

Résolution :

Dans l’éditeur d’éléments, accédez au bas de la page, puis sélectionnez Accéder à la page d’authentification.
Sous Étendues, entrez .default, puis sélectionnez Obtenir le jeton d’accès.
Dans la boîte de dialogue, approuvez la révision.

La création d’éléments échoue en raison de la sélection de la capacité

Erreur :

PriorityPlacement : aucun service principal n’est disponible pour le placement prioritaire. name, guid et workload-name uniquement sont disponibles.

Résolution :

En tant qu’utilisateur, vous avez peut-être uniquement accès à la capacité d’essai. Veillez à utiliser une capacité à laquelle vous avez accès.

Échec de création de fichier avec erreur 404 (NotFound)

Erreur :

Échec de la création d’un fichier pour filePath : 'workspace-id'/'lakehouse-id'/Files/data.json. Le code d’état de la réponse n’indique pas une opération réussie : 404 (NotFound).

Résolution :

Vérifiez que vous utilisez l’URL OneLake DFS qui correspond à votre environnement. Par exemple, si vous utilisez un environnement PPE, remplacez EnvironmentConstants.OneLakeDFSBaseUrl dans Constants.cs par l’URL appropriée.

Déboguer

Quand vous résolvez des problèmes liés à diverses opérations, vous pouvez définir des points d’arrêt dans le code pour analyser et déboguer le comportement. Pour un débogage efficace, suivez ces étapes :

Ouvrez le code dans votre environnement de développement.
Accédez à la fonction gestionnaire d’opérations appropriée (par exemple OnCreateFabricItemAsync pour les opérations CRUD, ou un point de terminaison d’un contrôleur pour les opérations execute).
Placez des points d’arrêt à des lignes spécifiques où vous souhaitez inspecter le code.
Exécuter l’application en mode débogage.
Déclenchez l’opération à partir du front-end à déboguer.

Le débogueur interrompt l’exécution aux points d’arrêt spécifiés pour vous permettre d’examiner les variables, de parcourir le code pas à pas, et d’identifier les problèmes.

Capture d’écran de l’exemple de programme avec des points d’arrêt pour le débogage.

Espace de travail

Si vous connectez un back-end à l’exemple de projet de charge de travail, votre élément doit appartenir à un espace de travail associé à une capacité. Par défaut, l’espace de travail Mon espace de travail n’est pas associé à une capacité. Sinon, vous risquez d’obtenir l’erreur affichée dans la capture d’écran suivante :

Capture d’écran de l’interface utilisateur pour nommer un exemple d’élément de charge de travail.

Passez à un espace de travail nommé. Conservez le nom d’espace de travail par défaut Mon espace de travail.
À partir de l’espace de travail approprié, chargez l’exemple de charge de travail et effectuez les tests :

Collaboration

Nous accueillons les contributions à ce projet. Si vous rencontrez des problèmes ou souhaitez ajouter de nouvelles fonctionnalités, suivez ces étapes :

Dupliquez (fork) le dépôt.
Créez une branche de fonctionnalités ou de corrections de bogues.
Effectuez vos changements, puis commitez-les.
Envoyez ces modifications à votre référentiel dupliqué.
Créez une demande de tirage (pull request) comportant une description claire de vos changements.

Partager via

Implémenter le back-end Microsoft Fabric

Serveur frontal

BackEnd

Azure Relay et DevGateway

Intégration du Lakehouse

Authentification et sécurité

Prérequis

Gestion des packages NuGet

Les dépendances

Démarrage

Utiliser l’exemple de projet Boilerplate

Génération de code

contrôleurs stub ASP.NET Core

Accéder à l’implémentation des interfaces

Définition des classes de contrat

Implémentation

Gérer une charge utile d’élément

Résoudre les problèmes et déboguer

Problèmes connus et résolutions

Clé secrète client manquante

La création d’éléments échoue en raison de la sélection de la capacité

Échec de création de fichier avec erreur 404 (NotFound)

Déboguer

Espace de travail

Collaboration

Commentaires

Ressources supplémentaires

Partager via

Implémenter le back-end Microsoft Fabric

Serveur frontal

BackEnd

Azure Relay et DevGateway

Intégration du Lakehouse

Authentification et sécurité

Prérequis

Gestion des packages NuGet

Les dépendances

Démarrage

Utiliser l’exemple de projet Boilerplate

Génération de code

contrôleurs stub ASP.NET Core

Accéder à l’implémentation des interfaces

Définition des classes de contrat

Implémentation

Gérer une charge utile d’élément

Résoudre les problèmes et déboguer

Problèmes connus et résolutions

Clé secrète client manquante

Erreur lors de la création de l’article en raison du consentement d’administrateur manquant

La création d’éléments échoue en raison de la sélection de la capacité

Échec de création de fichier avec erreur 404 (NotFound)

Déboguer

Espace de travail

Collaboration

Contenu connexe

Commentaires

Ressources supplémentaires