たまに質問がありますが、ほぼ誰も回答していないですね。私の嫌いなNPSPよりも回答がない。
ちょっと勉強してみますかね。

大事そうなところをメモします。

いきなり学習意欲を削ぐ仕打ち。案外多いんですよね。Pardotとかフィールドサービスもそうだ。

Trailhead Playground では B2C Commerce を使用できません。B2C Commerce is not available in the Trailhead Playground.

Commerce Cloud のリファレンスサイト

初めに

Business Manager を使用する人には 3 つのタイプがある

マーチャンダイザーは、商品、画像、キャンペーン、プロモーション、検索設定などのサイトデータを設定します。
管理者は、B2C Commerce サイトの設定、サイトデータのインポートやエクスポート、コードやデータの変更のロールアウトを行います。
デベロッパーは、Business Manager を使用してストアフロントアプリケーションに直接アクセスし、デバッグや問題のトラブルシューティング、開発固有の設定などを行います。

B2C Commerce では、顧客という用語に複数の意味があります。ここではわかりやすいように、Salesforce のお客様をマーチャントと呼び、マーチャントの顧客を買い物客とします。

B2C Commerce はオブジェクト指向のシステムである。

B2C Commerce ストアフロントアプリケーションを開発するということかな？

通常のAuraコンポーネントでの開発とはかなり用語が違う。知らん用語がどんどん出てきます。

B2C Commerce の主なソフトウェア開発ツールは、Business Manager、Microsoft Visual Studio Code、Commerce Cloud ストアフロントリファレンスアーキテクチャ (SFRA) の 3 つです。他に次のようなツールがあります。

テンプレート
フォーム定義
リソースバンドル
スクリプト
コントローラー

B2C Commerce のカートリッジ

カートリッジとは、B2C Commerce がプログラムのコードやデータをパッケージ化してリリースする手段で、汎用またはアプリケーション固有の機能を備えています。たとえば、マーチャントが複数のブランドを個別のサイトで販売しているとします。アパレルを扱っているため、どのサイトもプロセスは同様ですが、サイトの外観がブランドごとに異なります。汎用カートリッジには標準のプロセスが格納されるのに対し、アプリケーション固有のカートリッジにはブランド固有のコードやデータが格納されます。

何を構築するのか
では、ここで構築するものを上位から順に見ていきましょう。

ストアフロントページは、デスクトップでもモバイルデバイスでも、クライアント上に表示されます。以下は、標準のストアフロントページの一部です。

ホーム
カテゴリ
注文の詳細
検索結果

これらのページは HTML に基づく専有の ISML 形式で、フォーマットには CSS を使用する業界標準です。買い物客は、ボタンやタブをクリックしたり、項目にテキストを入力したりしてこれらのページを操作します。ここで使用する開発ツールは、テンプレートとフォーム定義というものです<-- 画面のこと？

クライアントとサーバーの両方にアプリケーション処理コンポーネントがあります。このコンポーネントは、ページからクリックやデータ入力を取得して処理するコードです。ここで使用する開発ツールは、スクリプトとコントローラーです。

ストアフロントページのコード化
ストアフロントページは視覚的なページで、魅力的な商品、華やかな広告、気の利いた割引で目を引きます。こうしたページには、テンプレート、フォーム、定義、リソースバンドルが必要です。ただし、クライアントベースに限られます。
テンプレート
テンプレートは、データやページ情報を HTML ベースの Web ページにどのように変換するかを定義します。これらのページがブラウザーに表示される際、ページレイアウトやスタイル設定には CSS、データの表示や検証には B2C Commerce のフォーム定義が使用されます。テンプレートは、HTML を動的に生成する Internet Store Markup Language (ISML) でコード化されます。複数の事前定義されたタグ (/ など) が提供され、スクリプトブロックや式が使用されます。

ISML を使用すると、1 つのテンプレートで何千もの商品を表示できます。たとえば、検索結果ページには、テンプレートで定義されているとおりのタイルの行と列に商品のリストが表示されます。

フォーム定義
フォーム定義では、顧客が入力した値をどのように検証してブラウザーに表示するかを管理できます。たとえば、フォームを使用して、郵便番号は正確な一連の整数として入力する必要があり、名前とアドレス情報は文字列として入力する必要があることを指定できます。ISML と同様に、B2C Commerce のフォーム定義は、独特の専有言語を使用します。

フォーム定義は、カートリッジのフォームフォルダー (cartridge/forms/default) に格納されます。フォームスキーマファイルは、許可される要素と属性を特定します。フォーム定義は、ストアフロントアプリケーションの表示の部分と処理の部分の両方とやりとりします。

