Compartir a través de

Implementación del back-end de Microsoft Fabric

  • Artículo

Este repositorio de muestra para desarrollo de cargas de trabajo de Microsoft Fabric es un punto inicial para crear aplicaciones que requieran integración con varios servicios y para la integración con la arquitectura de almacén de lago de datos. Este artículo le ayuda a configurar el entorno y a configurar los componentes necesarios para comenzar. En el artículo se describen los componentes clave y sus roles en la arquitectura.

Front-end

El front-end es donde se administra la experiencia del usuario (UX) y el comportamiento. Se comunica con el portal de front-end de Fabric a través de un iFrame para facilitar una interacción perfecta.

Para más información, consulte el front-end del Kit de desarrollo de cargas de trabajo de Microsoft Fabric.

Back-end

El back-end almacena los datos y los metadatos. Usa operaciones de Creación, lectura, actualización y eliminación (CRUD) para crear elementos y metadatos de carga de trabajo, y ejecuta trabajos para rellenar los datos en el almacenamiento. La comunicación entre el front-end y el back-end se establece a través de las API públicas.

Azure Relay y DevGateway

Azure Relay permite la comunicación entre el entorno de desarrollo local y el back-end de Fabric mientras en modo para desarrolladores. En el modo para desarrolladores, la carga de trabajo funciona en la máquina del desarrollador.

La utilidad DevGateway tiene dos roles:

  • Controla el lado de la carga de trabajo del canal de Azure Relay y administra el registro de la instancia local de carga de trabajo con Fabric en el contexto de un área de trabajo específica. La utilidad maneja la cancelación de registro cuando el canal se desconecta.
  • Funciona con Azure Relay para canalizar las llamadas de API de carga de trabajo desde Fabric a la carga de trabajo.

Las llamadas de API de control de carga de trabajo se realizan directamente desde la carga de trabajo a Fabric. El canal de Azure Relay no es necesario para las llamadas.

Integración de Lakehouse

La arquitectura del kit de desarrollo de cargas de trabajo se integra perfectamente con una arquitectura de almacén de lago de datos para operaciones como guardar, leer y capturar datos. La interacción se facilita a través de Azure Relay y el SDK de Fabric, para ayudar a garantizar una comunicación segura y autenticada. Para obtener más información, consulte la información sobre cómo trabajar con datos de clientes.

Autenticación y seguridad

Microsoft Entra ID se utiliza para la autenticación segura, lo que garantiza que todas las interacciones dentro de la arquitectura están autorizadas y seguras.

La introducción al kit de desarrollo proporciona una visión general de nuestra arquitectura. Para obtener más información sobre cómo se configuran los proyectos, para obtener instrucciones de autenticación y para empezar, consulte los artículos siguientes:

Diagrama en el que se muestra cómo se integra el SDK de Fabric en Fabric.

El front-end establece la comunicación con el portal de front-end de Fabric a través de un IFrame. A su vez, el portal interactúa con el back-end de Fabric realizando llamadas a sus API públicas expuestas.

Para las interacciones entre el cuadro de desarrollo del back-end y el back-end de Fabric, Azure Relay actúa como conducto. Además, el cuadro de desarrollo de back-end se integra perfectamente con Lakehouse. La comunicación se facilita mediante Azure Relay y el Kit de desarrollo de software (SDK) de Fabric instalados en el cuadro de desarrollo del back-end.

La autenticación de todas las comunicaciones dentro de estos componentes se garantiza a través de Microsoft Entra. Microsoft Entra proporciona un entorno seguro y autenticado para las interacciones entre el front-end, el back-end, Azure Relay, el SDK de Fabric y Lakehouse.

Requisitos previos

Asegúrese de que el administrador de paquetes NuGet está integrado en la instalación de Visual Studio. Esta herramienta es necesaria para la administración simplificada de bibliotecas externas y paquetes esenciales para nuestro proyecto.

