Compartilhar via


Implementar o back-end do Microsoft Fabric

Esta Amostra de repositório de desenvolvimento de carga de trabalho do Microsoft Fabric serve como um ponto de partida para a criação de aplicativos que exigem integração com vários serviços, bem como integração com a plataforma Lakehouse. Este guia ajuda você a configurar o ambiente e os componentes necessários para começar. Este artigo descreve os principais componentes e suas funções na arquitetura.

Front-end

O front-end é onde você gerencia a experiência do usuário (UX) e o comportamento. Ele se comunica com o portal de front-end do Fabric por meio de um iFrame para facilitar a interação perfeita.

Para obter mais informações, consulte Front-end do kit de desenvolvimento de carga de trabalho do Microsoft Fabric.

Back-end

O back-end armazena dados e metadados. Ele usa operações Criar, Ler, Atualizar e Excluir (CRUD) para criar itens e metadados de carga de trabalho e executa trabalhos para preencher dados no armazenamento. A comunicação entre o front-end e o back-end é estabelecida por meio de APIs públicas.

Retransmissão do Azure e DevGateway

A Retransmissão do Azure permite a comunicação entre o ambiente de desenvolvimento local e o back-end do Fabric enquanto opera no modo de desenvolvimento. No modo do desenvolvedor, a carga de trabalho opera na máquina do desenvolvedor.

O utilitário DevGateway tem duas funções:

  • O utilitário manipula o lado da carga de trabalho do canal de Retransmissão do Azure e gerencia o registro da instância local da carga de trabalho com o Fabric no contexto de uma capacidade específica. O DevGateway torna a carga de trabalho acessível em todos os workspaces atribuídos a essa capacidade. O utilitário manipula o cancelamento do registro quando o canal é interrompido.
  • Ele funciona com a Retransmissão do Azure para canalizar chamadas de API de carga de trabalho do Fabric para a carga de trabalho.

As chamadas à API de Controle de Carga de Trabalho são feitas diretamente da carga de trabalho para o Fabric. O canal de Retransmissão do Azure não é necessário para as chamadas.

Integração com o Lakehouse

A arquitetura do kit de desenvolvimento de carga de trabalho integra-se perfeitamente a uma arquitetura lakehouse para operações como salvar, ler e buscar dados. A interação é facilitada por meio da Retransmissão do Azure e do SDK do Fabric, garantindo uma comunicação segura e autenticada. Para obter mais informações, consulte Como trabalhar com dados do cliente.

Autenticação e segurança

O Microsoft Entra ID é usado para autenticação segura, garantindo que todas as interações dentro da arquitetura sejam autorizadas e seguras.

A visão geral do kit de desenvolvimento oferece uma prévia da nossa arquitetura. Para obter mais informações sobre como os projetos são configurados, para diretrizes de autenticação e para começar, consulte os seguintes artigos:

Diagrama mostrando como o SDK do Fabric se integra ao Fabric.

O front-end estabelece comunicação com o portal front-end do Fabric por meio de um iFrame. O portal, por sua vez, interage com o back-end do Fabric fazendo chamadas para suas APIs públicas expostas.

Para interações entre a caixa de desenvolvimento back-end e o back-end do Fabric, a Retransmissão do Azure atua como um condutor. Além disso, a caixa de desenvolvimento de back-end se integra perfeitamente ao Lakehouse. A comunicação é facilitada usando a Retransmissão do Azure e o Software Development Kit (SDK) do Fabric instalado na caixa de desenvolvimento do back-end.

A autenticação para toda a comunicação dentro desses componentes é garantida por meio do Microsoft Entra. O Microsoft Entra fornece um ambiente seguro e autenticado para as interações entre o front-end, o back-end, a Retransmissão do Azure, o SDK do Fabric e o Lakehouse.

Pré-requisitos

Assegure-se de que o Gerenciador de Pacotes NuGet está integrado à instalação do Visual Studio. Essa ferramenta é necessária para o gerenciamento simplificado de bibliotecas externas e pacotes essenciais para o nosso projeto.