リソースバンドル
買い物客に表示されるストアフロントのコードでは、ハードコード化されたテキスト文字列を避けることが望まれます。そのため、タイトル、表示ラベル、メッセージ、ボタン、項目名はリソースバンドル (.properties ファイルともいう) に保存します。このテキストを表示レイアウトと分けておけば、特にさまざまな地域情報をサポートしている場合に、テキストを目的ごとに簡単に変更できます。
ストアフロントアプリケーションの処理

アプリケーションの処理においては、訪問から注文手続きまですべて買い物客の動作に従って適切な詳細を表示、送信、計算、取得します。アプリケーションはこのために、スクリプトとコントローラーを使用します。

コードをアップロードするために、SFRA アップロードツールまたは webdav などの標準プロトコルのアップロードユーティリティを使用する必要があります。アップロードユーティリティは、GitHub にある B2C Commerce コミュニティのリポジトリから入手できます。また、リンターや静的コード解析ツールなど、標準の JavaScript ツールも使用できます。

スクリプト

プリケーションは Visual Studio Code でローカルに開発しますが、実行するのはサーバー上です。JavaScript インタープリタがアプリケーションサーバーで実行され、JavaScript の各クラスやメソッドを処理します。JavaScript インタープリタにとって、スクリプトコールのソースは関係ありません。これにより、使用できるツールの選択肢が広がります。

B2C Commerce は、B2C Commerce Script API と Open Commerce API (OCAPI) を使用する本格的なアプリケーションプログラムインターフェース (API) をいくつか備えています。OCAPI は RESTful API で、HTTP 要求を受け取って応答を返します。要求をどのように構築し、応答をどのように使用するかはデベロッパーが自在に決めることができます。

B2C Commerce API は、ストアフロントのユーザー体験のすべてを構築するために使用します。OCAPI は、サードパーティのシステムを統合したり、Commerce Cloud が提供する体験の先を行くカスタマージャーニーにつなげたりするために使用します。

LINK パートナー

サードパーティのソフトウェアプロバイダーが Salesforce B2C Commerce LINK テクノロジーパートナープログラムに参加して、各自のカートリッジが B2C Commerce の最新テクノロジーに適合することを保証しています。LINK カートリッジを使用すれば、現在使用可能なものの中でも極めて画期的な e コマーステクノロジーを実装できます。

これらのカートリッジはすぐに使える状態のため、実装時間が大幅に短縮されます。

B2C Commerce の主な 3 つのソフトウェア開発ツールはどれですか?
Business Manager、Microsoft Visual Studio Code、Commerce Cloud ストアフロントリファレンスアーキテクチャ (SFRA)

Commerce Cloud ストアフロントリファレンスアーキテクチャの説明

SFRA とは
オンラインストアフロントのサイトがどのように見えるか確認する場合、構築しながら表示でき、コードベースとして使用できるに越したことはありません。ここでは、SFRA を使用してまさにこのとおりのことを行います。ただし、このアーキテクチャはコードベースであるだけでなく、サイトの設計図にもなります。
モバイルファーストデザイン
レスポンシブデザインとアダプティブデザイン
モバイルファーストでは最小の画面から設計し、拡大していきます。レスポンシブデザインとアダプティブデザインのどちらを作成する場合でも、最適な戦略の 1 つとなるのがモバイルファーストです。

Commerce Cloud ストアフロントリファレンスアーキテクチャ (SFRA) は JavaScript コントローラーを使用します。B2C Commerce で、コントローラーは、ストアフロントの要求を処理するサーバー側のスクリプトです。アプリケーションの制御フローを管理し、ストアフロントの各要求を処理して適切な応答を生成するモデルやビューのインスタンスを作成します。たとえば、買い物客がカテゴリメニュー項目をクリックしたり検索用語を入力したりすると、ページを表示するコントローラーがトリガされます。

コントローラーは JavaScript と B2C Commerce スクリプトに記述されます。コントローラー CommonJS モジュール標準に適合している必要があります。

SFRA を使用すると、B2C Commerce が配信したコード、マーチャントのカスタマイズ、サードパーティのインテグレーションコードを個別のカートリッジに簡単に分割でき、各カートリッジのコンテンツを管理や更新しやすくなります。

B2C Commerce では、カートリッジにコードやデータが格納されます。つまり、デベロッパーがたとえばほしい物リスト、Apple Pay、支払インテグレーションといった機能などの新しいコンポーネントを構築して、それぞれ個別にストアフロントにプラグインできることを意味します。このアーキテクチャでは、軽量で比較的明快なコードベースを使用して、継続的、反復的、漸進的なサイト設計が可能になります。コアコードは編集できませんが、デベロッパーがコード上に機能を自在に開発できます。

