Microsoft Fabric バックエンドを実装する

[アーティクル]
12/03/2024

この Microsoft Fabric ワークロード開発サンプルリポジトリは、さまざまなサービスとの統合を必要とするアプリケーションを構築する場合やレイクハウスアーキテクチャと統合する場合の出発点になります。この記事は、環境を設定し、スタートに必要なコンポーネントの構成に役立ちます。この記事では、アーキテクチャにおける主要なコンポーネントとその役割について概要を説明します。

フロントエンド

フロントエンドは、ユーザーエクスペリエンス (UX) と動作を管理する場所です。 iFrame を介して Fabric フロントエンドポータルと通信し、シームレスな対話を支援します。

詳細については、Microsoft Fabric ワークロード開発キットフロントエンドに関する記事を参照してください。

バックエンド

バックエンドには、データとメタデータの両方が格納されます。作成、読み取り、更新、削除 (CRUD) 操作を使用して、ワークロード項目とメタデータが作成されます。また、ストレージ内のデータを設定するジョブが実行されます。フロントエンドとバックエンドの間の通信は、パブリック API を介して確立されます。

Azure Relay と DevGateway

Azure Relay を使用すると、開発者モードでローカル開発環境と Fabric バックエンド間の通信が可能になります。開発者モードでは、ワークロードは開発者のコンピューター上で動作します。

DevGateway ユーティリティには 2 つのロールがあります。

Azure Relay チャネルのワークロード側を処理し、特定のワークスペースのコンテキストで Fabric を使用してワークロードローカルインスタンスの登録を管理します。このユーティリティは、チャネルが切断されたときに登録解除を処理します。
Azure Relay と連携し、Fabric からワークロードへとワークロード API 呼び出しをチャネルします。

ワークロード制御 API 呼び出しは、ワークロードから Fabric に対して直接行われます。通話には Azure Relay チャネルは必要ありません。

Lakehouse 統合

ワークロード開発キットのアーキテクチャは、データの保存、読み取り、フェッチなどの操作のためにレイクハウスアーキテクチャとシームレスに統合されています。 Azure Relay と Fabric SDK を使用することでこの対話が容易になり、セキュリティで保護された認証済みの通信を確保できます。詳細については、顧客データの操作に関する記事を参照してください。

認証とセキュリティ

Microsoft Entra ID は、セキュリティで保護された認証に使用され、これにより、アーキテクチャ内のすべての対話が承認され、セキュリティで保護されます。

開発キットの概要では、アーキテクチャを簡単に説明します。プロジェクトの構成方法、認証のガイドライン、開始方法の詳細については、次の記事を参照してください。

Fabric SDK が Fabric とどのように統合されるかを示すダイアグラム。

フロントエンドは、iFrame 経由で Fabric フロントエンドポータルとの通信を確立します。次に、ポータルは、公開されているパブリック API を呼び出すことで Fabric バックエンドと対話します。

バックエンド開発ボックスと Fabric バックエンドの間のインタラクションに関して、Azure Relay はルートとして機能します。さらに、バックエンド開発ボックスは Lakehouse とシームレスに統合されます。通信は、Azure Relay と、バックエンド開発ボックスにインストールされているソフトウェア開発キット (SDK) を使用することで容易になります。

これらのコンポーネント内のすべての通信に対する認証は、Microsoft Entra を通じて保証されます。 Microsoft Entra は、フロントエンド、バックエンド、Azure Relay、Fabric SDK、Lakehouse の間の対話のための認証された安全な環境を提供します。

前提条件

.NET 7.0 SDK
Visual Studio 2022

お使いの Visual Studio のインストールに NuGet パッケージマネージャーが統合されていることを確認します。このツールは、プロジェクトに不可欠な外部ライブラリとパッケージの効率化された管理に必要です。

NuGet Package Management

<NuspecFile>Packages\manifest\ManifestPackageDebug.nuspec</NuspecFile>と<NuspecFile>Packages\manifest\ManifestPackageRelease.nuspec</NuspecFile>: これらのプロパティは、デバッグモードとリリースモードの NuGet パッケージの作成に使用される NuSpec ファイルへのパスを指定します。 NuSpec ファイルには、その ID、バージョン、依存関係、その他の関連情報など、パッケージに関するメタデータが含まれています。
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>: true に設定すると、このプロパティは、各ビルド中に NuGet パッケージを自動的に生成するようにビルドプロセスに指示します。このプロパティは、パッケージが常にプロジェクトの最新の変更に対応していることを確認するのに役立ちます。
<IsPackable>true</IsPackable>: true に設定した場合、このプロパティはプロジェクトを NuGet パッケージにパッケージ化できることを示します。パッケージ化できることは、ビルドプロセス中に NuGet パッケージを生成することを目的としたプロジェクトに不可欠なプロパティです。

