Standard から拡張データモデルへの移行の概要

Microsoft Power Platform CLI 移行ユーティリティは、既存の Power Pages サイトでサポートされている構成と関連レコードを標準データモデルから拡張データモデルに移動し、移行された構成を使用するようにサイトを切り替えます。

標準データモデルでは、adx_ プレフィックスを使用するテーブル間でPower Pagesサイト構成が格納されます。拡張データモデルは、 サイトコンポーネント テーブル (powerpagecomponent) にサイト構成を格納し、コンポーネントの種類によって各コンポーネントを識別します。移行ユーティリティのしくみ、サポートされているテンプレート、更新されないカスタマイズを理解すると、サイトを移動するタイミングと方法を決定するのに役立ちます。

強化されたデータモデルの利点を確認すると、サイトの移行を検討する理由が説明されています。

すべてのadx_* テーブルが powerpagecomponentに移動するわけではないことに注意してください。 adx_webpage、adx_webtemplate、adx_contentsnippet、adx_sitesetting、adx_pagetemplate、adx_weblink、adx_entityform、adx_entitylistなど、サイトの構造と作成サーフェイスを記述するメタデータ adx_* テーブルのみがpowerpagecomponentに統合されます (行ごとのプロパティがコンテンツ JSON 列に移動されます)。

トランザクション/ランタイム adx_* テーブル ( adx_invitation、 adx_inviteredemption、 adx_portalcomment、 adx_externalidentity、エンティティフォーム/高度なフォームの送信テーブル、ログテーブルなど、実行時のエンドユーザーアクティビティをキャプチャするテーブル) は、 powerpagecomponentに移行されず、既存のスキーマに残り、以前と同様にランタイムデータを格納し続けます。これらのトランザクションテーブルの変更点は、メタデータレコードへの参照が参照移行中に再配線され、レガシメタデータ adx_* 行ではなく新しい powerpagecomponent 行を指すようにすることです。

標準データモデルで作成された既存のサイトは引き続き adx_* テーブルで実行されるため、強化されたデータモデルを利用するには、各サイトを移行する必要があります。移行により、サイトの構成メタデータが拡張データモデル powerpagecomponent 図形に移動され、トランザクション参照がそれらの新しいメタデータレコードに再配線され、サイトレコードが拡張データモデルから提供されるように反転されます。また、カスタムの adx_* 列、adx_* 属性を読み取る Liquid、adx_* テーブルに対する FetchXML、プラグイン、ワークフローといったカスタマイズが洗い出され、対処されるのもここです。これは、これらのカスタマイズが自動的には移行されず、拡張されたデータモデルで動作するように書き換えるか再構成する必要があるためです。

前提条件

Microsoft Power Platform CLIバージョン 2.11.2 以降。サイトのダウンロード、移行、状態、アクティブ化、ロールバックの各コマンドを実行します。詳細については、「最新の Power Platform CLI をインストールする」を参照してください。
Dataverse 基本ポータルパッケージ CDSBasePortal9.3.2607.x 以降。必要な基本ポータルコンポーネントを提供します。
Power Pages Core パッケージ PowerPages_Core1.0.2605.x 以降。必要なPower Pagesランタイムコンポーネントを提供します。 Power Pages ソリューションを更新します。
アクティブなデータモデルの切り替えまたは元に戻すには、システム管理者、Dynamics 365管理者、または Power Platform 管理者ロールが必要です。
Power Pages用の Power Platform CLI に関する知識。
環境が管理モードの場合、バックグラウンド操作が有効になります。

移行ユーティリティの機能

移行ユーティリティは、サポートされているサイト構成と関連レコードを拡張データモデルにコピーします。移行が完了すると、アクティブなサイトは拡張データモデルに切り替わり、通常の使用に戻る前に検証されます。

移行ユーティリティ:

手動による変更が必要になる可能性があるカスタマイズのレポートを生成します。
サポートされているサイト構成と関連レコードを移行します。
アクティブなデータモデルを切り替える前に、移行の状態を確認できます。
検証で重大な問題が特定された場合は、サイトを標準データモデルに戻すことができます。

