Skip to main content
Build the future with Agentforce at TDX in San Francisco or on Salesforce+ on March 5–6. Register now.

B2C Commerce リファレンスアーキテクチャのカスタマイズ

学習の目的

この単元を完了すると、次のことができるようになります。

  • アプリケーションのカスタマイズが期待される理由を説明する。
  • 2 つの SFRA カスタマイズを挙げる。
  • 2 つの SFRA デコレーターテンプレートの違いを説明する。
  • コントローラーの拡張や上書きが機能やパフォーマンスにどのように影響するかを説明する。
  • SiteGenesis に対する SFRA の利点を 2 つ挙げる。

はじめに

あなたは、ファンクショナルアーキテクトとして、Salesforce B2C Commerce ストアフロントソリューションの戦略策定、設計、文書化という大変な作業を遂行してきました。次は、そのソリューションを適用する必要があります。そして、それにも計画が必要です。

次のことを自問します。

  • コードの基盤としてリファレンスアーキテクチャを使用できるか? できるとすると、カスタマイズをどのように行うか?
  • サードパーティアプリケーションをどのように統合するか?
  • 実装のベストプラクティスは何か? それによって、使用する手法がどのように変更されるか?
  • 稼働開始に向けた準備状況をどのように評価するか?

この単元では、マーチャントの要件を満たすためのリファレンスアーキテクチャのカスタマイズについて説明します。その他のトピックについては、後で説明します。

カスタマイズする理由

B2C Commerce には、優れた標準機能があり、高い汎用性があります。ただし、標準機能がマーチャントの要件をすべて満たすとは限りません。これは弱みではなく、B2C Commerce を使用するマーチャントの規模と範囲が大きく関わっています。実際、B2C Commerce ストアフロントの作成は複雑であるため、個々のマーチャントの要件を満たすには、標準機能に加えて、完全にカスタマイズと拡張が可能なプラットフォームを提供することが求められます。

それらの要件は、マーチャントの専門業種、地域、戦略、規模に応じて大きく異なります。たとえば、書籍販売業者とスポーツ用品リテーラーの要件は異なります。買い物客が靴をカスタマイズできるオンライン店舗を想像してください。または、顧客が自分の顔の写真を撮って、そこに化粧を施せる化粧品リテーラーを想像してください。複数の国で何百万枚もの T シャツを販売するリテーラーもあれば、1 か所のブティックで、オリジナルの革製ハンドバッグを販売しているリテーラーもあります。

複数の国で販売されている同じグレーの T シャツ。

カスタマイズ

B2C Commerce には、リファレンスアーキテクチャを使用したスターターコードが組み込まれています。リファレンスアーキテクチャには、SiteGenesis とストアフロントリファレンスアーキテクチャ (SFRA) の 2 種類があります。SFRA については、「Salesforce B2C Commerce (デベロッパー向け)」 Trailhead モジュールで学習しました。

SiteGenesis は、現在 2,700 以上の B2C Commerce サイトで使用されており、世界をリードするいくつかのブランドによって実証済みの基盤です。SiteGenesis には、標準ストアフロント機能に加えて、レスポンシブデザインなどの多くの優れた機能があります。ただし、アプリケーションの要件に合うように SiteGenesis をカスタマイズすると、SiteGenesis の機能強化のたびにアプリケーションを更新する必要があります。

幅広い調査を経て開発された SFRA は、サイト設計、マーチャンダイジング、技術的アーキテクチャのベストプラクティスを組み合わせた標準搭載のフレームワークで、マーチャントがモバイル優先のストアフロントを作成するために役立ちます。SiteGenesis と同様、SFRA も完全に機能するショッピング買い物カゴ、注文手続き、ホームページ、PDP ページなどを備えています。さらに SFRA は、合理化されたモバイル注文手続きフローやタッチ対応アイコンなどのモバイル向けに最適化されたユーザー体験を備えています。

ストアフロントアプリケーションに SiteGenesis を使用することを計画している場合は、慎重に検討してください。SiteGenesis は多くのサイトで使用されていますが、SFRA によって提供される機能を検討することをお勧めします。

SFRA のカスタマイズ

SFRA ランディングページ

SFRA には app_storefront_base カートリッジとサーバーモジュールが付属しています。ベースカートリッジには、ほとんどのサイトに共通する機能が含まれています。その上に、プラグインカートリッジ、LINK カートリッジ、カスタムコードカートリッジによって階層的に機能を追加することができます。B2C Commerce には、ほしい物リスト、ギフト登録、Apple Pay、商品比較のプラグインカートリッジと、ミドルウェア機能があります。PayPal や Bazaarvoice などの LINK パートナーからは LINK カートリッジが提供されています。そのため、さまざまな種類のアプリケーションを選択できます。

ベースカートリッジとモジュールは、カスタマイズするものではないことを覚えておいてください。つまり、app_storefront_base カートリッジやその他のプラグイン (plugin_applepay など) の編集または名前変更は行いません。また、app_storefront_base カートリッジやその他のプラグインのバージョンを最新に保って、すべての変更を取得する必要があります。

これは制限ではなく、仕様です。