Administración de paquetes NuGet

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> y <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: estas propiedades especifican la ruta de acceso a los archivos NuSpec usados para crear el paquete NuGet para los modos de depuración y lanzamiento. El archivo NuSpec contiene metadatos sobre el paquete, como su identificador, versión, dependencias y otra información relevante.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: cuando se establece en true, esta propiedad indica al proceso de compilación que genere de forma automática un paquete NuGet durante cada compilación. Esta propiedad es útil para garantizar que el paquete esté siempre actualizado con los cambios más recientes del proyecto.

  • <IsPackable>true</IsPackable>: cuando se establece en true, esta propiedad indica que el proyecto es empaquetable en un paquete NuGet. Ser empaquetable es una propiedad esencial para los proyectos diseñados para generar paquetes NuGet durante el proceso de compilación.

El paquete NuGet generado para el modo de depuración se encuentra en el directorio src\bin\Debug después del proceso de compilación.

Al trabajar en modo de nube, puede cambiar la configuración de compilación de Visual Studio a Versión y compilar su paquete. El paquete generado se encuentra en el directorio src\bin\Release. Para obtener más información, consulte la Guía para trabajar en modo de nube.

Dependencias

  • El ejemplo reutilizable del back-end depende de los siguientes paquetes de SDK de Azure:

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • El paquete de identidad de Microsoft

Para configurar el Administrador de paquetes de NuGet, especifique la ruta de acceso en la sección Orígenes de paquetes antes de empezar el proceso de compilación.

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

Introducción