Important

移行ユーティリティでは、標準データモデルテーブルに直接依存するすべてのカスタマイズが自動的に更新されるわけではありません。運用環境で使用する前に、カスタマイズレポートを確認し、影響を受けるカスタムコードを修正し、移行されたサイトをテストします。

サポートされているテンプレート

次のテンプレートから作成された既存の標準データモデルサイトを移行できます。

スターターレイアウト 1-5
アプリケーションを処理しています
空白ページ
プログラム登録
会議のスケジュールと管理
FAQ
コミュニティポータル (Dynamics 365)
カスタマー Self-Service ポータル (Dynamics 365)
従業員 Self-Service ポータル (Dynamics 365)
パートナーポータル (Dynamics 365)

Note

拡張データモデルを使用して新しいサイトを作成し、既存のサイトを移行する機能は別です。サイトの元のテンプレートがここに一覧表示されていない場合は、そのサイトの移行ユーティリティを実行しないでください。

始める前の準備

計画に関するその他の考慮事項:

[拡張データモデルに切り替え] 環境設定は、新しいサイトに使用されるデータモデルを制御します。この設定を有効にしても、既存のサイトは移行されません。
最初に、運用環境の完全なコピーで移行を実行します。移行する前に、カスタマイズの修復と検証を完了します。
組織の標準的なバックアップと復元プロセスを使用して、運用環境をバックアップします。
最終本番切り替えと検証のためのメンテナンス時間帯を計画します。
Web サイト ID、ポータル ID、環境 URL、CLI バージョン、パッケージバージョン、移行開始時刻、およびコマンド出力フォームを移行レコードの一部として記録します。

環境シーケンスを計画する

移行では、環境ごとに異なるモードで、異なる環境がサポートされます。

環境	推奨モード	実施内容
Development	`configurationData`	構成の移行、カスタマイズレポートの確認、カスタマイズの修復、検証、ソリューションでの構成のキャプチャを行います。
テストまたはUAT	`configurationDataReferences`	開発からテスト済みのソリューションをインポートし、サポートされている関連レコードを移行し、拡張データモデルをアクティブ化して検証します。
生産	`configurationDataReferences`	検証済みのマネージドソリューションをインポートし、サポートされている関連レコードを移行し、メンテナンス期間中にアクティブ化し、運用検証を完了します。
単一環境または単純なサイト	`all`	カスタマイズの影響を理解し、マルチ環境ソリューションパスを使用しない場合にのみ、1 回の操作で構成と関連レコードを移行します。

作業フォルダーを作成する

空の作業フォルダーを使用して、レポート、ダウンロードしたサイトソース、および比較ファイルを保持します。次の例では、この場所に \<OUTPUT\> を使用します。

mkdir C:\PowerPagesMigration\<site-name>
cd C:\PowerPagesMigration\<site-name>

移行フェーズ

移行プロセスは、次の 4 つのフェーズで構成されます。

事前チェック — サイト、ID、CLI、パッケージ、テンプレートソリューション、移行の状態を確認します。
構成 — 開発環境の構成を移行するか、ダウンストリーム環境でテスト済みの構成をインポートします。
移行とアクティブ化 - 関連レコードの移行、完了の確認、モデルの切り替え、再起動。
検証 — 動作、アクセス許可、カスタムコード、テンプレート体験をテストします。

フェーズ 1 (サイトの検出と事前チェック) とフェーズ 4 (移行後の検証) は、すべてのサイトで同じ方法で実行されます。

フェーズ 2 とフェーズ 3 はトラック分岐です。その形状は、環境の種類からトラックを派生させる移行モードに依存します。

オーサリングトラック (モード configurationDataまたはall) は、開発環境と単一環境のセットアップに使用されます。メタデータ自体はローカルに移行され、トランザクション参照が移動する前に、カスタマイズがスキャンされ、標準データモデルソースに対して修正されます。

ダウンストリームトラック (モード configurationDataReferences) は、構成メタデータが Dev からの ALM ソリューションインポートを介して到着したと見なされるテスト、UAT、運用環境に使用されます。このトラックでは、トランザクション参照のみが移行されます。カスタマイズの結果は、ローカルで行う必要がある作業ではなく、アップストリームの ALM ギャップを示します。