Gerenciamento de pacotes NuGet

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> e <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: estas propriedades especificam o caminho para os arquivos NuSpec usados para criar o pacote NuGet para os modos de Depuração e Versão. O arquivo NuSpec contém metadados sobre o pacote, como sua ID, versão, dependências e outras informações relevantes.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: quando definida como true, essa propriedade instrui o processo de build compilação a gerar automaticamente um pacote NuGet durante cada build. Essa propriedade é útil para garantir que o pacote esteja sempre atualizado com as alterações mais recentes no projeto.

  • <IsPackable>true</IsPackable>: quando definido como true, essa propriedade indica que o projeto pode ser empacotado em um pacote NuGet. Ser empacotado é uma propriedade essencial para projetos que se destinam a produzir pacotes NuGet durante o processo de build.

O pacote NuGet gerado para o modo de depuração estará localizado no diretório src\bin\Debug após o processo de build.

Ao trabalhar no modo de nuvem, você pode alterar a configuração de build do Visual Studio para Liberar e compilar seu pacote. O pacote gerado está no diretório src\bin\Release. Para obter mais informações, consulte o guia sobre Como trabalhar no modo em nuvem.

Dependências

  • O boilerplate da amostra de back-end depende dos seguintes pacotes do SDK do Azure:

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • O pacote Microsoft Identity

Para configurar o Gerenciador de Pacotes NuGet, especifique o caminho na seção Códigos-fonte do Pacote antes do processo de build.

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

Introdução

