Condividi tramite

Implementare il back-end di Microsoft Fabric

  • Articolo

Questo repository di esempio di sviluppo del carico di lavoro di Microsoft Fabric è un punto di partenza per la creazione di applicazioni che richiedono l'integrazione con vari servizi e per l'integrazione con l'architettura lakehouse. Questo articolo illustra come configurare l'ambiente e configurare i componenti necessari per iniziare. L'articolo illustra i componenti chiave e i relativi ruoli nell'architettura.

Front-end

Il front-end consente di gestire l'esperienza utente e il comportamento. Comunica con il portale front-end di Fabric tramite un iFrame per facilitare l'interazione senza problemi.

Per altre informazioni, vedere front-end di Microsoft Fabric Workload Development Kit.

Back-end

Il back-end archivia sia i dati che i metadati. Usa operazioni di creazione, lettura, aggiornamento ed eliminazione (CRUD) per creare elementi e metadati del carico di lavoro ed esegue processi per popolare i dati nell'archiviazione. La comunicazione tra il front-end e il back-end viene stabilita tramite LE API pubbliche.

Inoltro di Azure e DevGateway

Inoltro di Azure consente la comunicazione tra l'ambiente di sviluppo locale e il back-end fabric in modalità sviluppatore. In modalità sviluppatore, il carico di lavoro opera nel computer dello sviluppatore.

L'utilità DevGateway ha due ruoli:

  • Gestisce l'aspetto del carico di lavoro del Relay di Azure e si occupa della registrazione dell'istanza locale del carico di lavoro con Fabric nel contesto di uno specifico spazio di lavoro. L'utilità gestisce la dereregistrazione quando il canale si disconnette.
  • Funziona con Inoltro di Azure per indirizzare le chiamate API del carico di lavoro da Fabric al carico di lavoro.

Le chiamate API di controllo del carico di lavoro vengono effettuate direttamente dal carico di lavoro all'infrastruttura. Il canale di inoltro di Azure non è necessario per le chiamate.

Integrazione di Lakehouse

L'architettura del kit di sviluppo del carico di lavoro si integra perfettamente con un'architettura lakehouse per operazioni come il salvataggio, la lettura e il recupero dei dati. L'interazione viene facilitata tramite Inoltro di Azure e Fabric SDK per garantire la sicurezza e l'autenticazione delle comunicazioni. Per altre informazioni, vedere Uso dei dati dei clienti.

Autenticazione e sicurezza

Microsoft Entra ID viene usato per l'autenticazione sicura, garantendo che tutte le interazioni all'interno dell'architettura siano autorizzate e sicure.

La panoramica del kit di sviluppo offre un'occhiata all'architettura. Per altre informazioni sulla configurazione dei progetti, per le linee guida per l'autenticazione e per iniziare, vedere gli articoli seguenti:

Diagramma che mostra come Fabric SDK si integra con Fabric.

Il front-end stabilisce la comunicazione con il portale front-end di Fabric tramite un iFrame. Il portale interagisce a sua volta con il back-end di Fabric effettuando chiamate alle API pubbliche esposte.

Per le interazioni tra la casella di sviluppo back-end e il back-end Fabric, l'inoltro di Azure funge da canale. Inoltre, la casella di sviluppo back-end si integra perfettamente con Lakehouse. La comunicazione è facilitata usando Inoltro di Azure e Fabric Software Development Kit (SDK) installato nella casella di sviluppo back-end.

L'autenticazione per tutte le comunicazioni all'interno di questi componenti viene garantita tramite Microsoft Entra. Microsoft Entra offre un ambiente sicuro e autenticato per le interazioni tra front-end, back-end, Inoltro di Azure, Fabric SDK e Lakehouse.

Prerequisiti

Assicurarsi che Gestione pacchetti NuGet sia integrato nell'installazione di Visual Studio. Questo strumento è necessario per una gestione semplificata di librerie esterne e pacchetti essenziali per il progetto.

