Внедрение серверной части Microsoft Fabric

Этот репозиторий примеров разработки рабочей нагрузки Microsoft Fabric — это отправная точка для создания приложений, которые требуют интеграции с различными службами и взаимодействия с архитектурой lakehouse. Эта статья поможет вам настроить среду и настроить необходимые компоненты для начала работы. В этой статье описываются ключевые компоненты и их роли в архитектуре.

Внешний интерфейс

Интерфейс — это место, где вы управляете взаимодействием с пользователем (UX) и поведением. Он взаимодействует с интерфейсным порталом Fabric через iFrame, чтобы упростить простое взаимодействие.

Дополнительные сведения см. в разделе Frontend комплекта для разработки рабочих нагрузок Microsoft Fabric.

Бэкэнд

Серверная часть хранит как данные, так и метаданные. Он использует операции создания, чтения, обновления и удаления (CRUD) для создания элементов рабочей нагрузки и метаданных, а также выполняет задания для заполнения данных в хранилище. Обмен данными между интерфейсом и серверной частью устанавливается через общедоступные API.

Azure Relay и DevGateway

Azure Relay обеспечивает взаимодействие между локальной средой разработки и серверной частью Fabric в режиме разработчика. В режиме разработчика рабочая нагрузка работает на компьютере разработчика.

Служебная программа DevGateway имеет две роли:

  • Он обеспечивает обработку рабочей нагрузки в канале Azure Relay и управляет регистрацией локального экземпляра рабочей нагрузки в системе Fabric в контексте конкретной рабочей области. Программа обрабатывает отмену регистрации при отключении канала.
  • Он работает с Azure Relay, чтобы направлять вызовы API нагрузки от Fabric к рабочей нагрузке.

Вызовы API управления рабочей нагрузкой выполняются непосредственно из рабочей нагрузки в Fabric. Канал Ретрансляции Azure не требуется для вызовов.

Интеграция Lakehouse

Архитектура пакета средств разработки рабочей нагрузки легко интегрируется с архитектурой Lakehouse для таких операций, как сохранение, чтение и получение данных. Взаимодействие упрощается с помощью Azure Relay и пакета SDK Fabric для обеспечения безопасности и проверки подлинности связи. Дополнительные сведения см. в статье о работе с данными клиента.

Проверка подлинности и безопасность

Идентификатор Microsoft Entra используется для безопасной проверки подлинности, гарантируя, что все взаимодействия в архитектуре авторизованы и защищены.

Обзор пакета средств разработки предоставляет представление о нашей архитектуре. Дополнительные сведения о настройке проектов для рекомендаций по проверке подлинности и начале работы см. в следующих статьях:

Схема, показывающая, как пакет SDK Fabric интегрируется с Fabric.

Фронтенд устанавливает связь с фронтенд-порталом Fabric через iFrame. В свою очередь портал взаимодействует с серверной частью Fabric, выполняя вызовы к общедоступным API-интерфейсам.

Для взаимодействия между серверной частью разработки и серверной частью Fabric ретранслятор Azure служит в качестве канала. Кроме того, серверная часть разработки легко интегрируется с Lakehouse. Взаимодействие упрощается с помощью Azure Relay и пакета SDK для программного обеспечения Fabric, установленного в окне разработки серверной части.

Аутентификация всех подключений между этими компонентами обеспечивается с помощью Microsoft Entra. Microsoft Entra предоставляет безопасную и проверенную среду для взаимодействия между интерфейсом, серверной частью, Ретранслятором Azure, пакетом SDK Fabric и Lakehouse.

Предварительные условия

Убедитесь, что диспетчер пакетов NuGet интегрирована в установку Visual Studio. Это средство требуется для упрощенного управления внешними библиотеками и пакетами, необходимыми для нашего проекта.

Управление пакетами NuGet

  • <NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile> и <NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: эти свойства указывают путь к файлам NuSpec, используемым для создания пакета NuGet для режимов отладки и выпуска. Файл NuSpec содержит метаданные о пакете, такие как его идентификатор, версия, зависимости и другие соответствующие сведения.

  • <GeneratePackageOnBuild>true</GeneratePackageOnBuild>: если задано значение true, это свойство указывает процессу сборки автоматически создавать пакет NuGet во время каждой сборки. Это свойство полезно, чтобы убедиться, что пакет всегда обновлен с последними изменениями в проекте.

  • <IsPackable>true</IsPackable>: если задано значение true, это свойство указывает, что проект можно упаковать в пакет NuGet. Возможность упаковки — это важное свойство для проектов, предназначенных для создания пакетов NuGet во время процесса сборки.

Созданный пакет NuGet для режима отладки находится в каталоге src\bin\Debug после процесса сборки.

