Compartir vía

Guía de implementación del back-end (versión preliminar)

  • Artículo

Este repositorio de muestra para desarrollo de cargas de trabajo de Microsoft Fabric sirve como punto inicial para crear aplicaciones que requieran integración con varios servicios, así como integración con la plataforma Lakehouse. Esta guía le ayuda a configurar el entorno y a configurar los componentes necesarios para comenzar. En este 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, lo que facilita la interacción perfecta con el usuario. Para más información, consulte la guía de front-end del kit de desarrollo de cargas de trabajo de Fabric.

Back-end

El back-end almacena los datos y los metadatos. Utiliza operaciones CRUD para crear los elementos de la carga de trabajo (WL) junto con los metadatos 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 se opera en modo para desarrolladores. En el modo para desarrolladores, la carga de trabajo funciona en la máquina del desarrollador. La utilidad DevGateway.exe 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 una capacidad específica, haciendo que la carga de trabajo sea accesible en todos los espacios de trabajo asignados a esa capacidad. La utilidad controla el registro cuando se detiene.
  • Canaliza (junto con Azure Relay) las llamadas API de carga de trabajo desde Fabric a la carga de trabajo.

Las llamadas API de control de carga de trabajo se realizan directamente desde la carga de trabajo a Fabric y no requieren el canal de Azure Relay.

Integración de Lakehouse

La arquitectura del kit de desarrollo de cargas de trabajo se integra perfectamente con Lakehouse, lo que permite realizar operaciones como guardar, leer y capturar datos. La interacción se facilita a través de Azure Relay y el SDK de Fabric, lo que garantiza una comunicación segura y autenticada. Para más información, consulte trabajar con datos del cliente

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 la configuración del proyecto, las guías de autenticación y la introducción, consulte los siguientes documentos de autenticación:

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, lo que significa que se puede empaquetar en un paquete NuGet. 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 de trabajar en modo de nube