Para configurar o projeto de exemplo de carga de trabalho em seu computador local:

  1. Clonar o repositório: execute git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. No Visual Studio 2022, abra a solução.

  3. Configure um registro do aplicativo seguindo as instruções no Tutorial sobre Autenticação. Verifique se os projetos Front-end e Back-end têm a configuração necessária descrita no guia. O Microsoft Entra ID é usado para autenticação segura, garantindo que todas as interações dentro da arquitetura sejam autorizadas e seguras.

  4. Atualize a URL base do Microsoft OneLake DFS. Dependendo do ambiente do Fabric, você poderá atualizar o valor OneLakeDFSBaseURL na pasta src\Constants. O padrão é onelake.dfs.fabric.microsoft.com, mas você pode atualizar a URL para refletir seu ambiente. Para obter mais informações sobre caminhos DFS, consulte a Documentação do OneLake.

  5. Configure a configuração da carga de trabalho.

    1. Copie workload-dev-mode.json de src/Config para C:.
    2. No arquivo workload-dev-mode.json, atualize os seguintes campos para que correspondam à sua configuração:
      • WorkspaceGuid: a ID do seu workspace. Você pode encontrar esse valor na URL do navegador ao selecionar um workspace no Fabric. Por exemplo, https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: o local do pacote de manifesto. Quando você compilar a solução, ela salvará o pacote de manifesto em src\bin\Debug. Mais informações sobre o pacote de manifesto são fornecidas posteriormente no artigo.
      • WorkloadEndpointURL: URL do ponto de extremidade da carga de trabalho.
    3. No arquivo Packages/manifest/WorkloadManifest.xml, atualize os seguintes campos para que correspondam à sua configuração:
      • <AppId>: ID do cliente (ID do aplicativo) do aplicativo do Microsoft Entra de carga de trabalho.
      • <RedirectUri>: as URIs de redirecionamento Você pode encontrar esse valor no registro de aplicativo que você criou, em Autenticação.
      • <ResourceId>: O público-alvo dos para tokens do Microsoft Entra de entrada. Você pode encontrar essas informações no registro de aplicativo que você criou, em Expor uma API.
    4. No arquivo src/appsettings.json, atualize os seguintes campos para que correspondam à sua configuração:
      • PublisherTenantId: a ID do locatário do fornecedor da carga de trabalho.
      • ClientId: ID do cliente (ID do aplicativo) do aplicativo de carga de trabalho do Microsoft Entra.
      • ClientSecret: o segredo do aplicativo Microsoft Entra da carga de trabalho.
      • Audiência: audiência para os tokens do Microsoft Entra de entrada. Você pode encontrar essas informações no registro de aplicativo que você criou, em Expor uma API. Essa configuração também é chamada de URI da ID do aplicativo.
  6. Gere um pacote de manifesto.

    Para gerar um arquivo de pacote de manifesto, compile Fabric_Extension_BE_Boilerplate. A compilação é um processo de três etapas que gera o arquivo de pacote de manifesto. Ela executa as etapas a seguir:

    1. Dispara ManifestValidator.ps1 em WorkloadManifest.xml em Pacotes\manifesto/ e dispara ItemManifestValidator.ps1 em todos os itens XMLs (por exemplo, Item1.xml) em Pacotes\manifesto/. Se a validação falhar, um arquivo de erro será gerado. Você pode exibir os scripts de validação em ValidationScripts/.
    2. Se houver um arquivo de erro, a compilação falhará com os Erros de validação com manifestos ou valores padrão. Para ver o arquivo de erro no Visual Studio, clique duas vezes no erro nos resultados da validação.
    3. Após a validação bem-sucedida, empacote os arquivos WorkloadManifest.xml e Item1.xml em ManifestPackage.1.0.0.nupkg. O pacote resultante está em src\bin\Debug.

    Copie o arquivo ManifestPackage.1.0.0.nupkg para o caminho definido no arquivo de configuração workload-dev-mode.json.

  7. Program.cs é o ponto de entrada e script de inicialização para o aplicativo. Nesse arquivo, você pode configurar vários serviços, inicializar o aplicativo e iniciar o host da Web.

  8. Crie o build para garantir que seu projeto possa acessar as dependências necessárias para a compilação e a execução.

  9. Baixar o DevGateway no Centro de Download da Microsoft

  10. Execute o aplicativo Microsoft.Fabric.Workload.DevGateway.exe e entre com um usuário que tenha privilégios de administrador de workspace para o workspace especificado no campo WorkspaceGuid de workload-dev-mode.json.

    Captura de telada página de entrada da Microsoft.

    Após a autenticação, as cargas de trabalho externas estabelecem comunicação com o back-end do Fabric por meio da Retransmissão do Azure. Esse processo envolve o registro de retransmissão e o gerenciamento de comunicação, facilitado por um nó de Proxy designado. O pacote que contém o manifesto da carga de trabalho é carregado e publicado.

    Neste estágio, o Fabric detecta a carga de trabalho e incorpora sua capacidade alocada.

    Você pode monitorar possíveis erros no console.

    Se nenhum erro for mostrado, a conexão será estabelecida, o registro será executado com êxito e o manifesto da carga de trabalho será carregado sistematicamente.

    Captura de tela do carregamento da conexão sem erros.

  11. Altere seu projeto de inicialização no Visual Studio para o projeto Boilerplate e selecione Executar.

    Captura de tela da interface do usuário do projeto de inicialização no Visual Studio.

Trabalhar com o projeto Boilerplate de amostra

Geração de código

Usamos a amostra de carga de trabalho Boilerplate C# ASP.NET Core para demonstrar como criar uma carga de trabalho usando APIs REST. A amostra com a geração de stubs de servidor e classes de contrato com base na Especificação de Swagger da API de carga de trabalho. Você pode gerá-los usando qualquer uma das diversas ferramentas de geração de código de Swagger. A amostra de Boilerplate usa NSwag. O exemplo contém o script de linha de comando GenerateServerStub.cmd, que encapsula o gerador de código NSwag. O script usa um único parâmetro: um caminho completo para o diretório de instalação do NSwag. Ele também verifica o arquivo de definição do Swagger (swagger.json) e o arquivo de configuração (nswag.json) na pasta.