SFRA は一般的なブートストラップフロントエンドコンポーネントの UI ライブラリを使用します。ブートストラップとは、HTML、CSS、JS を使用した開発に使用するオープンソースのツールキットです。Sass 変数や Mixin、レスポンシブグリッドシステム、豊富な組み込みコンポーネント、jQuery 上に構築された強力なプラグインを使用して、アイデアのプロトタイプを作成したり、アプリケーション全体を構築したりすることができます。

保守、改善作業を正しい方向に進められるように、SFRA には注釈付きのワイヤフレームが用意されています。

B2C Commerce ビジネスオブジェクト

システムオブジェクト

B2C Commerce には、Appeasement から TrackingRef まで 63 種のシステムオブジェクトが用意されています。Business Manager(通常のSFのオブジェクトマネージャーと同じかな？) の各自のバージョンでは、参照のみとマークされているものもあります。新しいシステムオブジェクトを作成して B2C Commerce の内部システムをカスタマイズすることはできませんが、ビジネスニーズに応じてカスタムシステムオブジェクトを新規作成することは可能です。この違いは重要です! システムオブジェクト種別によって、システムオブジェクトに含まれる属性が定義されます。つまり、地図のような役割を果たします。

Commerce Cloud ストアフロントリファレンスアーキテクチャ (SFRA) では、システムオブジェクトを使用してそのサイトの各部を説明します。SFRA は、システムオブジェクトと対話するよう開発され、カスタムコードが不要なため、ストアフロントアプリケーション開発の出発点として利用できます。

実装で使用可能なシステムオブジェクトを最大限に活用するためには、こうしたオブジェクトについて理解しておく必要があります。ストアフロントアプリケーションを設定、管理、開発する B2C Commerce オンラインツールである Business Manager では、次のことができます。

カスタムオブジェクト

カスタムオブジェクトは、ビジネスニーズに合わせて B2C Commerce モデルを拡張する場合に使用できます。Business Manager では、最初にカスタムオブジェクトタイプを作成し、そのオブジェクトに含まれる属性を定義します。次に、これらの属性に基づいてカスタムオブジェクトを作成します。

カスタムオブジェクトタイプは、組織に定義されたストアフロントの全サイトで使用できます。ただし、カスタムオブジェクトの作成時に、サイト固有か組織全体かを選択できます。組織については、このモジュールの「Business Manager」の単元で説明しました。

カスタムオブジェクトタイプ

B2C Commerce モデルを拡張するには、ストアフロントまたはビジネスロジックに必要な追加のビジネスオブジェクトに、カスタムオブジェクトタイプを作成して管理します。たとえば、Sample というカスタムオブジェクトタイプを作成し、SKU と Date という属性を指定します。Business Manager の [カスタムオブジェクトの管理] で、SKU と Date の対に次のデータを入力して、データを作成します。

ベストプラクティス
可能な限り、カスタムオブジェクトではなく、システムオブジェクトを使用して、最新のリファレンスアーキテクチャに簡単にアップグレードできるようにし、不要なカスタマイズを排除します。

可能な限り、カスタム属性ではなく、システム属性を使用します。

B2C Commerce サイトの設定入門

サイトが作成、あるいはプロビジョニングされると、「レルム」に構造化されます。レルムにはプライマリインスタンスグループ (PIG) とセカンダリインスタンスグループ (SIG) の 2 つのグループがあります。レルムはマーチャントごとに異なります。どちらのグループにも、e コマースのサイトの設定に使用できるツールがあります。

レルム
マーチャントには通常、自社専用のレルムが 1 つあります。レルムには、ストアフロントアプリケーションを開発、テスト、リリースするインスタンスが含まれます。

通常マーチャントは、1 つのレルムにつき 9 つのインスタンスを受け取ります。具体的には、PIG のステージング、テスト、導入用の 3 つのインスタンスと、SIG のコード開発用の 5 つの Sandbox インスタンスと、1 つのデモ用インスタンスです。拡張が必要な場合は、1 つのレルムあたり最大 47 の Sandbox を設定できます。
レルムには PIG と SIG がそれぞれ 1 つのみ存在します。

1 つのレルムと複数のレルムの設定

一般に、マーチャントは 1 つのレルムを所有し、そこでブランディングや地域情報の異なる複数のサイトを開発してステージングしてからリリースします。ストアフロントサイトを管理する人々が、同じ場所にいる必要はありません。複数のサイトで、商品カタログを共有することも、異なるカタログを設定することもできます。場合によっては、サイト間で一定の管理設定を共有することもあります。