フェーズ 1: 事前チェック

pac --versionを使用して Power Platform CLI のバージョンを確認します。お使いのバージョンが必要なバージョンより前の場合は、続行する前に、Microsoft Power Platform CLI をインストールまたは更新してください。
ターゲット環境に対して認証します。
1. pac auth list を実行します。
2. pac auth who を実行します。
アクティブな認証プロファイルが、サイトを含む環境を指していることを確認します。別のプロファイルを選択するか、プロファイルを作成するには、 pac auth select または pac auth create -u "https://contoso.crm.dynamics.com"を使用します。
次のいずれかの方法を使用して、テンプレートの拡張データモデルソリューションをインストールします。
1. 管理センターで拡張データモデル (EDM) フラグを有効にして、テンプレートのサイトをプロビジョニングします。
2. CLI を使用してコマンドを使用してインストールする pac application install --application-name "PowerPages_PartnerPortal_V2"
サイトを検索し、その識別子を pac pages list -vで記録します。

次の表に示す値を記録します。

Value	使用目的
Webサイト ID	すべての `migrate-datamodel` コマンド。
ポータル ID	拡張データモデルに切り替えて、標準データモデルに戻す。
フレンドリ名と URL	管理センターで適切なサイトを選択したことを確認します。
データモデルのバージョン	Standard である必要があります。既に拡張されている場合、移行は必要ありません。

Important

ポータル ID がPower Pagesアプリ ID ではありません。 CLI にポータル ID が表示されない場合は、Power Platform 管理センターの [リソース>サイトPower Pagesサイト>サイトの詳細] の下で使用できます。または、必要な Web サイトアクセス許可でサインインしているときにサイト URL に/_services/aboutを追加します。

次のコマンドを使用して、以前または進行中の移行を確認します。

pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatus

ステータス	意味	アクション
NotStarted またはトラッカーなし	移行は開始されません。	パッケージのチェックを続行します。
元に戻されました	以前の移行がロールバックされました。	元に戻された理由を確認し、準備ができたら続行します。
完了	移行は完了しましたが、サイトが切り替えされていない可能性があります。	アクティブなデータモデルを確認します。引き続き Standard の場合は、アクティブ化を続行します。
Running	移行はまだ処理中です。	状態の確認を続行します。同じサイトに対して別の移行を開始しないでください。
失敗	移行でエラーが発生しました。	コマンド出力と環境の詳細を収集し、原因を修正し、障害が認識された後にのみ再試行します。

Note

移行が予想以上に長時間 Running 状態のままの場合は、Microsoft サポートに問い合わせる前に、Web サイト ID、環境 ID、CLI バージョン、パッケージのバージョン、コマンド出力、および移行の開始時刻が必要です。サポートまたは承認済みのランブックから指示がない限り、進行中の移行をリセットしないでください。

pac solution list --includeSystemSolutionsで必要なファーストパーティパッケージを確認します。
1. サイトのテンプレートの CDSBasePortal、 PowerPages_Core、EDM ソリューションが必要なバージョンでインストールされていることを確認します。
パッケージが見つからないか古い場合は、Power Platform 管理センターから更新します。
1. ターゲット環境を開きます。
2. Resources>Dynamics 365 apps に移動します。
3. 必要なパッケージを見つけます。
4. [ インストール ] または [ アップグレード] を選択します。
5. 操作が完了するまで待ってから、もう一度 pac solution list --includeSystemSolutions 実行します。
Note

テンプレート EDM ソリューションを直接インストールできない場合は、同じテンプレートを使用して同じ環境に一時的な拡張データモデルサイトを作成すると、一致する EDM ソリューションがインストールされます。ソリューションの確認後に一時サイトを削除できます。
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --siteCustomizationReportPath "<OUTPUT>"を使用してカスタマイズレポートを生成します。レポートを生成しても、サイトは変更されません。