Gestione pacchetti NuGet

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> e <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: queste proprietà specificano il percorso dei file NuSpec usati per la creazione del pacchetto NuGet per le modalità debug e rilascio. Il file NuSpec contiene metadati relativi al pacchetto, ad esempio ID, versione, dipendenze e altre informazioni pertinenti.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: se impostato su true, questa proprietà indica al processo di compilazione di generare automaticamente un pacchetto NuGet durante ogni compilazione. Questa proprietà è utile per far sì che il pacchetto sia sempre aggiornato con le modifiche più recenti nel progetto.

  • <IsPackable>true</IsPackable>: se impostato su true, questa proprietà indica che il progetto può essere inserito in un pacchetto NuGet. La creazione di pacchetti è una proprietà essenziale per i progetti destinati a produrre pacchetti NuGet durante il processo di compilazione.

Il pacchetto NuGet generato per la modalità di debug si trova nella directory src\bin\Debug dopo il processo di compilazione.

Quando si lavora in modalità cloud, è possibile modificare la configurazione di compilazione di Visual Studio in Rilascio e compilare il pacchetto. Il pacchetto generato si trova nella directory src\bin\Release. Per altre informazioni, vedere Guida all'uso della modalità cloud.

Dipendenze

  • L'esempio Boilerplate back-end dipende dai pacchetti di Azure SDK seguenti:

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • Pacchetto Microsoft Identity

Per configurare Gestione pacchetti NuGet, specificare il percorso nella sezione Origini pacchetti prima di iniziare il processo di compilazione.

<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>

Operazioni preliminari