При работе в облачном режиме можно изменить конфигурацию сборки в Visual Studio на Release и выполнить сборку вашего пакета. Созданный пакет находится в каталоге src\bin\Release . Дополнительные сведения см. в руководстве по работе в облачном режиме.

Зависимости

  • Образец серверной части Boilerplate зависит от следующих пакетов SDK Azure.

    • Azure.Core
    • Azure.Identity
    • Azure.Storage.Files.DataLake
    • Пакет идентификации Майкрософт

Чтобы настроить диспетчер пакетов NuGet, укажите путь в разделе "Источники пакетов" перед началом процесса сборки.

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

Начало работы

Чтобы настроить пример проекта рабочей нагрузки на локальном компьютере, выполните следующие действия.

  1. Клонируйте репозиторий: Запустите git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git.

  2. В Visual Studio 2022 откройте решение.

  3. Настройте регистрацию приложения, следуя инструкциям в руководстве по проверке подлинности. Убедитесь, что интерфейсные и внутренние проекты имеют необходимую настройку, описанную в статье. Microsoft Entra используется для безопасной проверки подлинности, чтобы гарантировать, что все взаимодействия в архитектуре авторизованы и защищены.

  4. Обновите базовый URL-адрес Microsoft OneLake DFS. В зависимости от среды Fabric можно обновить значение OneLakeDFSBaseURL в папке src\Constants . Значением по умолчанию является onelake.dfs.fabric.microsoft.com, но вы можете обновить URL-адрес, чтобы отразить среду. Дополнительные сведения о путях DFS см. в документации по OneLake.

  5. Настройте конфигурацию рабочей нагрузки.

    1. Скопируйте workload-dev-mode.json из src/Config в C:.
    2. В файле workload-dev-mode.json обновите следующие поля, чтобы соответствовать конфигурации:
      • WorkspaceGuid: идентификатор рабочей области. Это значение можно найти в URL-адресе браузера при выборе рабочей области в Fabric. Например, https://app.powerbi.com/groups/<WorkspaceID>/.
      • ManifestPackageFilePath: расположение пакета манифеста. При сборке решения он сохраняет пакет манифеста в src\bin\Debug. Дополнительные сведения о пакете манифеста приведены далее в статье.
      • WorkloadEndpointURL: URL-адрес конечной точки рабочей нагрузки.
    3. В файле packages/manifest/WorkloadManifest.xml обновите следующие поля, чтобы соответствовать конфигурации:
      • <AppId>: идентификатор клиента (идентификатор приложения) рабочей нагрузки приложения Microsoft Entra.
      • <RedirectUri>: URI перенаправления. Это значение можно найти в созданной регистрации приложения в разделе "Проверка подлинности".
      • <ResourceId>: аудитория входящих токенов Microsoft Entra. Эти сведения можно найти в созданной регистрации приложения в разделе "Предоставление API".
    4. В файле src/appsettings.json обновите следующие поля, чтобы соответствовать конфигурации:
      • PublisherTenantId: идентификатор клиента издателя рабочей нагрузки.
      • ClientId: идентификатор клиента (идентификатор приложения) рабочей нагрузки приложения Microsoft Entra.
      • ClientSecret: секрет для приложения рабочей нагрузки Microsoft Entra.
      • Аудитория: аудитория для входящих токенов Microsoft Entra. Эти сведения можно найти в созданной регистрации приложения в разделе "Предоставление API". Этот параметр также называется URI идентификатора приложения.

  6. Создайте пакет манифеста.

    Чтобы создать файл пакета манифеста, создайте Fabric_Extension_BE_Boilerplate. Сборка представляет собой трехэтапный процесс, который создает файл манифеста пакета. Он выполняет следующие действия:

    1. Активирует ManifestValidator.ps1 на WorkloadManifest.xml в Packages\manifest/ и активирует ItemManifestValidator.ps1 на всех XML-файлах элементов (например, Item1.xml) в Packages\manifest/. Если проверка завершается ошибкой, создается файл ошибки. Скрипты проверки можно просмотреть в ValidationScripts/.
    2. Если файл с ошибками существует, сборка завершается с ошибками проверки либо манифестов, либо значений по умолчанию. Чтобы просмотреть файл ошибки в Visual Studio, дважды щелкните ошибку в результатах проверки.
    3. После успешной проверки упаковайте файлы WorkloadManifest.xml и Item1.xml в ManifestPackage.1.0.0.nupkg. Полученный пакет находится в src\bin\Debug.

    Скопируйте файл ManifestPackage.1.0.0.nupkg в путь, определенный в файле конфигурации workload-dev-mode.json.

  7. Program.cs — это точка входа и скрипт запуска приложения. В этом файле можно настроить различные службы, инициализировать приложение и запустить веб-узел.

  8. Выполните сборку, чтобы ваш проект мог получить доступ к необходимым зависимостям для компиляции и выполнения.

  9. Скачивание DevGateway из Центра загрузки Майкрософт

  10. Запустите приложение Microsoft.Fabric.Workload.DevGateway.exe и войдите с помощью пользователя с правами администратора рабочей области для рабочей области, указанной в WorkspaceGuid поле workload-dev-mode.json.

    Снимок экрана: страница входа Майкрософт.

    После аутентификации внешние рабочие задачи устанавливают связь с бэкендом Fabric через Azure Relay. Этот процесс включает в себя управление регистрацией ретранслятора и взаимодействием, которое упрощается назначенным прокси-узлом. Пакет, содержащий манифест рабочей нагрузки, отправляется и публикуется.

    На этом этапе Fabric обнаруживает рабочую нагрузку и включает выделенную емкость.

    Вы можете отслеживать потенциальные ошибки в консоли.

    Если ошибки не отображаются, подключение установлено, регистрация успешно выполняется, а манифест рабочей нагрузки систематически отправляется.

    Снимок экрана: загрузка подключения без ошибок.

  11. В Visual Studio измените проект запуска на проект "Шаблон" и выберите Выполнить.

    Снимок экрана: пользовательский интерфейс для запуска проекта в Visual Studio.