A execução do script produz um arquivo C# chamado WorkloadAPI_Generated.cs. O conteúdo desse arquivo pode ser dividido logicamente em três partes, conforme explicado nas próximas seções.

Controladores de stubs ASP.NET Core

As classes ItemLifecycleController e JobsController são implementações finas de controladores ASP.NET Core para dois subconjuntos da API de carga de trabalho: gerenciamento do ciclo de vida do item e trabalhos. Essas classes se conectam ao pipeline HTTP do ASP.NET Core. Eles servem como pontos de entrada para os métodos de API definidos na especificação do Swagger. Elas encaminham chamadas para a implementação "real", fornecida pela carga de trabalho.

Veja um exemplo do métodoCreateItem.

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

Interfaces para implementação de carga de trabalho

IItemLifecycleController e IJobsController são interfaces para as implementações "reais" mencionadas anteriormente. Eles definem os mesmos métodos que os controladores implementam.

Definição das classes de contrato

Classes de contrato C# são classes que as APIs usam.

Implementação

A próxima etapa após a geração de código é implementar as interfaces IItemLifecycleController e IJobsController. Na amostra de Boilerplate ItemLifecycleControllerImpl e JobsControllerImpl implementam essas interfaces.

Por exemplo, este código é a implementação da 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);
}

Manipular um conteúdo de item

Vários métodos de API aceitam vários tipos de "conteúdo" como parte do corpo da solicitação ou os retornam como parte da resposta. Por exemplo, CreateItemRequest tem a propriedade 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
 }
 }
}

Os tipos dessas propriedades de conteúdo são definidos na especificação Swagger. Há um tipo dedicado para cada tipo de carga útil. Esses tipos não definem propriedades específicas e permitem que qualquer propriedade seja incluída.

Veja um exemplo do tipoCreateItemPayload:

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

As classes de contrato C# geradas são definidas como partial. Elas têm um dicionário com propriedades definidas.

Veja um exemplo:

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

O código pode usar esse dicionário para ler e retornar propriedades. No entanto, uma abordagem melhor é definir propriedades específicas com tipos e nomes correspondentes. Você pode usar a declaração partial nas classes geradas para definir propriedades com eficiência.

Por exemplo, o arquivo CreateItemPayload.cs contém uma definição complementar para a classe CreateItemPayload.

Neste exemplo, a definição adiciona a propriedade 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; }
    }
}

No entanto, se a carga de trabalho der suporte a vários tipos de item, a classe CreateItemPayload deverá ser capaz de lidar com diferentes tipos de conteúdo de criação em um por tipo de item. Você tem duas opções. A maneira mais simples, usada pela amostra de Boilerplate, é definir várias propriedades opcionais, cada uma representando a conteúdo de criação para um tipo de item diferente. Cada solicitação tem então apenas um desses conjuntos de propriedades, de acordo com o tipo de item que está sendo criado. Como alternativa, você pode implementar a serialização polimórfica, mas essa opção não é demonstrada no exemplo porque a opção não oferece nenhum benefício significativo.

Por exemplo, para dar suporte a dois tipos de item, a definição de classe deve ser estendida como no exemplo a seguir:

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

Observação

O conteúdo enviada à carga de trabalho é gerada pelo cliente. Pode ser o editor de itens iFrame ou a API REST de Automação do Fabric. O cliente é responsável por enviar a carga correta e corresponder ao tipo de item. A carga de trabalho é responsável pela verificação. O Fabric trata essa carga como um objeto opaco e apenas a transfere do cliente para a carga de trabalho. Da mesma forma, para uma carga que é retornada pela carga de trabalho para o cliente, é responsabilidade da carga de trabalho e do cliente lidar com o conteúdo corretamente.

Por exemplo, esse código mostra como a implementaçãoitem1 da amostra de Boilerplate manipula o conteúdo de forma que:

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

Solucionar problemas e depurar

As próximas seções descrevem como solucionar problemas e depurar sua implantação.

Problemas conhecidos e resolução

Obtenha informações sobre problemas conhecidos e maneiras de resolvê-los.