Para configurar el proyecto de carga de trabajo de ejemplo en la máquina local:

  1. Clone el repositorio: ejecute git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. En Visual Studio 2022, abra la solución.

  3. Configure el registro de una aplicación mediante las instrucciones del tutorial de autenticación. Asegúrese de que los proyectos de front-end y back-end tengan la configuración necesaria que se describe en el artículo. Microsoft Entra se utiliza para la autenticación segura, para ayudar a garantizar que todas las interacciones dentro de la arquitectura están autorizadas y seguras.

  4. Actualice la dirección URL base de Microsoft OneLake DFS. Según el entorno de Fabric, es posible que pueda actualizar el valor de OneLakeDFSBaseURL en la carpeta src\Constants. El valor predeterminado es onelake.dfs.fabric.microsoft.com, pero puede actualizar la dirección URL para reflejar el entorno. Para obtener más información sobre las rutas de acceso DFS, consulte la documentación de OneLake.

  5. Configure la configuración de la carga de trabajo.

    1. Copie workload-dev-mode.json de src/Config a C:.
    2. En el archivo workload-dev-mode.json, actualice los siguientes campos para que coincidan con su configuración:
      • WorkspaceGuid: identificador del área de trabajo. Puede encontrar este valor en la dirección URL del explorador al seleccionar un área de trabajo en Fabric. Por ejemplo, https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: ubicación del paquete de manifiesto. Cuando cree la solución, se guardará el paquete de manifiesto en src\bin\Debug. Se proporciona más información sobre el paquete de manifiesto más adelante en el artículo.
      • WorkloadEndpointURL: dirección URL del punto de conexión de carga de trabajo.
    3. En el archivo Packages/manifest/WorkloadManifest.xml, actualice los siguientes campos para que coincidan con su configuración:
      • <AppId>: id. de cliente (id. de Aplicación) de la aplicación de Microsoft Entra para la carga de trabajo.
      • <RedirectUri>: URI de redirección. Puede encontrar este valor en el registro de la aplicación que creó, en Autenticación.
      • <ResourceId>: audiencia para los tokens entrantes de Microsoft Entra. Puede encontrar esta información en el registro de la aplicación que creó, en Exponer una API.
    4. En el archivo src/appsettings.json, actualice los siguientes campos para que coincidan con su configuración:
      • PublisherTenantId: id. del inquilino del publicador de la carga de trabajo.
      • ClientId: id. de cliente (id. de Aplicación) de la aplicación de Microsoft Entra para la carga de trabajo.
      • ClientSecret: secreto de cliente para la aplicación de Microsoft Entra de la carga de trabajo.
      • Audiencia: audiencia para los tokens entrantes de Microsoft Entra. Puede encontrar esta información en el registro de la aplicación que creó, en Exponer una API. Esta configuración también se denomina URI de identificador de aplicación.

  6. Genere un paquete de manifiesto.

    Para generar un archivo de paquete de manifiesto, compile Fabric_Extension_BE_Boilerplate. Esto compila un proceso de tres pasos que genera el archivo de paquete de manifiesto. Ejecuta estos pasos:

    1. Desencadena ManifestValidator.ps1 en WorkloadManifest.xml en Packages\manifest/ y desencadena ItemManifestValidator.ps1 en los archivos XML de todos los elementos (por ejemplo, Item1.xml) en Packages\manifest/. Si la validación falla, se genera un archivo de error. Puede ver los scripts de validación en ValidationScripts/.
    2. Si existe un archivo de error, la compilación produce un error de tipo Errores de validación con manifiestos o valores predeterminados. Para ver el archivo de error en Visual Studio, haga doble clic en el error en los resultados de validación.
    3. Después de la validación correcta, empaquete los archivos WorkloadManifest.xml e Item1.xml en ManifestPackage.1.0.0.nupkg. El paquete resultante es src\bin\Debug.

    Copie el archivo ManifestPackage.1.0.0.nupkg en la ruta definida en el archivo de configuración workload-dev-mode.json.

  7. Program.cs es el punto de entrada y script de inicio para su aplicación. En este archivo , puede configurar varios servicios , inicializar la aplicación, e iniciar el host web.

  8. Compile para asegurarse de que su proyecto puede acceder a las dependencias necesarias para la compilación y ejecución.

  9. Descargue el DevGateway desde el Centro de descarga de Microsoft.

  10. Ejecute la aplicación Microsoft.Fabric.Workload.DevGateway.exe e inicie sesión con un usuario que tenga privilegios de administrador del área de trabajo para el área de trabajo especificada en el campo WorkspaceGuid de workload-dev-mode.json.

    Captura de pantalla de la página de inicio de sesión de Microsoft.

    Después de la autenticación, las cargas de trabajo externas establecen la comunicación con el back-end de Fabric a través de Azure Relay. Este proceso implica el registro de la retransmisión y la administración de la comunicación, facilitada por un nodo proxy designado. Se carga y se publica el paquete que contiene el manifiesto de la carga de trabajo.

    En esta fase, Fabric detecta la carga de trabajo e incorpora su capacidad asignada.

    Puede supervisar si hay posibles errores en la consola.

    Si no aparecen errores, la conexión se ha establecido, que el registro se ejecuta correctamente y que el manifiesto de la carga de trabajo se cargó sistemáticamente.

    Captura de pantalla de la carga de la conexión sin errores.

  11. En Visual Studio, cambie el proyecto de inicio por el proyecto reutilizable y seleccione Ejecutar.

    Captura de pantalla del proyecto UI para startup en Visual Studio.

Trabajar con el proyecto de ejemplo reutilizable

Generación de código

Utilizamos el ejemplo reutilizable de C# de carga de trabajo ASP.NET Core para demostrar cómo crear una carga de trabajo con las API REST. El ejemplo comienza con la generación de stubs de servidor y clases de contrato basadas en la especificación Swagger de la API de carga de trabajo. Puede generar el código mediante cualquiera de las herramientas de generación de código de Swagger. El ejemplo reutilizable usa NSwag. El ejemplo contiene la secuencia de comandos GenerateServerStub.cmd de línea de comandos, que encapsula el generador de código NSwag. El script toma un único parámetro, que es una ruta de acceso completa al directorio de instalación de NSwag. También comprueba el archivo de definición de Swagger (swagger.json) y el archivo de configuración (nswag.json) en la carpeta.

La ejecución de este script genera un archivo de C# llamado WorkloadAPI_Generated.cs. El contenido de este archivo se puede dividir lógicamente en tres partes, como se explica en las secciones siguientes.

Controladores de stub de ASP.NET Core