生成された CSV ファイルを開き、標準データモデルテーブルを参照する各項目を確認します。運用環境の移行前に、必要なすべての修復に所有者と検証手順を割り当てます。

カスタマイズカテゴリ	Plan
adx_ メタデータテーブルのカスタム列	powerpagecomponent に関連するサポートされているカスタムテーブルにカスタムデータを移動します。
adx_ メタデータテーブルへのリレーションシップ	サポートされている拡張データモデルテーブルに対してリレーションシップを再作成します。
Liquid または FetchXML での adx_ テーブルへの参照	サポートされている Liquid オブジェクト、仮想テーブル、または powerpagecomponent を使用するようにコードを更新します。
adx_ テーブルのワークフローとプラグイン	サポートされている拡張データモデルテーブルに対してロジックをリファクタリングして登録します。

Note

カスタマイズレポートでは、移行後にすべてのサイトの動作が動作するとは限りません。検証は引き続き必要です。

移行モードを選択して、ユーティリティが 1 回の操作で移行する内容を決定します。

Mode	移行対象	使用するタイミング
構成データ	ページ、Web テンプレート、スニペット、設定、フォーム、リスト、Web ロール、テーブルのアクセス許可など、サポートされているサイト構成メタデータ。	開発環境。ここでは、構成を修正し、ソリューションを通じて移行します。
構成データ参照	移行されたサイト構成を参照するサポートされているレコード。	ソリューションのインポートを通じてサイト構成が到着した後のテスト、UAT、運用。
すべて	構成と関連レコードの両方。	ソリューションベースの環境シーケンスを使用しない単一の環境または単純な移行。

フェーズ 2: サイト構成

オーサリングの追跡: 開発環境、あるいは単一の環境

pac pages download --webSiteId "<WEBSITE_ID>" --modelVersion 1 --path "<OUTPUT>\site-sdm"を実行して SDM ベースラインをダウンロードします。このコマンドにより、サイトに名前が付けられた子フォルダーが作成されます。 website.ymlを直接含むフォルダーを記録します。
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --mode configurationDataを実行してサイト構成を移行します。単一操作パスが必要な場合は、 configurationData を all に置き換えます。
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatusを実行して移行の状態を確認します。次の PowerShell ループを使用して、最大 30 分間、1 分に 1 回状態を確認します。
```
$webSiteId = "<WEBSITE_ID>"
for ($i = 1; $i -le 30; $i++) {
    $output = pac pages migrate-datamodel `
        --webSiteId $webSiteId `
        --checkMigrationStatus 2>&1 | Out-String
    if ($output -match "Completed|Failed|Reverted") {
        Write-Host $output
        break
    }
    Write-Host "Attempt $i/30 - migration is still running."
    Start-Sleep -Seconds 60
}
```
ループが終了した時点でステータスがまだ「実行中」の場合、チェックは --checkMigrationStatus で続行されます。実行時間の長い操作は、必ずしも失敗した操作であるとは限りません。
この記事のカスタマイズレポートとガイダンスを使用して、報告されたカスタマイズを修復し、影響を受ける FetchXML、Liquid、カスタム列、リレーションシップ、ワークフロー、プラグインを更新します。変更された各コンポーネントを再テストします。ダウンロードしたソースを更新する場合は、pac pages upload --path "<OUTPUT>\site-sdm\<site-slug>" --modelVersion 1を実行して、website.ymlを直接含むサイトフォルダーをアップロードします。

ダウンストリームトラック: テスト、UAT、または運用

移行および修復されたサイト構成を含むソリューションをインポートします。 Power Platform 管理センターまたは確立されたデプロイパイプラインを使用します。
```
pac solution import --path "<PATH_TO_SOLUTION_ZIP>" --activate-plugins true --publish-changes true
```
ターゲット環境でPower Pages管理アプリを開いて、サイト構成が存在することを確認します。関連レコードが移行される前に、サイトレコードと予想される構成が存在する必要があります。