デバッグモード用に生成された NuGet パッケージは、ビルドプロセス後に src\bin\Debug ディレクトリに配置されます。

クラウドモードで作業する場合は、Visual Studio のビルド構成を [リリース] に変更して、パッケージをビルドできます。生成されたパッケージは、src\bin\Release ディレクトリにあります。詳細については、クラウドモードでの作業ガイドを参照してください。

依存関係

バックエンドの定型文サンプルは、次の Azure SDK パッケージによって異なります。
- Azure.Core
- Azure.Identity
- Azure.Storage.Files.DataLake
- Microsoft ID パッケージ

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>

作業の開始

ローカルコンピューターでワークロードサンプルプロジェクトを設定するには:

リポジトリをクローンする: git clone https://github.com/microsoft/Microsoft-Fabric-workload-development-sample.git を実行します。
Visual Studio 2022 でソリューションを開きます。
認証チュートリアルの手順に従って、アプリの登録を設定します。フロントエンドとバックエンドのプロジェクトの両方で、この記事で説明されている必要なセットアップが行われていることを確認します。 Microsoft Entra はセキュリティで保護された認証に使用され、アーキテクチャ内のすべての対話を確実に認可し、セキュリティで保護するために役立ちます。
Microsoft OneLake DFS ベース URL を更新します。 Fabric 環境によっては、OneLakeDFSBaseURL フォルダー内のの値を更新できる場合があります。既定値は onelake.dfs.fabric.microsoft.com ですが、環境に合わせて URL を更新できます。 DFS パスの詳細については、OneLake のドキュメントを参照してください。
ワークロード構成を設定します。
1. workload-dev-mode.json を src/Config から C: にコピーします。
2. 実際の構成に合わせて、workload-dev-mode.json ファイルの次のフィールドを更新します。
  - WorkspaceGuid: ワークスペース ID。 Fabric でワークスペースを選択したときに、ブラウザーの URL でこの値を確認できます。たとえば、https://app.powerbi.com/groups/<WorkspaceID>/ のようにします。
  - ManifestPackageFilePath: マニフェストパッケージの場所。ソリューションをビルドすると、マニフェストパッケージが src\bin\Debug に保存されます。マニフェストパッケージの詳細については、この記事の後半で説明します。
  - WorkloadEndpointURL: ワークロードエンドポイント URL。
3. 実際の構成に合わせて、Packages/manifest/WorkloadManifest.xml ファイルの次のフィールドを更新します。
  - <AppId>: ワークロード Microsoft Entra アプリケーションのクライアント ID (アプリケーション ID)。
  - <RedirectUri>: リダイレクト URI。この値は、作成したアプリ登録の [認証] で確認できます。
  - <ResourceId>: 受信 Microsoft Entra トークンの対象ユーザー。この情報は、作成したアプリ登録の [API の公開] で確認できます。
4. 実際の構成に合わせて、src/appsettings.json ファイルの次のフィールドを更新します。
  - PublisherTenantId: ワークロードパブリッシャーテナントの ID。
  - ClientId: ワークロード Microsoft Entra アプリケーションのクライアント ID (アプリケーション ID)。
  - ClientSecret: ワークロード Microsoft Entra アプリケーションのシークレット。
  - Audience: 受信 Microsoft Entra トークンの対象ユーザー。この情報は、作成したアプリ登録の [API の公開] で確認できます。この設定は、アプリケーション ID URI とも呼ばれます。
マニフェストパッケージを生成します。

マニフェストパッケージファイルを生成するには、Fabric_Extension_BE_Boilerplate をビルドします。ビルドは、マニフェストパッケージファイルを生成する 3 段階のプロセスです。次の手順が実行されます。
1. Packages\manifest/ 内の WorkloadManifest.xml に対して ManifestValidator.ps1 をトリガーし、Packages\manifest/ 内のすべての項目 XML (たとえば Item1.xml) に対して ItemManifestValidator.ps1 をトリガーします。検証が失敗した場合は、エラーファイルが生成されます。 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 構成ファイルで定義されているパスにコピーします。
Program.csは、お使いのアプリのエントリポイントとスタートアップスクリプトとして機能します。このファイルでは、さまざまなサービスの構成、アプリケーションの初期化、Web ホストの起動を行うことができます。
ビルドして、コンパイルと実行に必要な依存関係にプロジェクトがアクセスできることを確認します。
Microsoft ダウンロードセンターから DevGateway をダウンロードします
Microsoft.Fabric.Workload.DevGateway.exe アプリケーションを実行し、workload-dev-mode.json のフィールドに指定されたワークスペースに対してWorkspaceGuidを持つユーザーを使用してサインインします。