Segredo do cliente ausente

Erro:

Microsoft.Identity.Client.MsalServiceException: um problema de configuração está impedindo a autenticação. Verifique a mensagem de erro do servidor para obter detalhes. Você pode modificar a configuração no portal de registro de aplicativo. Confira https://aka.ms/msal-net-invalid-client para obter detalhes.

Exceção original: AADSTS7000215: segredo do cliente inválido fornecido. Verifique se o segredo enviado na solicitação é o valor do segredo do cliente e não a ID do segredo do cliente para um segredo adicionado à configuração app_guid do aplicativo.

Resolução: verifique se você tem o segredo do cliente correto definido em appsettings.json.

Erro:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: o usuário ou administrador não consentiu em usar o aplicativo com a ID <example ID>. Envie uma solicitação de autorização interativa para esse usuário e recurso.

Resolução:

  1. No editor de itens, vá para a parte inferior da dor e selecione Acessar a Página de Autenticação.

  2. Em Escopos, insira .default e selecione Obter Token de Acesso.

  3. Na caixa de diálogo, aprove a revisão.

A criação do item falha devido à seleção de capacidade

Erro:

PriorityPlacement: nenhum serviço principal está disponível para o posicionamento de prioridade. Somente name, guid e workload-name estão disponíveis.

Resolução:

Como usuário, você pode ter acesso apenas à capacidade de Avaliação. Certifique-se de usar uma capacidade à qual você tem acesso.

Falha na criação de arquivos com o erro 404 (NotFound)

Erro:

Falha ao criar um arquivo para filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. Erro: o código de status da resposta não indica sucesso: 404 (NotFound).

Resolução:

Verifique se você está trabalhando com a URL DFS do OneLake que se adapta ao seu ambiente. Por exemplo, se você trabalha com um ambiente PPE, altere EnvironmentConstants.OneLakeDFSBaseUrl em Constants.cs para a URL apropriada.

Depurar

Ao realizar a solução de problemas de várias operações, você pode definir pontos de interrupção no código para analisar e depurar o comportamento. Siga estas etapas para uma depuração eficaz:

  1. Abra o código no ambiente de desenvolvimento.
  2. Vá para a função de manipulador de operação relevante (por exemplo, OnCreateFabricItemAsync para operações CRUD ou um ponto de extremidade em um controlador para operações execute).
  3. Coloque pontos de interrupção em linhas específicas em que você deseja inspecionar o código.
  4. Execute o aplicativo no modo de depuração.
  5. Dispare a operação do front-end que você deseja depurar.

O depurador pausa a execução nos pontos de interrupção especificados para que você possa examinar variáveis, percorrer o código e identificar problemas.

Captura de tela do programa de exemplo com pontos de interrupção para depuração.

Workspace

Se você estiver conectando um back-end ao projeto de carga de trabalho de exemplo, seu item deverá pertencer a um workspace associado a uma capacidade. Por padrão, o workspace Meu Workspace não está associado a uma capacidade. Caso contrário, você poderá obter o erro mostrado na seguinte captura de tela:

Captura de tela da interface do usuário para nomear um item de carga de trabalho de exemplo.

  1. Alterne para um workspace nomeado. Deixe o nome do workspace como o padrão Meu workspace.

    Captura de tela da interface do usuário para criar uma carga de trabalho de exemplo.

  2. No espaço de trabalho correto, carregue a carga de trabalho de exemplo e prossiga com os testes:

    Captura de tela da interface do usuário para criar um item de carga de trabalho de exemplo.

Contribuir

Agradecemos as contribuições para esse projeto. Se você encontrar algum problema ou quiser adicionar recursos, siga estas etapas:

  1. Crie fork do repositório.
  2. Crie um branch para seu recurso ou correção de bug.
  3. Faça suas alterações e confirme-as.
  4. Envie essas alterações por push para o repositório para o qual você criou o fork.
  5. Crie uma pull request com uma descrição clara das alterações.