サポートされている関連レコードを移行します。 --mode allを既に使用している場合は、この手順をスキップします。完了と報告されるまで状態を確認 します。
```
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --mode configurationDataReferences
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --checkMigrationStatus
```
移行状態が正常に完了したことを報告したら、アクティブなサイトを拡張データモデルに切り替えます。標準データモデル Web サイトレコードが非アクティブ化され、対応する拡張データモデル Web サイトレコードがアクティブになります。
```
pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --updateDatamodelVersion --portalId "<PORTAL_ID>"
```
サイトを再起動します。
1. Power Platform 管理センターを開きます。
2. 環境に移動し、リソース>Power Pages サイトを選択します。
3. サイトを選択します。
4. [Restart](再起動) をクリックします。 [再起動] を使用できない場合は、サイトを非アクティブ化してからアクティブ化します。
5. 検証の前に操作が完了するまで待ちます。
次の 1 つ以上の方法を使用して、アクティブなデータモデルを確認します。
1. Power Platform 管理センターで、サイトを選択し、 データモデル に [拡張] が表示されていることを確認します。
2. デザインスタジオでサイトのセットアップ ワークスペースPower Pages開き、表示されているデータモデルを確認します。
3. Power Pages管理アプリで高度な構成が開かれることを確認します。
4. pac pages list -v実行し、データモデルのバージョンを確認します。
Tip

サイトの URL とビジュアルデザインは、アクティブなデータモデルが変更されたからといって変更されません。移行を確認するには、サイトの外観ではなく、これらのチェックを使用します。

フェーズ 4: 移行されたサイトを検証する

ユーザーに対して運用サイトを再度開く前に、検証を完了します。重要なユーザーの種類と Web ロールごとにテストアカウントを使用し、すべての重要なテストの結果を記録します。

領域	検証対象
ページとコンテンツ	ホームページ、代表的なコンテンツページ、Web テンプレート、コンテンツスニペット、Web ファイル、ナビゲーション、リダイレクト、多言語コンテンツ。
Authentication	サインイン、サインアウト、登録、招待、外部 ID プロバイダー、アクセス拒否エクスペリエンス。
認証	Web ロール、テーブルのアクセス許可、列のアクセス許可、およびページアクセス規則は、予期されるアクションを許可および拒否します。
フォームとリスト	サイトで使用される基本的なフォーム、マルチステップフォーム、リスト、フォームメタデータ、送信、関連レコード、Web フォームセッション。
Dynamics 365 テンプレートジャーニー	テンプレート固有のページやアクセスパターンなど、実装で使用される主要な顧客、従業員、コミュニティ、またはパートナー体験。
カスタムコード	カスタマイズレポートで識別される Liquid、FetchXML、JavaScript、プラグイン、ワークフロー、および統合。
サイトの設定とファイル	サイト設定、画像、添付ファイル、SVG ファイル、およびその他の Web ファイルが正しく読み込まれます。
データと参照	重要なレコード数とサポートされている関連レコードは、移行された正しいサイトコンポーネントを指します。
管理と ALM	サイトは Power Pages Management で開き、ソリューションに必要に応じて追加、エクスポート、およびソリューションからインポートできます。

ブラウザーの診断を確認する

代表的なページのテスト中にブラウザー開発者ツールを開きます。調査:

adx\_、エンティティ、Liquid、または FetchXML に関するコンソールエラー。
\_apiからの HTTP 401 または 403 応答。アクセス許可または Web ロールの問題を示している可能性があります。
HTTP 500 応答。Liquid、FetchXML、プラグイン、または統合エラーを示すことができます。

移行の完了条件

サイトで拡張データモデルが表示され、重要なビジネス体験が成功し、予想されるセキュリティ動作が確認され、影響の大きいカスタマイズの検出がすべて解決または受け入れられる場合にのみ、移行が完了することを検討してください。

運用移行シーケンス

移行リスクを軽減するには、次の運用シーケンスを使用します。