認証後、外部ワークロードは Azure Relay を介して Fabric バックエンドとの通信を確立します。このプロセスには、指定されたプロキシノードによって促進されるリレー登録と通信管理が含まれます。ワークロードマニフェストを含むパッケージがアップロードされ、発行されます。

この段階で、Fabric によってワークロードが検出され、割り当てられた容量が組み込まれます。

コンソールで潜在的なエラーを監視できます。

エラーが表示されない場合は、接続が確立され、登録が正常に実行され、ワークロードマニフェストが体系的にアップロードされます。
Visual Studio で、スタートアッププロジェクトを定型プロジェクトに変更し、[実行] を選択します。

定型サンプルプロジェクトを使用する

コード生成

ワークロードの定型 C# ASP.NET Core サンプルを使用して、REST API を使用してワークロードを構築する方法を説明します。このサンプルは、ワークロード API Swagger 仕様に基づくサーバースタブとコントラクトクラスの生成から始まります。このコードを生成するには、いくつかの Swagger コード生成ツールのいずれかを使用します。この定型サンプルでは NSwag を使用しています。このサンプルには、NSwag コードジェネレーターをラップする GenerateServerStub.cmd コマンドラインスクリプトが含まれています。スクリプトは単一のパラメーターを受け取ります。これは NSwag インストールディレクトリへの完全なパスです。また、フォルダー内の Swagger 定義ファイル (swagger.json) と構成ファイル (nswag.json) もチェックされます。

このスクリプトを実行すると、WorkloadAPI_Generated.cs という C# ファイルが生成されます。このファイルの内容は、次のセクションで説明するように、論理的に 3 つの部分に分割できます。

コアスタブコントローラーの ASP.NET

ItemLifecycleController と JobsController クラスは、Workload API の 2 つのサブセット (項目ライフサイクル管理とジョブ) に対する ASP.NET Core コントローラーのシン実装です。これらのクラスは、ASP.NET Core HTTP パイプラインに接続されます。これらは、Swagger 仕様で定義されている API メソッドのエントリポイントとして機能します。これらのクラスは、ワークロードによって提供される "実際の" 実装への呼び出しを転送します。

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 でこれらのインターフェイスを実装しています。

たとえば、次のコードは CreateItem API の実装です。

/// <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 クラスは、項目の種類ごとに 1 つずつ、さまざまな種類の作成ペイロードを処理できる必要があります。この場合、2 つの選択肢があります。定型サンプルで使用されるより簡単な方法は、複数の省略可能なプロパティを定義することです。それぞれが異なる項目の種類の作成ペイロードを表します。すべての要求には、作成される項目の種類に応じて、これらのプロパティセットのいずれかが 1 つだけ含まれます。または、ポリモーフィックなシリアル化を実装することもできますが、このオプションには大きな利点がないため、サンプルではこのオプションを示していません。

たとえば、2 つの項目の種類をサポートするには、次の例のようにクラス定義を拡張する必要があります。

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

Note

ワークロードに送信されるペイロードは、クライアントによって生成されます。項目エディターの iFrame または Fabric Automation REST API を使用できます。クライアントは、正しいペイロードを送信し、項目の種類と一致する役割を担います。ワークロードは検証を担います。 Fabric は、このペイロードを不透明なオブジェクトとして扱い、クライアントからワークロードにのみ転送します。同様に、ワークロードからクライアントに返されるペイロードの場合、ペイロードを正しく処理するのはワークロードとクライアントの責任です。

たとえば、次のコードは、定型サンプル 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 設定に追加されたシークレットの、クライアントシークレット ID ではなく、クライアントシークレット値であることを確認してください。

解決策: appsettings.json で正しいクライアントシークレットが定義されていることを確認します。

エラー:

Microsoft.Identity.Client.MsalUiRequiredException: AADSTS65001: ユーザーまたは管理者は、ID <example ID> によるアプリケーションの使用に同意しませんでした。このユーザーとリソースに、対話形式の承認要求を送信してください。

