この文章は Salesforce 機械翻訳システムを使用して翻訳されました。詳細はこちらをご参照ください。

エクスペリエンスビルダーサイトの ExperienceBundle

ExperienceBundle メタデータ型は、エクスペリエンスビルダーサイトを構成するさまざまな設定およびコンポーネント (ページ、ブランドセット、テーマなど) のテキストベースの表現を提供します。サイトが独自の組織用であるかどうかにかかわらず、またはあなたがコンサルティングパートナーまたは ISV であるかどうかにかかわらず、VS Code 向け Salesforce 拡張機能、Salesforce CLI、お気に入りの IDE またはテキストエディタなど、好みの開発ツールを使用してサイトをプログラムですばやく更新し、リリースします。

Summer ’19 リリース以前 (API バージョン 45.0 以前) は、Network、CustomSite、SiteDotCom メタデータ型を組み合わせてエクスペリエンスビルダーサイトを定義していました。ただし、SiteDotCom 型を取得すると、人間が判読できないバイナリの .site ファイルが生成されました。SiteDotCom ではなく ExperienceBundle 型を取得すると、3 レベルのフォルダ構造に含まれる詳細なサイトメタデータを、人間が判読可能な形式で抽出して編集できます。

制限事項

管理パッケージはサポートされません。

ExperienceBundle の構造

ExperienceBundle を取得すると、データは 3 レベルのフォルダ構造に保存されます。

experiences フォルダには、組織の各エクスペリエンスビルダーサイト用のフォルダが含まれます。各 site_name フォルダ (この例では customer_service) には、サイトを定義し、エクスペリエンスビルダーでアクセスするさまざまな要素を表すサブフォルダが含まれます。各サブフォルダは、ローカルマシンやスクラッチ組織で編集してからリリースできるプロパティが入った .json ファイルを持っています。 ExperienceBundle のフォルダ

各エクスペリエンスビルダーサイトを定義するファイルを詳しく見てみましょう。

フォルダ	内容
brandingSets	`branding_set_name`.json は、サイトのブランドセットプロパティを定義します。
config	`site_name`.json は、公開アクセスや順次表示などのサイト設定を定義します。 languages.json は、サポートされる言語を定義します。 loginAppPage.json と mainAppPage.json は、単一ページアプリケーション (SPA) です。loginAppPage.json は、ログインを必要とするサイトページで使用します。mainAppPage は、他のすべてのページで使用します。 SPA は、1 つの HTML ページを読み込む Web アプリケーションです。ユーザが移動する複数のページで構成される従来の Web サイトとは異なり、SPA は、ユーザが操作するときにページを動的に更新するための複数のビューで構成されています。
routes	URL や他のルート関連情報を定義する `page_name`.json という名前のファイルがページごとに 1 つ含まれます。
themes	テーマを定義する `theme_name`.json という名前のファイルがテーマごとに 1 つ含まれます。
variations	`experienceVariation_name`.json という名前のファイルがバリエーションごとに 1 つ含まれます。環境のバリエーションを使用することで、利用者ごとにエクスペリエンスビルダーサイトにおけるブランド設定、ページバリエーション、コンポーネントの表示、コンポーネントの属性などのデフォルト動作を変更できます。
views	`view_name`.json という名前のファイルがビューごとに 1 つ含まれます。各ファイルは、エンドユーザに表示するページに相当する SPA ビューを定義します。ビューは、表示されるページ内の他の領域やコンポーネントを含む領域から構成されます。

エクスペリエンスビルダーサイトの .json ファイルを更新する前に、バックアップとしてサイトのフォルダをコピーすることをお勧めします。

ヒント

ExperienceBundle の完全な定義と、含まれるファイルについては、『メタデータ API 開発者ガイド』を参照してください。

ExperienceBundle のメタデータ型の有効化

Aura サイトの ExperienceBundle を有効化すると、メタデータ API コール (retrieve および deploy) と Salesforce DX 操作 (pull、push、status) は SiteDotCom 型ではなく ExperienceBundle 型を使用します。

変更セットを使用してサイトをリリースすると、連動関係のリストには Site.com 型の 2 つの項目 (MySiteName and MySiteName1) が含まれます。MySiteName1 は、SiteDotCom ではなく ExperienceBundle を表すようになります。

LWR サイトの ExperienceBundle メタデータ型を有効にする必要はありません。LWR サイトでは、デフォルトで ExperienceBundle が使用されます。

メモ

[設定] から、[クイック検索] ボックスに「デジタルエクスペリエンス」と入力し、[設定] を選択します。
[ExperienceBundle メタデータ API を有効化] を選択します。
変更内容を保存します。

あるいは、スクラッチ組織定義ファイルを使用してスクラッチ組織を作成するときにこの機能を有効に��ることもできます。(「Metadata Coverage (対象メタデータ)」レポート」を参照)。

メタデータ API を使用した ExperienceBundle の取得とリリース

メタデータ API では、マニフェストファイルは、取得するコンポーネントを定義します。次の例は、SiteDotCom ではなく ExperienceBundle を使用してエクスペリエンスビルダーサイトを取得する package.xml マニフェストファイルを示しています。

.zip ファイルを取得したら、展開して取り出したファイルを開いて編集してください。 zip ファイルの内容

「zip ファイルを使用したメタデータのリリースと取得」を参照してください。

Salesforce DX を使用した ExperienceBundle の取得とリリース

Salesforce Developer Experience (DX) は、開発ライフサイクル全体を合理化するツールセットです。Salesforce DX によって、チーム開発とコラボレーションが向上し、自動テストと継続的インテグレーションが促進され、リリースサイクルがより効率的で俊敏になります。

Salesforce DX 環境を設定してある場合は、以下をすばやく行うことができます。

sfdx force:source:pull を使用して組織内のすべてのエクスペリエンスビルダーサイトを取得する
sfdx force:source:push を使用して更新をリリースする
sfdx force:source:status を使用してサーバ上の競合や変更を確認する
sfdx force:community:template:list を使用して使用可能なテンプレートのリストを取得する
sfdx force:community:create を使用してサイトを作成する
sfdx force:community:publish を使用してエクスペリエンスビルダーサイトを公開する

ExperienceBundle を有効化した場合、Salesforce DX の pull 操作を既存のエクスペリエンスビルダーサイトで正常に使用するには、最初にエクスペリエンスビルダーでサイトを更新する必要があります。この機能を有効化した後で作成した新規サイトでは、pull 操作は直ちに機能します。

メモ

Salesforce DX に不慣れな場合は、以下の役に立つリソースを参照してください。

Experience Cloud 開発者ガイド