Fabric ライフサイクル管理ツールに関するよくあるご質問

ライフサイクル管理には、統合とデプロイの 2 つの要素があります。 Fabric 統合について理解するには、「Git 統合の概要」をご覧ください。 Fabric のデプロイ パイプラインとは何かを理解するには、「デプロイ パイプラインの概要」をご覧ください。

Git 統合の簡単な説明については、「Git 統合の概要」を参照してください。質問に対する複数行または書式設定された回答が用意されています。 「|」文字の後の行でインデントを維持している限り、任意の Markdown 書式設定を使用できます。

デプロイ パイプラインの簡単な説明については、デプロイ パイプラインの概要に関するページを参照してください。

ライセンス情報については、「Fabric ライセンス」をご覧ください。

すべてのワークスペースはFabric ライセンスに割り当てられる必要があります。 しかし、ワークスペースごとに異なる容量の種類を使用できます。

容量の種類の情報については、「容量と SKU」をご覧ください。

配置パイプラインのアクセス許可モデルについては、「アクセス許可」のセクションで説明されています。

配置パイプラインで配置ルールを構成するには、セマンティック モデルの所有者である必要があります。

ワークスペース容量が 1 つの地理的な場所にある一方、Azure DevOps リポジトリが別の場所にある場合、Fabric 管理者はクロス geo エクスポートを有効にするかどうかを決定します。 詳細については、「他の地理的な場所にある Git リポジトリにアイテムをエクスポートできる」を参照してください。

開始手順を参考に、Git 統合を始めてみてください。

ワークスペースからアイテムが削除される理由はいくつか考えられます。

• アイテムがコミットされておらず、"元に戻す" アクションでそのアイテムを選んだ場合、アイテムはワークスペースから削除されます。
• アイテムがコミットされており、ブランチを切り替えて、そのアイテムが新しいブランチには存在しない場合、そのアイテムは削除される可能性があります。

留意すべき重要な考慮事項をいくつか挙げます。

• 配置ルールの制限事項
• データフローおよびセマンティック モデル ルールでサポートされているデータ ソース
• 増分更新
• 自動mation* デプロイ パイプラインを使用して、別のリージョンにあるワークスペースにアイテムをデプロイすることはできません。

1 つのワークスペースをパイプラインに割り当て、それをパイプライン全体にデプロイする、または各パイプライン ステージに別々のワークスペースを割り当てることができます。 詳細については、「配置パイプラインにワークスペースを割り当てる」を参照してください。

DirectQuery または複合の接続モードを使用し、バリエーションまたは自動の日付/時刻のテーブルを含むデータセットは、デプロイ パイプラインではサポートされていません。 デプロイが失敗したときに、バリエーション テーブルを含むデータセットがあることが原因と思われる場合は、テーブルの列で variations プロパティを探すことができます。 次に示す方法のいずれかを使用して、配置パイプラインで機能できるようにセマンティック モデルを編集できます。

• データセットで DirectQuery または複合モードを使用するのではなく、インポート モードを使用します。

• セマンティック モデルから自動日付/時刻テーブルを削除します。 必要に応じて、テーブル内のすべての列から残りのバリエーションを削除します。 バリエーションを削除すると、ユーザーが作成したメジャー、計算列、計算テーブルが無効になる可能性があります。 この方法は、セマンティック モデル モデルの動作を理解している場合にのみ使用します。これにより、ビジュアルでデータが破損する可能性があるからです。

タイルをダッシュボードにピン留めする際、そのタイルがサポートされていないアイテム (このリストにないアイテムはすべてサポートされていません)、またはユーザーにデプロイ権限がないアイテムに依存している場合、ダッシュボードをデプロイした後にタイルはレンダリングされません。 たとえば、自分が管理者ではないセマンティック モデルに依存するレポートからタイルを作成すると、そのレポートを配置する際にエラー警告が表示されます。 ただし、タイルと一緒にダッシュボードをデプロイすると、エラー メッセージは表示されません。デプロイは成功しますが、タイルには何も情報が表示されません。

展開されたページ分割されたレポートの所有者は、レポートを展開したユーザーです。 ページ分割されたレポートを初めて配置している場合は、そのレポートの所有者になります。

ページ分割されたレポートを、そのページ分割されたレポートのコピーが既に存在するステージにデプロイしている場合は、前のレポートは上書きされ、前の所有者に代わって自分が所有者になります。 このような場合は、ページ分割されたレポートでデータを使用できるように、基になるデータ ソースに対する資格情報が必要です。

ページ分割されたレポートのサブレポートは、ページ分割されたレポートが保持されているのと同じフォルダーに保持されます。 選択的コピーを使用して、サブレポートを含むページ分割されたレポートをコピーしているときのレンダリング問題を回避するには、親レポートとサブレポートの両方を選択します。

ページ分割されたレポート ルールは、ページ分割されたレポートで同じステージのセマンティック モデルを参照先とする場合に作成できます。 ページ分割されたレポートの配置ルールを作成する場合は、データベースとサーバーを選択する必要があります。

Fabric セマンティック モデルを含まないページ分割されたレポートの配置ルールを設定している場合は、ターゲット データ ソースが外部にあるため、サーバーとデータベースの両方を指定する必要があります。

ただし、Fabric セマンティック モデルを使用するページ分割されたレポートでは、内部セマンティック モデルが使用されます。 このような場合は、接続先のFabric セマンティック モデルを識別するためにデータ ソース名を使用することはできません。 データ ソース ルールを作成するか、またはデータソースの更新 API を呼び出すと、データ ソース名はターゲット ステージで更新されても変更されなくなります。 配置ルールを設定する際に、データベース形式を保持し、データベース フィールドのセマンティック モデル オブジェクト ID を置き換える必要があります。 セマンティック モデルは内部にあるため、サーバーは同じままです。

• データベース -Fabric セマンティック モデルを含むページ分割されたレポートのデータベース形式は sobe_wowvirtualserver-<dataset ID>です。 たとえば、sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63 のようにします。 <dataset ID> をデータセットの ID に置き換えます。 データセット ID を URL から取得するには、datasets/ の後で、かつ次のフォワードスラッシュの前にある GUID を選択します。

  

• サーバー - データベースをホストするサーバー。 既存のサーバーをそのままにします。

デプロイ後、ページ分割されたレポートの RDL をダウンロードした場合、Power BI サービスで表示される最新バージョンでは更新されていない場合があります。

増分更新で構成されたセマンティック モデルを含むデータフローがある場合、配置中には更新ポリシーはコピーまたは上書きされません。 増分更新を含むセマンティック モデルが含まれたデータフローをこのデータフローを含まないステージに配置した後に、更新ポリシーがある場合には、ターゲット ステージで再構成する必要があります。 増分更新を使用するデータフローを、それが既に存在するステージにデプロイする場合、増分更新ポリシーはコピーされません。 このような状況で、ターゲット ステージの更新ポリシーを更新したい場合は、手動で行う必要があります。

配置パイプラインには、パイプライン ステージのデータマートに属するデータセットは表示されません。 データマートを配置すると、そのデータセットも配置されます。 データマートのデータセットは、そのステージのワークスペースで表示できます。

関連するコンテンツ

• Git 統合を開始する
• デプロイ パイプラインの使用を開始する