複数の事業部門やグローバルチームがあり、それぞれプロセスやビジネスポリシーが異なるマーチャントの多くは、複数のレルムを使用しています。マーチャントに個々の組織があり、バックエンド統合、スケジュール、その他の懸念事項がそれぞれ異なり、独自に管理したほうがよい場合も、個別のレルムが役立ちます。

同じレルム内のサイトは、商品データに同じ商品カタログを共有できますが、異なるレルムのサイトがカタログ構造の枠を超えてデータを共有することはできません。ただし、データを異なるレルムにインポートして共有することは可能です。

サイトと組織

Business Manager では、各インスタンス内に 1 つ以上のサイトを設定できます。特定のインスタンスに複数のサイトがある場合は組織とみなされます。たとえば、設定を行う場合に、サイト固有 (1 つのサイト) または全サイト共通 (組織) として設定できます。

データのインポートとエクスポートについて

インポートでは、外部ファイルからのデータを使用して B2C Commerce データベースに入力します。
エクスポートでは、B2C Commerce データベースからデータを抽出し、外部システムへのフィードとして使用可能な XML ファイルを作成できます。
フィードとは、特定のインポートあるいはエクスポートプロセスです。

データは本番からエクスポートされます。

以下は、ストアフロントデータのインポート/エクスポートプロセスではありません。

データのレプリケーションは、コードとデータをあるインスタンスから別のインスタンスにコピーすることです。データのレプリケーションについては次の単元で説明します。
Business Manager のカタログフィード機能は、サードパーティ (Certona など) のファイルを処理します。
サイトのインポート/エクスポートは、サイト固有の設定などの情報をあるインスタンスから別のインスタンスに移動することです。

スキーマ

B2C Commerce は XML 形式でエクスポートしますが、クーポンコードは例外で CSV 形式にエクスポートされます。.csv ファイルは、サードパーティのプログラムを使用して必須の XML 形式に処理することをお勧めします。処理に大量のメモリが割り当てられている純正の .NET または Java プラットフォームを使用してファイルを変換するほうがはるかに高速で効率的です。

本番フィード

本番フィードには、以前のフィードからの変更のみを含めることをお勧めします。これをデルタフィードといいます。デルタフィードのほうがアーカイブの量が少なく、インポートが迅速で、トラブルシューティングが簡単です。ただし、スキーマの中には、グローバルインポートモードを上書きし、常に置換モードを使用する要素のあるものがあります。これらの要素は、各インポートにオブジェクトのフルセットを含める必要があるため、デルタフィードに含めることができません。

B2C Commerce のレプリケーション

レプリケーションは、データとコードをステージングインスタンスから開発または本番インスタンスに転送する Salesforce B2C Commerce のプロセスで、管理された方法で行い、エラーのリスクを最小限に抑えます。レプリケーションはプライマリインスタンスグループ (PIG) のインスタンスのみで行われ、セカンダリインスタンスグループ (SIG) や Sandbox では行われません。

レプリケーションの管理

最初に、サイトを構成して管理するための B2C Commerce ツールである Business Manager で、レプリケーションプロセスを作成します。レプリケーションプロセスとは、前回のレプリケーション以降に行われた変更を特定するレプリケーションタスクの集合体です。データ (商品データ、コンテンツ、画像ファイルなど) の変更であることもあれば、コードの変更である場合もあります。

トラフィックの少ない時間帯に開始日と終了日をスケジュールし、サイトのパフォーマンスや、買い物客の体験に悪影響を及ぼさないようにします。

2 段階の公開

転送: 新しいレプリケーションを作成してサイト向けに設定したら、レプリケーションタイプ別に [Transfer (転送)] を選択します。転送に失敗した場合は、何が問題であったのかを解明します。問題を修正してから、もう一度実行します。
公開: データを公開するために、データ公開という 2 つ目のタスクを作成します。データのレプリケーションでは、転送タスクと公開タスクのデータが一致している必要があります。たとえば、カタログ、インデックス、プロモーションデータを転送してから、カタログデータのみを公開することはできません。

コードのレプリケーション

Sandbox で開発を終えたら、コードをステージングにアップロードします。サーバー接続はセキュアでなければなりません。

本番インスタンスで、新しいバージョンが自動的に作成され、元のバージョン名にタイムスタンプを組み合わせた名前が付けられます。コードをアクティブにしないまま本番にコピーすることや、アクティブ化の途中でコピーすることもできます。以前のコードのバージョンに戻す必要がある場合、B2C Commerce が以前のアクティブなバージョンを検出して再びアクティブにします。

本番インスタンスでは次の操作を実行することをお勧めします。

コードのバージョンをステージングにリリースします。
コード (とデータ) を開発環境にレプリケートして、プロセスをテストします。
コードを本番環境にレプリケートします。