共通の基盤があることで、コードを記述し直すことなく、セキュリティ更新、バグ修正、新機能を簡単に取得できます。SFRA は、ポイントリリース間に後方互換性があるため (緊急のセキュリティ修正で必要な場合を除く)、新しいバージョンをダウンロードして、自動テストを実行するだけです。コードの変更内容を探して、カスタマイズしたコードにそれを移植する必要はありません。

詳しい説明

各サイトには、少なくとも 1 つのカスタムカートリッジが必要です。複数のサイトを作成する場合は、複数のカスタムカートリッジを作成して、ブランドや地域に固有の機能を分けることをお勧めします。そうすることで、新しいサイトやマイクロサイトに、カートリッジスタックの大部分を再利用できます。

メモ

カートリッジスタックは、Business Manager でカートリッジをリストする方法です (読み込み順序を指示します)。サイトがライブになると、各カートリッジは以前のカートリッジの上に重ねられて、アプリケーションが作成されます。

それらのカスタムカートリッジ内のいくつかのコンポーネントについて説明しましょう。これは、チームのより技術的なメンバーに対応するときに役立ちます。

コンポーネント

フック

フックを使用すると、アプリケーションフローの特定の時間にコールされる機能や、特定のイベント用の機能を設定できます。つまり、B2C Commerce スクリプトの System パッケージの HookMgr クラスメソッドを介して OCAPI フックまたはカスタムフックを使用するということです。

アプリケーションはそれらを使用して、たとえば買い物カゴの計算や検証、または支払プロセッサーの起動などを行うことができます。

モジュール

モジュールは、複数のリソースで共有される機能のコードをグループ化するための業界標準の方法です。モジュールを使用することで、簡単にストアフロント機能を追加し、該当する場合にいつでも再利用することができます。

SFRA は、Modules 1.1.1 CommonJS 仕様に準拠する JavaScript/B2C Commerce スクリプトモジュールをサポートします。CommonJS モジュールの機能は、複数のコントローラーで再利用できます。モジュールの .ds ファイルまたは .js ファイルは、通常、script フォルダーのカートリッジ、またはカートリッジと同じレベルの modules フォルダーに保存されます。アプリケーションは、そのカートリッジ、他のカートリッジ、modules フォルダー内のモジュールにアクセスできます。

テンプレート

テンプレート (SiteGenesis と同じ) は、ストアフロントに情報がどのように表示されるかを決定します。SFRA には 2 つのデコレーターテンプレートが含まれています。

  • page.isml — ナビゲーション情報が含まれます。
  • checkout.isml — ナビゲーション情報は含まれません。ナビゲーション情報を削除すると、たとえば、一般に買い物カゴ放棄率が改善されます。買い物客が、簡単にはそのページを離れにくくなります。
モデル

SFRA モデルは、アプリケーションの JSON オブジェクトレイヤーを提供します。モデルは、B2C Commerce スクリプト API が返したオブジェクトをストアフロント用に設計された純粋な JSON オブジェクトに変換します。さらにモデルは、ストアフロントにビジネスロジックを適用することも行います。

コントローラーはモデルの作成と更新を行います。モデルをカスタマイズするには、モデルを作成してから、表示に使用できるデータをモデルに追加します。

コントローラーとルート

ミドルウェアを使用すると、コントローラーが起動される前後にコードを実行できます。ルートを使用すると、アプリケーションが実行されるたびに起動される PSR-7 互換のコーラブルをスタックに追加できます。

コントローラーを拡張しているか上書きしているかは、機能とパフォーマンスに影響します。コントローラーを拡張すると、アプリケーションは元のミドルウェアを実行してから拡張機能を実行します。元のミドルウェアにサードパーティとのインタラクションが含まれている場合は、そのインタラクションも実行されます。拡張機能にもそのインタラクションが含まれる場合、インタラクションは 2 回実行されます。

フォーム

テンプレートとコントローラーを使用して HTML フォームを作成します。フォーム定義を使用すると、セッション中にフォームデータを保持し、システムオブジェクトまたはカスタムオブジェクトにそれを保存できます。

SiteGenesis のカスタマイズ

SiteGenesis は、何年もの間、定番の Commerce Cloud リファレンスアーキテクチャであったため、この領域には、豊富なカスタマイズ環境があります。

SiteGenesis ランディングページ

典型的な SiteGenesis のカスタマイズをいくつか挙げます。

  • カテゴリの絞り込みの表示カテゴリのみを制御する別個の属性を新しく作成する。これは、上部のナビゲーションと絞り込みにカテゴリを表示する既存の属性とは別です。
  • 買い物カゴをデフォルトの配送方法に自動的に設定する。注文手続きの配送ページではなく、買い物カゴレベルで送料 (と配送プロモーション) を表示します。
  • 商品情報ページに、セールバリアントと正規価格バリアントの両方を表示する。商品情報ページの別個の 2 か所に色を配置することによって、割引後の SKU と正規価格の SKU を視覚的に区別します。
  • カスタムサイト設定またはコンテンツスロットオブジェクトのカスタム属性を使用して、ホームページカルーセルの回転速度を制御する。

次のステップ

カスタマイズを制限するのは、リソース、時間、想像力だけです。2 つの Commerce Cloud リファレンスアーキテクチャを使用したストアフロントのカスタマイズの基本を理解できたので、サードパーティアプリケーションの統合に進みましょう。

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む