解決策:

項目エディターで、ペインの一番下に移動し、[認証ページに移動] を選択します。
[スコープ] に「.default」と入力し、[アクセストークンの取得] を選択します。
ダイアログでリビジョンを承認します。

容量選択によりアイテム作成が失敗した

エラー:

PriorityPlacement: 優先配置に使用できるコアサービスはありません。 name、guid、workload-name のみが使用できます。

解決策:

ユーザーである場合は、アクセスできるのは試用版の容量のみの可能性があります。アクセスできる容量を使用していることを確認してください。

404 (NotFound) エラーを伴うファイル作成エラー

エラー:

filePath の新しいファイルの作成に失敗しました: 'workspace-id'/'lakehouse-id'/Files/data.json。応答状態コードが成功にならない: 404 (NotFound)。

解決策:

環境に合った OneLake DFS URL を使用していることを確認します。たとえば、PPE 環境を使用する場合は、EnvironmentConstants.OneLakeDFSBaseUrl のを適切な URL に変更します。

デバッグ

さまざまな操作のトラブルシューティングを行うときは、コードにブレークポイントを設定して、その動作を分析してデバッグできます。効果的なデバッグを行うには、次の手順に従います。

開発環境でコードを開きます。
関連する操作ハンドラー関数に移動します (たとえば、CRUD 操作の場合は OnCreateFabricItemAsync、execute 操作の場合はコントローラーのエンドポイント)。
コードを検査する特定の行にブレークポイントを配置します。
デバッグモードでアプリケーションを実行する。
デバッグするフロントエンドから操作をトリガーします。

デバッガーにより、指定したブレークポイントで実行が一時停止されるので、変数を調べ、コードをステップ実行し、問題を特定することができます。

デバッグ用のブレークポイントを含むサンプルプログラムのスクリーンショット。

ワークスペース

バックエンドをサンプルワークロードプロジェクトに接続している場合は、容量に関連付けられているワークスペースに項目が属している必要があります。既定では、[マイワークスペース] ワークスペースは容量に関連付けられていません。それ以外の場合、次のスクリーンショットに示されているエラーが発生する可能性があります。

サンプルワークロード項目に名前を付けるための UI のスクリーンショット。

名前付きワークスペースに切り替えます。既定のワークスペース名「マイワークスペース」のままにします。
適切なワークスペースからサンプルワークロードを読み込み、テストを続行します。

投稿

このプロジェクトへのコントリビューション歓迎します。問題が見つけた場合、または新機能を追加する場合は、次の手順に従います:

リポジトリをフォークします。
新しく機能ブランチまたはバグ修正ブランチを作成します。
変更を加えてコミットします。
変更点をフォークされたリポジトリにプッシュします。
変更の明確な説明を含む pull request を作成します。

次の方法で共有

Microsoft Fabric バックエンドを実装する

フロントエンド

バックエンド

Azure Relay と DevGateway

Lakehouse 統合

認証とセキュリティ

前提条件

NuGet Package Management

依存関係

作業の開始

定型サンプルプロジェクトを使用する

コード生成

コアスタブコントローラーの ASP.NET

ワークロード実装用のインターフェース

コントラクトクラスの定義

実装

項目のペイロードを処理する

トラブルシューティングとデバッグ

既知の問題と解決策

クライアントシークレットが見つからない

容量選択によりアイテム作成が失敗した

404 (NotFound) エラーを伴うファイル作成エラー

デバッグ

ワークスペース

投稿

フィードバック

その他のリソース

次の方法で共有

Microsoft Fabric バックエンドを実装する

フロントエンド

バックエンド

Azure Relay と DevGateway

Lakehouse 統合

認証とセキュリティ

前提条件

NuGet Package Management

依存関係

作業の開始

定型サンプル プロジェクトを使用する

コード生成

コア スタブ コントローラーの ASP.NET

ワークロード実装用のインターフェース

コントラクト クラスの定義

実装

項目のペイロードを処理する

トラブルシューティングとデバッグ

既知の問題と解決策

クライアント シークレットが見つからない

管理者の同意がないため、アーティファクトの作成中にエラーが発生しました

容量選択によりアイテム作成が失敗した

404 (NotFound) エラーを伴うファイル作成エラー

デバッグ

ワークスペース

投稿

関連するコンテンツ

フィードバック

その他のリソース

定型サンプルプロジェクトを使用する

コアスタブコントローラーの ASP.NET

コントラクトクラスの定義

クライアントシークレットが見つからない