リハーサル用の運用環境の完全なコピーを作成します。
コピーした環境で CLI、パッケージ、およびテンプレートソリューションの前提条件を確認します。
カスタマイズレポートを生成して確認します。
コピーした開発環境で構成を移行します。
カスタマイズを修復し、マネージドソリューションで検証済みのサイト構成をキャプチャします。
リハーサル環境にソリューションをインポートし、サポートされている関連レコードを移行し、拡張データモデルをアクティブ化して、完全な検証チェックリストを完了します。
すべての重要なテストが成功するまで修復とリハーサルを繰り返します。
運用メンテナンス期間をスケジュールし、検証とロールバックの決定ポイントを伝え、運用をバックアップします。
運用パッケージとテンプレートソリューションの前提条件をもう一度確認します。
検証済みのマネージドソリューションを運用環境にインポートします。
configurationDataReferences実行し、移行の状態を確認し、アクティブなデータモデルを切り替えて、サイトを再起動します。
運用検証チェックリストを実行し、重要なテストに合格した後にのみサイトを通常の使用に戻します。

移行されたサイトを標準データモデルに戻す

検証でアクティブ化後に重大な問題が特定された場合は、次のコマンドを使用して標準データモデル Web サイトレコードを再アクティブ化します。

pac pages migrate-datamodel --webSiteId "<WEBSITE_ID>" --revertToStandardDataModel --portalId "<PORTAL_ID>"

コマンドの完了後:

Power Platform 管理センターからサイトを再起動します。
サイトに Standard がアクティブなデータ モデルとして表示 されていることを確認します。
サイトの重要な検証テストを再実行します。
別の移行を試みる前に、移行レポート、エラーの詳細、修復に関するメモを保持します。

Important

運用環境の移行前にロールバックの決定を計画します。標準の Web サイトレコードと拡張 Web サイトレコードは別々のレコードであるため、元に戻す前に拡張データモデルの切り替え後に行われた変更を確認します。

Troubleshooting

メッセージまたは症状	考えられる原因	アクション
`pac powerpages migrate-datamodel` が認識されない	このコマンドでは、間違った名前空間または古い CLI が使用されます。	Power Platform CLI を更新し、 `pac pages migrate-datamodel`を使用します。
`CDSBasePortal` または `PowerPages_Core` が一覧に表示されない	システムソリューションがコマンド出力に含まれていないか、パッケージがインストールされていません。	`pac solution list --includeSystemSolutions` を実行します。不足しているパッケージを Power Platform 管理センターからインストールまたはアップグレードします。
Web サイトの移行はサポートされていません	元のテンプレートはサポートされていません。パッケージのバージョンが不十分であるか、一致する EDM テンプレートソリューションがありません。	テンプレートの適格性、パッケージのバージョン、およびテンプレートソリューションリファレンスに記載されている EDM ソリューションを確認します。
不明な引数 `--webSiteId` が渡されました `pac pages upload`	upload コマンドは、Web サイト ID 引数を受け入れていません。	引数を省略します。サイトは `website.yml`から識別されます。
アップロード先のサイトが間違っているか、サイトが見つからない	パスは、サイトフォルダーではなくラッパーフォルダーを指します。	website.ymlを直接含む子フォルダーを使用します。
ポータル ID に `Unknown` または `N/A`	サイトが非アクティブであるか、インストールされている CLI が値を返しません。	Power Platform 管理センターまたはサイトの `/_services/about` ページからポータル ID を取得します。アプリ ID は使用しないでください。
移行レポートでは `Completed` と表示されますが、サイトには依然として `Standard` が表示されます。	アクティブなデータモデルが切り替えられなかったか、間違ったポータル ID が使用されました。	Web サイト ID と正しいポータル ID を使用してアクティブ化コマンドを実行し、サイトを再起動して確認します。
状態は引き続き `Running`	移行が大量のデータを処理しているか、ブロックされています。	状態の確認を続行します。サポートに連絡する前に、環境、パッケージ、CLI、開始時刻、およびコマンドの詳細を収集します。 2 回目の移行を開始しないでください。
ステータスは `Failed`	パッケージ、テンプレート、カスタマイズ、データ、またはサービスエラーが操作を停止しました。	完全なコマンド出力を保存し、特定された原因を修正し、失敗した移行状態を確認した後にのみ再試行します。
サイトが開きますが、ユーザーは予想されるデータにアクセスできません	Web ロール、テーブルのアクセス許可、またはカスタムクエリは、移行後に想定どおりに動作しません。	Web ロール、テーブルのアクセス許可、列のアクセス許可、FetchXML、Liquid、ブラウザーのネットワークエラーを確認します。

