Experience Cloud Developer Guide (Experience Cloud 開発者ガイド)
jメタデータ API を使用した Experience Cloud サイトのリリース
メタデータ API を使用して、Salesforce 組織間で Experience Cloud サイトを移行します。テスト環境でサイトの設定とテストを行ってから、サイトのデータを取得して本番組織にリリースします。
| 使用可能なインターフェース: Salesforce Classic (使用できない組織もあります) および Lightning Experience |
| 使用可能なエディション: Enterprise Edition、Performance Edition、Unlimited Edition、および Developer Edition |
メタデータ API を使用して、エクスペリエンスビルダーと Salesforce タブ + Visualforce サイトを移行できます。
次のメタデータ型を組み合わせてサイトを定義します。サイトを移行するには、メタデータ API の retrieve コールを使用して、組織のコンポーネントの XML ファイル表現を取得します。
- Network — Experience Cloud サイトを表します。ページの上書き、メール、メンバーシップの設定などの管理設定が含まれています。
- CustomSite — indexPage、siteAdmin、URL 定義など、ドメインとページの設定情報が含まれています。
-
ExperienceBundle または SiteDotCom — エクスペリエンスビルダーサイトをリリースする場合、SiteDotCom ではなく ExperienceBundle を使用することをお勧めします。ExperienceBundle は、エクスペリエンスビルダーサイトを構成するさまざまなエクスペリエンスビルダー設定およびサイトコンポーネント (ページ、ブランドセット、テーマなど) の、人間が判読可能なテキストベースの表現を提供します。
Summer ’19 リリース以前 (API バージョン 45.0 以前) は、Network、CustomSite、SiteDotCom メタデータ型を組み合わせてエクスペリエンスビルダーサイトを定義していました。ただし、SiteDotCom 型を取得すると、人間が判読できないバイナリの .site ファイルが生成されました。ExperienceBundle 型を有効にすると、編集可能なサイトメタデータを取得し、エクスペリエンスビルダーサイトをプログラムですばやく作成、更新、公開、リリースできます。「ExperienceBundle for Experience Builder Sites (エクスペリエンスビルダーサイトの ExperienceBundle)」を参照してください。
これらのメタデータ型についての詳細とデータ移行の手順は、『メタデータ API 開発者ガイド』と『Salesforce CLI コマンドリファレンス』を参照してください。
ヒントと検討事項
- データを別の組織に移行する前に、エラーの発生を避けるため、移行先の組織でデジタルエクスペリエンスを有効化し、Sandbox 組織で使用したものと同じドメイン名を入力します。
- 各 Experience Cloud サイトのネットワークコンポーネントには、一意の名前と URL パスプレフィックスがあります。ネットワークコンポーネントを取得すると生成される XML ファイル名は、ネットワークの名前に基づきます。移行時に API でファイル名が参照され、ファイル名が存在している場合はサイトが更新されます。存在していない場合、API でサイトが作成されます。誰かが Sandbox でサイト名を変更して移行しようとすると、API によって既存のパスプレフィックスでサイトの作成が試行されるため、エラーが表示されます。
- すべての連動関係が取り込まれていることを CustomSite の XML ファイルで確認します。いずれかがない場合、XML ファイルで明示的に指定します。
- Network、CustomSite、および ExperienceBundle コンポーネントに加えて、カスタムオブジェクト、カスタム項目、カスタム Lightning コンポーネント、Apex クラスなど、サイトに必要な他のコンポーネントをすべて含めます。
- ロック解除済みパッケージを使用して Network コンポーネントと Profile コンポーネントをリリースするには、コンポーネントごとに個別のロック解除済みパッケージを作成して個別にリリースします。
- ExperienceBundle を使用してエクスペリエンスビルダーサイトをリリースする場合、SiteDotCom 型がマニフェストファイルに含まれていないことを確認します。
- でサイトの名前を変更する場合は、リリース元サイトとリリース先サイトで、Network コンポーネントの picassoSite 属性と site 属性の値が一致することを確認します。
- ゲストユーザプロファイルに変更があった場合は、サイト移行の一部としてプロファイルを含めます。
- ユーザプロファイルを移行すると、ユーザが本番組織のサイトに追加されます。その後、新しいサイトの場合と同じようにメールがメンバーに送信されます。
- リリース中、対象組織の NavigationMenu API 参照名がソース組織の API 参照名と同じであることを確認します。
- containerType が CommunityTemplateDefinition の場合、メタデータ API を介して既存の NavigationMenu を更新することはできません。
- メニュー項目を追加したナビメニューをリリースすると、対象環境の既存のメニュー項目に適用されているすべての翻訳が削除されます。
- 以前のリリースバージョンを使用している対象組織にリリースすることはできません。たとえば、ソース組織が Summer '19 (API バージョン 46.0) の場合、Spring '19 (API バージョン 45.0) の対象組織にはリリースできません。
- NavigationLinkSet は、Winter '20 (API バージョン 47.0) で廃止され、NavigationMenu に置き換えられました。
- ExperienceBundle では、異なる API バージョンでの取得およびリリースはサポートされません。ExperienceBundle メタデータを古い API バージョンから新しいバージョン (API バージョン 48.0 から 49.0 など) にアップグレードする場合は、次の手順を実行します。
- package.xml マニフェストファイルの API バージョンを 48.0 に設定して、パッケージをリリースします。
- 次に、package.xml の API バージョンを 49.0 に設定します。
- パッケージを取得して、ExperienceBundle の最新の更新を取得します。
サンプルテンプレート
次のサンプルには、メタデータ API で移行できるすべての項目が含まれています。
package.xml マニフェストファイルのサンプル
マニフェストファイルでは、取得するコンポーネントを定義します。次のサンプルに、エクスペリエンスビルダーサイトのすべてのコンポーネントを取得するための package.xml マニフェストファイルを示します。