Las clases ItemLifecycleController y JobsController son implementaciones delgadas de controladores principales de ASP.NET Core para dos subconjuntos de API de carga de trabajo: administración del ciclo de vida de elementos y trabajos. Estas clases se conectan a la canalización HTTP de ASP.NET Core. Sirven como puntos de entrada para los métodos de API definidos en la especificación de Swagger. Estas clases reenvía las llamadas a la implementación "real" proporcionada por la carga de trabajo.

Este es un ejemplo del método 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);
}

Implementación para interfaces de cargas de trabajo

IItemLifecycleController y IJobsController son interfaces para las implementaciones "reales" mencionadas anteriormente. Definen los mismos métodos que implementan los controladores.

Definición de clases de contrato

Las clases de contrato de C# son clases que usan las API.

Implementación

El siguiente paso después de generar código implementa las interfaces IItemLifecycleController y IJobsController. En el ejemplo reutilizable, ItemLifecycleControllerImpl y JobsControllerImpl implementan estas interfaces.

Por ejemplo, este código es la implementación de la 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);
}

Controlar una carga útil de elemento

Varios métodos de API aceptan varios tipos de "carga" como parte del cuerpo de la solicitud o devuelven las cargas útiles como parte de la respuesta. Por ejemplo, CreateItemRequest tiene la propiedad 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
 }
 }
}

Los tipos de estas propiedades de carga útil se definen en la especificación Swagger. Hay un tipo dedicado para cada tipo de carga. Estos tipos no definen ninguna propiedad específica y permiten incluir cualquier propiedad.

Este es un ejemplo del tipo CreateItemPayload:

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

Las clases de contrato de C# generadas se definen como partial. Tienen un diccionario con propiedades definidas.

Este es un ejemplo:

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

El código puede usar este diccionario para leer y devolver propiedades. Sin embargo, un mejor enfoque es definir propiedades específicas mediante los tipos y nombres correspondientes. Puede usar la declaración partial en las clases generadas para definir propiedades de forma eficaz.

Por ejemplo, el archivo CreateItemPayload.cs contiene una definición complementaria para la clase CreateItemPayload.

En este ejemplo, la definición agrega la propiedad 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; }
    }
}

Sin embargo, si la carga de trabajo admite varios tipos de elementos, la clase CreateItemPayload debe ser capaz de controlar diferentes tipos de carga de creación, uno por tipo de elemento. Tiene dos opciones. La manera más sencilla, utilizada por el ejemplo reutilizable, es definir varias propiedades opcionales, cada una que representa la carga de creación para un tipo de elemento diferente. Cada solicitud tiene solo uno de estos conjuntos de propiedades, según el tipo de elemento que se va a crear. Como alternativa, podría implementar la serialización polimórfica, pero esta opción no se muestra en el ejemplo porque no proporciona ninguna ventaja significativa.

Por ejemplo, para admitir dos tipos de elemento, la definición de clase debe extenderse como en el ejemplo siguiente:

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:

El cliente genera la carga útil enviada a la carga de trabajo. Puede ser el editor de elementos iFrame o la API de REST de Fabric Automation. El cliente es responsable de enviar la carga correcta y coincidir con el tipo de elemento. La carga de trabajo es responsable de la comprobación. Fabric trata esta carga como un objeto opaco y solo lo transfiere del cliente a la carga de trabajo. Del mismo modo, para una carga devuelta por la carga de trabajo al cliente, es responsabilidad de la carga de trabajo y del cliente controlar la carga correctamente.

Por ejemplo, este código muestra cómo la implementación de item1 del ejemplo reutilizable controla la carga útil:

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

Solución de problemas y depuración

En las secciones siguientes se describe cómo solucionar problemas y depurar la implementación.

Problemas conocidos y resoluciones

Obtenga información sobre problemas conocidos y sobre las formas de resolverlos.

Falta el secreto de cliente

Error:

Microsoft.Identity.Client.MsalServiceException: un problema de configuración impide la autenticación. Compruebe el mensaje de error del servidor para obtener más información. Puede modificar la configuración en el portal de registro de la aplicación. Para obtener información detallada, vea https://aka.ms/msal-net-invalid-client.