Per configurare il progetto di esempio del carico di lavoro nel computer locale:

  1. Clonare il repository: eseguire git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. In Visual Studio 2022 aprire la soluzione.

  3. Configurare una registrazione dell'app seguendo le istruzioni riportate nell'esercitazione sull'autenticazione. Assicurarsi che i progetti front-end e back-end abbiano la configurazione necessaria descritta nell'articolo. Microsoft Entra viene usato per l'autenticazione sicura per garantire che tutte le interazioni all'interno dell'architettura siano autorizzate e sicure.

  4. Aggiornare l'URL di base di Microsoft OneLake DFS. A seconda dell'ambiente fabric, potrebbe essere possibile aggiornare il valore per OneLakeDFSBaseURL nella cartella src\Constants . Il valore predefinito è onelake.dfs.fabric.microsoft.com, ma è possibile aggiornare l'URL in modo da riflettere l'ambiente. Per altre informazioni sui percorsi DFS, vedere la documentazione di OneLake.

  5. Configurare la configurazione del carico di lavoro.

    1. Copiare workload-dev-mode.json da src/Config a C:.
    2. Nel file workload-dev-mode.json aggiornare i campi seguenti in modo che corrispondano alla configurazione:
      • WorkspaceGuid: ID dell'area di lavoro. È possibile trovare questo valore nell'URL del browser quando si seleziona un'area di lavoro in Infrastruttura. Ad esempio: https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: percorso del pacchetto manifesto. Quando si compila la soluzione, il pacchetto manifesto viene salvato in src\bin\Debug. Altre informazioni sul pacchetto manifesto sono disponibili più avanti nell'articolo.
      • WorkloadEndpointURL: URL dell'endpoint del carico di lavoro.
    3. Nel file Packages/manifest/WorkloadManifest.xml aggiornare i campi seguenti in modo che corrispondano alla configurazione:
      • <AppId>: ID client (ID applicazione) dell'applicazione Microsoft Entra del carico di lavoro.
      • <RedirectUri>: URI di reindirizzamento. È possibile trovare questo valore nella registrazione dell'app creata, in Autenticazione.
      • <ResourceId>: il gruppo di destinatari per i token Microsoft Entra in ingresso. Queste informazioni sono disponibili nella registrazione dell'app creata, in Esporre un'API.
    4. Nel file src/appsettings.json aggiornare i campi seguenti in modo che corrispondano alla configurazione:
      • PublisherTenantId: ID del tenant del server di pubblicazione del carico di lavoro.
      • ClientId: ID client (ID applicazione) dell'applicazione Microsoft Entra del carico di lavoro.
      • ClientSecret: il segreto usato per l'app Microsoft Entra del carico di lavoro.
      • Destinatari: destinatari per i token Microsoft Entra in ingresso. Queste informazioni sono disponibili nella registrazione dell'app creata, in Esporre un'API. Questa impostazione è detta anche URI ID applicazione.

  6. Generare un pacchetto manifesto.

    Per generare un file di pacchetto manifesto, compilare Fabric_Extension_BE_Boilerplate. La compilazione è un processo in tre passaggi che genera il file del pacchetto manifesto. Esegue questi passaggi:

    1. Attiva ManifestValidator.ps1 in WorkloadManifest.xml in Packages\manifest/ e attiva ItemManifestValidator.ps1 in tutti gli elementi XMLs (ad esempio, Item1.xml) in Packages\manifest/. Se la convalida ha esito negativo, viene generato un file di errore. È possibile visualizzare gli script di convalida in ValidationScripts/.
    2. Se esiste un file di errore, la compilazione non riesce con gli errori di convalida con manifesti o valori predefiniti. Per visualizzare il file di errore in Visual Studio, fare doppio clic sull'errore nei risultati della convalida.
    3. Dopo la convalida, creare un pacchetto dei file WorkloadManifest.xml e Item1.xml in ManifestPackage.1.0.0.nupkg. Il pacchetto risultante si trova in src\bin\Debug.

    Copiare il file ManifestPackage.1.0.0.nupkg nel percorso definito nel file di configurazione workload-dev-mode.json .

  7. Program.cs è il punto di ingresso e lo script di avvio per l'applicazione. In questo file, è possibile configurare vari servizi, inizializzare l'applicazione e avviare l'host Web.

  8. Eseguire la build per assicurarsi che il progetto possa accedere alle dipendenze necessarie per la compilazione e l'esecuzione.

  9. Scaricare DevGateway dall'Area download Microsoft

  10. Eseguire l'applicazione Microsoft.Fabric.Workload.DevGateway.exe e accedere con un utente con privilegi di amministratore dell'area di lavoro per l'area di lavoro specificata nel WorkspaceGuid campo di workload-dev-mode.json.

    Screenshot della pagina di accesso di Microsoft.

    Dopo l'autenticazione, i carichi di lavoro esterni stabiliscono la comunicazione con il back-end di Fabric tramite Inoltro di Azure. Questo processo comporta la registrazione e la gestione delle comunicazioni di inoltro facilitata da un nodo proxy designato. Il pacchetto che contiene il manifesto del carico di lavoro viene caricato e pubblicato.

    In questa fase Fabric rileva il carico di lavoro e incorpora la capacità allocata.

    È possibile monitorare la presenza di potenziali errori nella console.

    Se non vengono visualizzati errori, viene stabilita la connessione, la registrazione viene eseguita correttamente e il manifesto del carico di lavoro viene caricato sistematicamente.

    Screenshot del caricamento della connessione senza errori.

  11. In Visual Studio modificare il progetto di avvio nel progetto Boilerplate e selezionare Esegui.

    Screenshot dell'interfaccia utente per il progetto di avvio in Visual Studio.

Usare il progetto di esempio Boilerplate

Generazione codice

Viene usato l'esempio Boilerplate C# ASP.NET Core del carico di lavoro per illustrare come creare un carico di lavoro usando le API REST. L'esempio inizia con la generazione di stub server e classi di contratto in base alla specifica Swagger dell'API workload. È possibile generare il codice usando uno dei diversi strumenti di generazione del codice Swagger. L'esempio Boilerplate usa NSwag. L'esempio contiene lo script della riga di comando GenerateServerStub.cmd , che esegue il wrapping del generatore di codice NSwag. Lo script accetta un unico parametro, ovvero un percorso completo della directory di installazione di NSwag. Controlla anche la presenza del file di definizione Swagger (swagger.json) e del file di configurazione (nswag.json) nella cartella .

L'esecuzione di questo script genera un file C# denominato WorkloadAPI_Generated.cs. Il contenuto di questo file può essere suddiviso logicamente in tre parti, come illustrato nelle sezioni successive.

Controller stub ASP.NET Core