サイトのカスタマイズに関する考慮事項

カスタマイズレポートは、標準データモデルテーブルへの直接の依存関係を識別します。運用環境で使用する前に、必要な修復を完了します。

メタデータテーブルのカスタム列

adx_webpageなどの標準データモデルテーブルにカスタム列が含まれている場合は、カスタムデータを格納するカスタムテーブルを作成し、powerpagecomponentに参照を追加します。カスタム値を新しいテーブルに移行し、列の読み取りまたは書き込みを行うコードを更新します。

カスタムテーブルとメタデータテーブル間のリレーションシップ

adx_テーブルを指すカスタムリレーションシップを再作成して、適切な拡張データモデルテーブル (通常はpowerpagecomponent) を指します。依存フォーム、ビュー、プラグイン、フロー、統合を更新します。

メタデータテーブルへの液体参照

サポート対象の Liquid オブジェクトが存在する場合は、entities['adx_*'] への直接アクセスをそのオブジェクトに置き換えてください。たとえば、adx_weblinksetまたは関連テーブルに直接クエリを実行する代わりに、weblinks Liquid オブジェクトを使用します。返されるオブジェクトと使用可能な属性が異なる可能性があるため、各使用を確認します。

メタデータテーブルへの FetchXML 参照

直接 adx_ エンティティ参照を対応する仮想テーブルまたはクエリ powerpagecomponent に置き換え、フィルター処理を行います。 powerpagecomponenttype

標準データモデルの例:

<fetch>
  <entity name="adx_webpage">
    <attribute name="adx_name" />
    <filter>
      <condition attribute="adx_partialurl" operator="eq" value="home" />
    </filter>
  </entity>
</fetch>

拡張データモデルの例:

<fetch>
  <entity name="powerpagecomponent">
    <attribute name="name" />
    <filter type="and">
      <condition attribute="powerpagecomponenttype" operator="eq" value="2" />
      <condition attribute="partialurl" operator="eq" value="home" />
    </filter>
  </entity>
</fetch>

カスタムワークフローとプラグイン

adx_ テーブルに登録されているカスタムワークフローとプラグインロジックをリファクタリングします。更新されたロジックを適切な拡張データモデルテーブルに登録し、拡張スキーマと属性を使用します。非運用環境での作成、更新、削除、およびセキュリティの動作をテストします。

コマンドリファレンス

Purpose	命令
CLI のバージョンを確認する	`pac --version`
認証プロファイルを一覧表示する	`pac auth list`
認証プロファイルを作成する	`pac auth create -u "<ENV_URL>"`
サイトと識別子を一覧表示する	`pac pages list -v`
システムソリューションを一覧表示する	`pac solution list --includeSystemSolutions`
移行の状態を確認する	`pac pages migrate-datamodel --webSiteId "<ID>" --checkMigrationStatus`
SDM ソースのダウンロード	`pac pages download --webSiteId "<ID>" --modelVersion 1 --path "<OUT>\site-sdm"`
EDM ソースのダウンロード	`pac pages download --webSiteId "<ID>" --modelVersion 2 --path "<OUT>\site-edm"`
カスタマイズレポートを生成する	`pac pages migrate-datamodel --webSiteId "<ID>" --siteCustomizationReportPath "<OUT>"`
構成の移行	`pac pages migrate-datamodel --webSiteId "<ID>" --mode configurationData`
関連レコードを移行する	`pac pages migrate-datamodel --webSiteId "<ID>" --mode configurationDataReferences`
両方のカテゴリを移行する	`pac pages migrate-datamodel --webSiteId "<ID>" --mode all`
サイトソースのアップロード	`pac pages upload --path "<SITE_ROOT>" --modelVersion 1`
EDM のアクティブ化	`pac pages migrate-datamodel --webSiteId "<ID>" --updateDatamodelVersion --portalId "<PORTAL_ID>"`
SDM に戻す	`pac pages migrate-datamodel --webSiteId "<ID>" --revertToStandardDataModel --portalId "<PORTAL_ID>"`