Excepción original: AADSTS7000215: se ha proporcionado un secreto de cliente no válido. Asegúrese de que el secreto que se envía en la solicitud es el valor del secreto de cliente, no el identificador del secreto de cliente, para un secreto agregado al ajuste de la aplicación app_guid.

Resolución: asegúrese de que tiene el secreto de cliente correcto en appsettings.json.

Error:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: el usuario o administrador no ha dado su consentimiento para usar la aplicación con el id. <example ID>. Envíe una solicitud de autorización interactiva para este usuario y recurso.

Resolución:

  1. En el editor de elementos, vaya a la parte inferior del panel y seleccione Ir a la página de autenticación.

  2. En Ámbitos, escriba .default y seleccione Obtener token de acceso.

  3. En el cuadro de diálogo, apruebe la revisión.

Se produce un error en la creación del elemento debido a la selección de la capacidad

Error:

PriorityPlacement: no hay servicios principales disponibles para la selección de ubicación de prioridad. Solo name, guid y workload-name están disponibles.

Resolución:

Como usuario, es posible que solo tenga acceso a la capacidad de prueba. Asegúrese de usar una capacidad a la que tenga acceso.

Error de creación de archivos con el código 404 (NotFound)

Error:

Error al crear un nuevo archivo para filePath: 'workspace-id'/'lakehouse-id'/Files/data.json. El código de estado de la respuesta no indica que la operación se realizó correctamente: NotFound (404).

Resolución:

Asegúrese de que está trabajando con la dirección URL de OneLake DFS que se ajusta a su entorno. Por ejemplo, si trabaja con el entorno de PPE, cambie EnvironmentConstants.OneLakeDFSBaseUrl en Constants.cs a la dirección URL adecuada.

Depurar

Al solucionar problemas con varias operaciones, puede establecer puntos de interrupción en el código para analizar y depurar el comportamiento. Siga estos pasos para una depuración eficaz:

  1. Abra el código en el entorno de desarrollo.
  2. Vaya a la función del controlador de operaciones pertinente (por ejemplo, OnCreateFabricItemAsync para operaciones CRUD o un punto de conexión en un controlador de operaciones execute).
  3. Coloque puntos de interrupción en las líneas concretas en las que quiera inspeccionar el código.
  4. Ejecute la aplicación en modo de depuración.
  5. Desencadene la operación desde el front-end que desea depurar.

El depurador pausa la ejecución en los puntos de interrupción especificados, lo que le permite examinar variables, recorrer el código e identificar problemas.

Captura de pantalla del programa de ejemplo con puntos de interrupción para la depuración.

Área de trabajo

Si está conectando un back-end a la carga de trabajo de muestra, el elemento debe pertenecer a un área de trabajo que esté asociada a una capacidad. De manera predeterminada, el área de trabajo Mi área de trabajo no está asociada a una capacidad. De lo contrario, es posible que reciba el error que se muestra en la captura de pantalla siguiente:

Captura de pantalla de la interfaz de usuario para asignar un nombre a un elemento de carga de trabajo de ejemplo.

  1. Cambie a un área de trabajo con nombre. Deje el nombre predeterminado del área de trabajo Mi área de trabajo.

    Captura de pantalla de la interfaz de usuario para crear una carga de trabajo de ejemplo.

  2. En el área de trabajo correcta, cargue la carga de trabajo de ejemplo y continúe con las pruebas:

    Captura de pantalla de la interfaz de usuario para crear un elemento de carga de trabajo de ejemplo.

Colaboracion

Agradecemos las contribuciones a este proyecto. Si encuentra algún problema o quiere agregar nuevas características, siga estos pasos:

  1. Bifurque el repositorio.
  2. Cree una ramificación nueva para la función o corrección de errores.
  3. Aplique los cambios y confírmelos.
  4. Envíe los cambios al repositorio bifurcado.
  5. Cree una solicitud de cambios con una descripción clara de los cambios.

Contenido relacionado