Dependencias

  • El código reutilizable del back-end de ejemplo 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 del 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, siga estos pasos:

  1. Clonación del repositorio: git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git

  2. Abra la solución en Visual Studio 2022.

  3. Configure el registro de una aplicación mediante las instrucciones de la guía de autenticación. Asegúrese de que sus proyectos Frontend y Backend tienen la configuración necesaria descrita en la guía. Microsoft Entra se utiliza para la autenticación segura, lo que garantiza que todas las interacciones dentro de la arquitectura están autorizadas y seguras.

  4. Actualizar la URL base de OneLake DFS: en función del entorno de Fabric, puede actualizar el OneLakeDFSBaseURL dentro de la carpeta src\Constants. El valor predeterminado es onelake.dfs.fabric.microsoft.com, pero se puede actualizar para reflejar el entorno en el que se encuentra. Puede encontrar más información sobre las rutas de acceso DFS en la documentación de One Lake.

  5. Configuración de la carga de trabajo

    • Copie workload-dev-mode.json de src/Config a C:\.
    • En el archivo workload-dev-mode.json, actualice los siguientes campos para que coincidan con su configuración:
      • CapacityGuid: su id. de capacidad. Puede encontrarlo en el portal Fabric, en la configuración de capacidad del portal de Administración.
      • ManifestPackageFilePath: la ubicación del paquete de manifiesto. Cuando cree la solución, se guardará el paquete de manifiesto en src\bin\Debug. Más detalles sobre el paquete de manifiesto se puede encontrar en los pasos posteriores.
      • WorkloadEndpointURL: dirección URL del punto de conexión de carga de trabajo.
    • 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. Esto se puede encontrar en el registro de la aplicación que creó en la sección "Autenticación".
      • <ResourceId>: audiencia para los tokens entrantes de Microsoft Entra. Esta información se puede encontrar en el registro de la aplicación que creó en la sección "Exponer una API".
    • En el archivo src/appsettings.json, actualice los siguientes campos para que coincidan con su configuración:
      • PublisherTenantId: el id. del inquilino editor de 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. Esta información se puede encontrar en el registro de la aplicación que creó en la sección "Exponer una API". Esto también se conoce como 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 ejecuta un proceso de tres pasos para generar el archivo de paquete de manifiesto:

    1. Desencadene ManifestValidator.ps1 en WorkloadManifest.xml en *Packages\manifest* y desencadene ItemManifestValidator.ps1 en los XML de todos los elementos (p. ej.: 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, se produce un error en la compilación con Validation errors with either manifests or default values. Seleccione dos veces el error en Visual Studio para ver el archivo de error.
    3. Después de la validación, empaquete los archivos WorkloadManifest.xml y 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 ubicada en la carpeta DevGateway. Inicie sesión con un usuario que tenga privilegios de administrador de capacidad para la capacidad que definió en workload-dev-mode.json (CapacityGuid). Una vez inicializada la carga de trabajo, aparece una solicitud de autenticación.

    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. Además, se carga y se publica el paquete que contiene el manifiesto de la carga de trabajo.

    En esta fase, Fabric tiene conocimiento de la carga de trabajo, que abarca su capacidad asignada.

    La supervisión de posibles errores se puede ver 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. Cambie el proyecto de inicio de Visual Studio por el proyecto Reutilizable y seleccione Ejecutar.

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

Trabajar con Reutilizable

Generación de código

Utilizamos el ejemplo reutilizable de C# de carga de trabajo ASP.NET Core para explicar cómo crear una carga de trabajo con las API de REST. 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 generarlos mediante cualquiera de las herramientas de generación de código de Swagger. Nuestra muestra Reutilizable utiliza 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 espera encontrar el archivo de definición de Swagger (swagger.json) y el archivo de configuración (nswag.json) junto a él.

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 indica a continuación.

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 principal de ASP.NET Core y sirven como puntos de entrada para los métodos de API, definidos en la especificación 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 e IJobsController son interfaces para las implementaciones "reales" mencionadas anteriormente. Definen los mismos métodos que implementan los controladores.

Definición de clases de contrato

Clases de contrato de C# usadas por las API.

Implementación

El siguiente paso después de generar código es implementar las interfaces IItemLifecycleController e 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);
}

Control de la carga de elementos

Varios métodos de API aceptan varios tipos de "carga" como parte del cuerpo de la solicitud o los devuelven 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" 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 cualqiuier propiedad. Por ejemplo, este es el 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 parciales y tienen un diccionario con propiedades.

/// <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 con los tipos y nombres correspondientes. Esto se puede lograr fácilmente debido a la declaración "parcial" en las clases generadas.

Por ejemplo, CreateItemPayload.cs archivo contiene una definición complementaria para la clase CreateItemPayload, que 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. Existen dos formas de hacerlo. 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 no se muestra en el ejemplo porque no proporciona ninguna ventaja significativa.

Por ejemplo, para admitir dos tipos de elemento, esta definición de clase tendría que extenderse de la siguiente manera:

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" enviada a la carga de trabajo. Podría 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 controla la implementación de Item1 de ejemplo Reutilizable 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();
}

Depuración y solución de problemas

Problemas conocidos y soluciones

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 a 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 consiente en usar la aplicación con el ID…. Envíe una solicitud de autorización interactiva para este usuario y recurso.

Resolución: en el editor de elementos, vaya a la parte inferior y seleccione Ir a la página de autenticación. En Ámbitos, escriba .default y seleccione Obtener token de acceso. Aprobar el consentimiento en el cuadro de diálogo emergente.

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 posición prioritaria, solo "name","guid","workload-name".

Resolución: es posible que esté usando un usuario que solo tenga acceso a la capacidad de prueba. Asegúrese de que usa una capacidad a la que tiene 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. Error: 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.

Depuración

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 de ejecución).
  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 (FE) 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, tenga en cuenta que 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, puede obtener un error como este:

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 y deje el valor predeterminado 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