Работа с примером проекта Boilerplate

Создание кода

Мы используем пример Boilerplate C# для ASP.NET Core для демонстрации создания нагрузки с помощью REST API. Пример начинается с создания заглушек сервера и классов контрактов на основе спецификации Swagger API производственной нагрузки. Вы можете создать код с помощью любого из нескольких средств создания кода Swagger. В примере "Boilerplate" используется NSwag. Пример содержит скрипт командной строки GenerateServerStub.cmd, который упаковывает генератор кода NSwag. Скрипт принимает один параметр, который указывает полный путь к каталогу установки NSwag. Он также проверяет файл определения Swagger (swagger.json) и файл конфигурации (nswag.json) в папке.

При выполнении этого скрипта создается файл C# с именем WorkloadAPI_Generated.cs. Содержимое этого файла можно логически разделить на три части, как описано в следующих разделах.

контроллеры заглушки ASP.NET Core

ItemLifecycleController и JobsController классы — это тонкие реализации контроллеров ASP.NET Core для двух подмножеств API рабочей нагрузки: управление жизненным циклом элементов и заданиями. Эти классы подключались к конвейеру HTTP ASP.NET Core. Они служат точками входа для методов API, определенных в спецификации Swagger. Классы перенаправили вызовы в "реальную" реализацию, предоставляемую рабочей нагрузкой.

Ниже приведен пример 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);
}

Интерфейсы для реализации рабочей нагрузки

IItemLifecycleController и IJobsController являются интерфейсами для упомянутых ранее "реальных" реализаций. Они определяют те же методы, которые реализуют контроллеры.

Определение классов контрактов

Классы контрактов C# — это классы, используемые API.

Внедрение

Следующий шаг после создания кода — реализация интерфейсов IItemLifecycleController и IJobsController. В примере шаблона ItemLifecycleControllerImpl и JobsControllerImpl реализуют эти интерфейсы.

Например, этот код является реализацией 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);
}

Обработка полезной нагрузки элемента

Несколько методов API принимают различные типы полезных данных в составе текста запроса или возвращают полезные данные в рамках ответа. Например, CreateItemRequest имеет 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
 }
 }
}

Типы этих свойств полезной нагрузки определены в спецификации Swagger. Существует выделенный тип для каждого вида полезной нагрузки. Эти типы не определяют какие-либо определенные свойства, и они позволяют включать любое свойство.

Ниже приведен пример CreateItemPayload типа:

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

Созданные классы контрактов C# определяются как partial. У них есть словарь с определенными свойствами.

Приведем пример:

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

Код может использовать этот словарь для чтения и возврата свойств. Однако более подходящим подходом является определение конкретных свойств с помощью соответствующих типов и имен. Можно использовать объявление partial в созданных классах для эффективного определения свойств.

Например, файл CreateItemPayload.cs содержит дополнительное определение для CreateItemPayload класса.

В этом примере определение добавляет 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; }
    }
}

Однако если рабочая нагрузка поддерживает несколько типов элементов, класс CreateItemPayload должен иметь возможность обрабатывать разные типы полезной нагрузки создания, причём одна полезная нагрузка на каждый тип элемента. В этом случае у вас есть два варианта. Простой способ, используемый в примере Boilerplate, — это определить несколько необязательных свойств, каждое из которых представляет данные для создания для другого типа элемента. Затем каждый запрос имеет только один из этих наборов свойств в соответствии с типом создаваемого элемента. Кроме того, можно реализовать полиморфную сериализацию, но этот параметр не демонстрируется в примере, так как этот параметр не предоставляет существенных преимуществ.