サイトコンポーネントの種類のリファレンス

powerpagecomponentクエリを実行するときは、powerpagecomponenttype フィルターで次の値を使用します。

Component	Value	Component	Value
公開状況	1	Web ページ	2
Web ファイル	3	Web リンクセット	4
Web リンク	5	ページテンプレート	6
コンテンツスニペット	7	Web テンプレート	8
サイト設定	9	Web ページアクセス制御ルール	10
Web ロール	11	Web サイトのアクセス	12
サイトマーカー	13	基本フォーム	15
基本フォームメタデータ	16	リスト	17
テーブルのアクセス許可	18	詳細フォーム	19
詳細フォームステップ	20	詳細フォームメタデータ	21 (二十一)
投票配置	24	広告配置	26
ボット利用者	二十七	列パーミッションプロファイル	28
列のアクセス許可	二十九	リダイレクト	30
公開状態の移行ルール	31	Shortcut	32
クラウドフロー	33	UX コンポーネント	34

EDM テンプレートソリューションリファレンス

pac solution list --includeSystemSolutions実行して、サイトのテンプレートの拡張データモデルソリューションがインストールされていることを確認します。

テンプレート	EDM ソリューションの一意の名前
スターターレイアウト 1	DefaultPortalTemplate_V2
スターターレイアウト 2	PowerPages_BlankDesign002_V2
スターターレイアウト 3	PowerPages_BlankDesign003_V2
スターターレイアウト 4	PowerPages_BlankDesign004_V2
スターターレイアウト 5	PowerPages_BlankDesign005_V2
空白ページ	PowerPages_BlankTemplate_V2
FAQ	PowerPages_FAQ_V2
アプリケーションを処理しています	PowerPages_BuildingPermit_V2
プログラム登録	PowerPages_ProgramRegistration_V2
会議のスケジュールと管理	PowerPages_BookMeeting_V2
コミュニティポータル (Dynamics 365)	PowerPages_CommunityPortal_V2
カスタマー Self-Service ポータル (Dynamics 365)	PowerPages_CustomerPortal_V2
従業員 Self-Service ポータル (Dynamics 365)	PowerPages_ESSPortal_V2
パートナーポータル (Dynamics 365)	PowerPages_PartnerPortal_V2

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-09-01

Standard から拡張データ モデルへの移行の概要

前提条件

移行ユーティリティの機能

サポートされているテンプレート

始める前の準備

環境シーケンスを計画する

作業フォルダーを作成する

移行フェーズ

フェーズ 1: 事前チェック

フェーズ 2: サイト構成

オーサリングの追跡: 開発環境、あるいは単一の環境

ダウンストリーム トラック: テスト、UAT、または運用

フェーズ 3: 関連レコードとアクティブ化

フェーズ 4: 移行されたサイトを検証する

ブラウザーの診断を確認する

移行の完了条件

運用移行シーケンス

移行されたサイトを標準データ モデルに戻す

Troubleshooting

サイトのカスタマイズに関する考慮事項

メタデータ テーブルのカスタム列

カスタム テーブルとメタデータ テーブル間のリレーションシップ

メタデータ テーブルへの液体参照

メタデータ テーブルへの FetchXML 参照

カスタム ワークフローとプラグイン

コマンド リファレンス

サイト コンポーネントの種類のリファレンス

EDM テンプレート ソリューション リファレンス

関連するコンテンツ

フィードバック

その他のリソース

Standard から拡張データモデルへの移行の概要

ダウンストリームトラック: テスト、UAT、または運用

移行されたサイトを標準データモデルに戻す

メタデータテーブルのカスタム列

カスタムテーブルとメタデータテーブル間のリレーションシップ

メタデータテーブルへの液体参照

メタデータテーブルへの FetchXML 参照

カスタムワークフローとプラグイン

コマンドリファレンス

サイトコンポーネントの種類のリファレンス

EDM テンプレートソリューションリファレンス