ItemLifecycleController le classi e JobsController sono implementazioni sottili di ASP.NET controller Core per due subset dell'API del carico di lavoro: gestione del ciclo di vita degli elementi e processi. Queste classi si collegano alla pipeline HTTP di ASP.NET Core. Fungono da punti di ingresso per i metodi API definiti nella specifica Swagger. Le classi inoltrano le chiamate all'implementazione "reale" fornita dal carico di lavoro.

Ecco un esempio del CreateItem metodo :

/// <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);
}

Interfacce per l'implementazione dei carichi di lavoro

IItemLifecycleController e IJobsController sono interfacce per le implementazioni "reali" indicate in precedenza. Definiscono gli stessi metodi implementati dai controller.

Definizione delle classi di contratto

Le classi di contratto C# sono classi usate dalle API.

Implementazione

Il passaggio successivo dopo la generazione di codice implementa le IItemLifecycleController interfacce e IJobsController . Nell'esempio ItemLifecycleControllerImpl Boilerplate e JobsControllerImpl implementare queste interfacce.

Ad esempio, questo codice è l'implementazione dell'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);
}

Gestire un payload di un elemento

Diversi metodi API accettano vari tipi di "payload" come parte del corpo della richiesta o restituiscono payload come parte della risposta. Ad esempio, CreateItemRequest ha la creationPayload proprietà .

"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
 }
 }
}

I tipi per queste proprietà del payload sono definiti nella specifica Swagger. Esiste un tipo dedicato per ogni genere di payload. Questi tipi non definiscono proprietà specifiche e consentono l'inserimento di qualsiasi proprietà.

Ecco un esempio del CreateItemPayload tipo:

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

Le classi di contratto C# generate vengono definite come partial. Hanno un dizionario con proprietà definite.

Ecco un esempio:

/// <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; }
 }
}

Il codice può usare questo dizionario per leggere e restituire proprietà. Tuttavia, un approccio migliore consiste nel definire proprietà specifiche usando i tipi e i nomi corrispondenti. È possibile usare la dichiarazione nelle partial classi generate per definire in modo efficiente le proprietà.

Ad esempio, il file CreateItemPayload.cs contiene una definizione complementare per la CreateItemPayload classe .

In questo esempio la definizione aggiunge la Item1Metadata proprietà :

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; }
    }
}

Tuttavia, se il carico di lavoro supporta più tipi di elementi, la CreateItemPayload classe deve essere in grado di gestire diversi tipi di payload di creazione in un singolo tipo di elemento. Hai due opzioni. Il modo più semplice, usato nell'esempio Boilerplate, consiste nel definire più proprietà facoltative, ognuna che rappresenta il payload di creazione per un tipo di elemento diverso. Ogni richiesta ha quindi solo uno di questi set di proprietà, in base al tipo di elemento creato. In alternativa, è possibile implementare la serializzazione polimorfica, ma questa opzione non viene illustrata nell'esempio perché l'opzione non offre alcun vantaggio significativo.

Ad esempio, per supportare due tipi di elemento, la definizione della classe deve essere estesa come nell'esempio seguente:

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; }
    } 
}

Nota

Il payload inviato al carico di lavoro viene generato dal client. Può essere l'editor di elementi iFrame o l'API REST di Automazione infrastruttura. Il client è responsabile dell'invio del payload corretto e della corrispondenza del tipo di elemento. Il carico di lavoro è responsabile della verifica. Fabric considera questo payload come oggetto opaco e lo trasferisce solo dal client al carico di lavoro. Analogamente, per un payload restituito dal carico di lavoro al client, è responsabilità del carico di lavoro e del client gestire correttamente il payload.

Ad esempio, questo codice mostra come l'implementazione di Boilerplate sample item1 gestisce il payload:

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();
}

Risolvere i problemi ed eseguire il debug

Le sezioni successive descrivono come risolvere i problemi ed eseguire il debug della distribuzione.

Problemi noti e soluzioni

Ottenere informazioni sui problemi noti e sui modi per risolverli.

Segreto client mancante

Errore:

Microsoft.Identity.Client.MsalServiceException: un problema di configurazione impedisce l'autenticazione. Controllare il messaggio di errore del serve per verificare i dettagli. È possibile modificare la configurazione nel portale di le registrazione dell'applicazione. Per informazioni dettagliate, vedere https://aka.ms/msal-net-invalid-client.