Например, чтобы поддерживать два типа элементов, определение класса должно быть расширено, как показано в следующем примере:

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

Примечание.

Полезная нагрузка, которая отправляется в рабочую нагрузку, генерируется клиентом. Это может быть редактор элементов iFrame или REST API службы автоматизации Fabric. Клиент отвечает за отправку правильного пакета данных и сопоставление типа объекта. Рабочая нагрузка отвечает за проверку. Технологическая система обрабатывает эти данные как неинтерпретированный объект и передает их только от клиента к рабочей нагрузке. Аналогичным образом, ответственность за правильную обработку пейлоада, возвращаемого рабочей нагрузкой клиенту, лежит как на рабочей нагрузке, так и на клиенте.

Например, этот код демонстрирует, как реализация Boilerplate sample item1 обрабатывает полезную нагрузку.

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

Устранение неполадок и отладка

В следующих разделах описывается устранение неполадок и отладка развертывания.

Известные проблемы и решения

Получение сведений о известных проблемах и способах их устранения.

Отсутствующий секрет клиента

Ошибка.

Microsoft.Identity.Client.MsalServiceException: проблема конфигурации предотвращает проверку подлинности. Дополнительные сведения см. в сообщении об ошибке с сервера. Конфигурацию можно изменить на портале регистрации приложений. Подробные сведения см. в разделе https://aka.ms/msal-net-invalid-client.

Исходное исключение: AADSTS7000215: был предоставлен недопустимый секрет клиента. Убедитесь, что секрет, отправляемый в запросе, является значением секрета клиента, а не идентификатором секрета для секрета, добавленного в параметр приложения app_guid .

Решение. Убедитесь, что у вас есть правильный секрет клиента, определенный в appsettings.json.

Ошибка.

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: пользователь или администратор не предоставил согласие на использование приложения с идентификатором <example ID>. Отправьте интерактивный запрос авторизации для этого пользователя и ресурса.

Решение.

  1. В редакторе элементов перейдите в нижнюю часть окна и выберите Перейти на страницу аутентификации.

  2. В разделе "Сферы" введите .default, затем выберите Получить токен доступа.

  3. В диалоговом окне подтвердите редакцию.

Создание элемента завершается сбоем из-за выбора емкости

Ошибка.

PriorityPlacement: для приоритетного размещения недоступны основные сервисы. Только name, guidи workload-name доступны.

Решение.

У пользователя может быть доступ только к емкости пробной версии. Убедитесь, что у вас есть доступ к емкости.

Сбой создания файла с ошибкой 404 (NotFound)

Ошибка.

Сбой создания нового файла для filePath: "workspace-id"/'lakehouse-id"/Files/data.json. Код состояния ответа не указывает на успех: 404 (NotFound).

Решение.

Убедитесь, что вы работаете с URL-адресом OneLake DFS, который соответствует вашей среде. Например, если вы работаете с средой PPE, измените EnvironmentConstants.OneLakeDFSBaseUrlConstants.cs на соответствующий URL-адрес.

Отладка

При устранении неполадок с различными операциями можно задать точки останова в коде для анализа и отладки поведения. Выполните следующие действия для эффективной отладки:

  1. Откройте код в среде разработки.
  2. Перейдите к соответствующей функции обработчика операций (например, OnCreateFabricItemAsync для операций CRUD или конечной точки в контроллере для execute операций).
  3. Поместите точки останова в определенные строки, где вы хотите проверить код.
  4. Запустите приложение в режиме отладки.
  5. Запустите операцию с фронтенда, которую вы хотите отладить.

Отладчик приостанавливает выполнение в указанных точках останова, чтобы можно было изучить переменные, выполнить шаг по коду и определить проблемы.

Снимок экрана: пример программы с точками останова для отладки.

Рабочая область

Если вы подключаете бэкенд к пробному проекту нагрузки, ваш элемент должен принадлежать рабочей области, связанной с емкостью. По умолчанию рабочая область "Моя рабочая область" не связана с емкостью. В противном случае может появиться ошибка, показанная на следующем снимке экрана:

Снимок экрана: пользовательский интерфейс для именования примера элемента рабочей нагрузки.

  1. Перейдите в именованную рабочую область. Оставьте имя рабочей области по умолчанию "Моя рабочая область".

  2. В правильной рабочей области загрузите образец рабочей нагрузки и выполните следующие тесты:

Внести вклад

Мы приветствуем вклад в этот проект. Если вы найдете какие-либо проблемы или хотите добавить новые функции, выполните следующие действия.

  1. Сделать форк репозитория.
  2. Создайте ветвь для функции или исправления ошибок.
  3. Внесите изменения и зафиксируйте их.
  4. Отправьте изменения в ваш форкнутый репозиторий.
  5. Создайте pull request с подробным описанием изменений.

Связанный контент

  • Last updated on