Поделиться через

Реализация серверной части Microsoft Fabric

  • Статья

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

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

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

Дополнительные сведения см . в интерфейсе пакета средств разработки рабочей нагрузки 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 на выпуск и сборку пакета. Созданный пакет находится в каталоге src\bin\Release . Дополнительные сведения см . в руководстве по работе в облачном режиме.

Зависимости

  • Пример серверной реплики зависит от следующих пакетов Пакета 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 в пакетах\manifest/ и активирует ItemManifestValidator.ps1 во всех элементах XMLs (например, Item1.xml) в пакетах\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

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

Мы используем пример ASP.NET Core для рабочей нагрузки Boilerplate C# для демонстрации создания рабочей нагрузки с помощью REST API. Пример начинается с создания заглушки сервера и классов контрактов на основе спецификации API Swagger рабочей нагрузки. Вы можете создать код с помощью любого из нескольких средств создания кода Swagger. В примере "Стандартный" используется 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 класс должен иметь возможность обрабатывать различные типы полезных данных создания по одному типу элемента. В этом случае у вас есть два варианта. Проще всего определить несколько необязательных свойств, каждый из которых представляет полезные данные создания для другого типа элемента. Затем каждый запрос имеет только один из этих наборов свойств в соответствии с типом создаваемого элемента. Кроме того, можно реализовать полиморфную сериализацию, но этот параметр не демонстрируется в примере, так как этот параметр не предоставляет существенных преимуществ.

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

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. Клиент отвечает за отправку правильных полезных данных и сопоставление типа элемента. Рабочая нагрузка отвечает за проверку. Структура обрабатывает эту полезные данные как непрозрачный объект и передает его только из клиента в рабочую нагрузку. Аналогичным образом, для полезных данных, возвращаемых рабочей нагрузкой клиенту, она несет ответственность за рабочую нагрузку и клиент для правильной обработки полезных данных.

Например, в этом коде показано, как реализация 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>. Send an interactive authorization request for this user and resource. (Пользователь или администратор не предоставили разрешение на использование приложения с идентификатором "{идентификатор_приложения}" и именем "{имя_приложения}". Отправьте интерактивный запрос авторизации для этого пользователя и ресурса.)

Решение.

  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. Создайте запрос на вытягивание с четким описанием изменений.

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