Eccezione originale: AADSTS7000215: è stato fornito un segreto client non valido. Assicurarsi che il segreto inviato nella richiesta sia il valore del segreto client e non l'ID segreto client per un segreto aggiunto all'impostazione dell'app app_guid .

Soluzione: assicurarsi di avere il segreto client corretto definito in appsettings.json.

Errore:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: l'utente o l'amministratore non ha fornito il consenso per l'uso dell'applicazione con ID <example ID>. Inviare una richiesta di autorizzazione interattiva per questo utente e questa risorsa.

Risoluzione:

  1. Nell'editor di elementi passare alla parte inferiore del dolore e selezionare Passa alla pagina Autenticazione.

  2. In Ambiti immettere .default e quindi selezionare Recupera token di accesso.

  3. Nella finestra di dialogo approvare la revisione.

La creazione dell'elemento non riesce a causa della selezione della capacità

Errore:

PriorityPlacement: nessun servizio principale è disponibile per la selezione della priorità. Sono disponibili solo name, guide workload-name .

Risoluzione:

Gli utenti possono avere accesso solo alla capacità di valutazione. Assicurarsi di usare una capacità a cui si ha accesso.

Errore di creazione del file con errore 404 (NotFound)

Errore:

Impossibile creare un nuovo file per filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. Il codice di stato della risposta non indica l'esito positivo: 404 (NotFound).

Risoluzione:

Assicurarsi di usare l'URL DFS di OneLake adatto all'ambiente. Ad esempio, se si lavora con un ambiente DPI, passare EnvironmentConstants.OneLakeDFSBaseUrl Constants.cs all'URL appropriato.

Debug

Quando si risolvono varie operazioni, è possibile impostare punti di interruzione nel codice per analizzare ed eseguire il debug del comportamento. Per eseguire il debug efficace, seguire questa procedura:

  1. Aprire il codice nell'ambiente di sviluppo.
  2. Passare alla funzione del gestore dell'operazione pertinente, OnCreateFabricItemAsync ad esempio per le operazioni CRUD o un endpoint in un controller per execute le operazioni.
  3. Posizionare punti di interruzione in righe specifiche in cui si desidera esaminare il codice.
  4. Eseguire l'applicazione in modalità di debug.
  5. Attivare l'operazione dal front-end di cui si vuole eseguire il debug.

Il debugger sospende l'esecuzione in corrispondenza dei punti di interruzione specificati in modo da poter esaminare le variabili, esaminare il codice e identificare i problemi.

Screenshot del programma di esempio con punti di interruzione per il debug.

Area di lavoro

Se si sta connettendo un back-end al progetto di carico di lavoro di esempio, l'elemento deve appartenere a un'area di lavoro associata a una capacità. Per impostazione predefinita, l'area di lavoro personale non è associata a una capacità. In caso contrario, è possibile che venga visualizzato l'errore illustrato nello screenshot seguente:

Screenshot dell'interfaccia utente per la denominazione di un elemento del carico di lavoro di esempio.

  1. Passare a un'area di lavoro denominata. Lasciare il nome dell'area di lavoro predefinito Area di lavoro personale.

    Screenshot dell'interfaccia utente per la creazione di un carico di lavoro di esempio.

  2. Dall'area di lavoro corretta, caricare il carico di lavoro di esempio e procedere con i test:

    Screenshot dell'interfaccia utente per la creazione di un elemento del carico di lavoro di esempio.

Contribuisci

Accogliamo volentieri i contributi a questo progetto. Se si verificano problemi o si vogliono aggiungere nuove funzionalità, seguire questa procedura:

  1. Creare una copia tramite fork del repository.
  2. Creare un nuovo ramo per la funzionalità o la correzione di bug.
  3. Apportare le modifiche e quindi eseguirne il commit.
  4. Eseguire il push delle modifiche nel repository di cui è stata creata una copia tramite fork.
  5. Creare una richiesta pull con una descrizione chiara delle modifiche.

Contenuto correlato