Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

B2C Commerce のレプリケーションについて

学習の目的

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

  • インスタンス間のプロセスフローを説明する。
  • レプリケートされる 3 種類のデータを挙げる。
  • インポート/エクスポートプロセスとレプリケーションプロセスの違いを 2 つ挙げる。
  • レプリケーションを管理する 2 つの方法について説明する。
  • レプリケーションタスクの利点を説明する。

概要

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

ステージングから本番と開発へのレプリケート

レプリケート元とレプリケート先

レプリケーション時に、変更がレプリケート元からレプリケート先に転送されます。レプリケート元は常にステージングインスタンスですが、レプリケート先は開発インスタンスのこともあれば、本番インスタンスのこともあります。レプリケーションの主な目的は、ステージングの変更を本番に転送することですが、予備のステップで同じ変更を開発にも転送します。このステップにより、レプリケーションが正常に完了したことをデベロッパーが確認できます。

レプリケーションの管理

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

複数のレプリケーションプロセスを定義して、各プロセスに含めるレプリケーションタスクを指定できます。こうすれば、毎回転送される粒度を管理することができます。サイト全体を転送することも、選択したサブセットを転送することも可能です。たとえば、サイトのカスタムオブジェクトのみを転送する場合などです。組織レベルの変更も同様に柔軟に対応できます。

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

2 段階の公開

データは 2 段階の公開方法でレプリケートできます。この方法では、プロセス全体を実行して失敗するといった事態を回避できます。このプロセスは、レプリケーションプロセスや転送プロセスを開始したばかりの場合や、結果に対する管理を強める必要がある場合に役立ちます。

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

データ複製

データのレプリケーションはストアフロントの最新バージョンを本番に転送することを目的とするもので、置換操作であり、マージではありません。データのレプリケーションではまず、レプリケート元インスタンスのデータのコピーをレプリケート先インスタンスの新しい場所に作成します。元のデータは置換しません。このプロセスが完了したら、既存のデータからレプリケート先システムの新しいデータに切り替えて、効率的にデータを置換します。切り替えは瞬時にシームレスに行われます。

データを初めてレプリケートするときは、すべてのデータが対象です。後続のレプリケーションでは、粒度を指定できます。たとえば、個々のサイトとそのサイトに関連付けられているカタログ (全カタログ、1 つのカタログ、商品カタログ) をレプリケートできます。

レプリケートするデータの選択

B2C Commerce のデータには、組織範囲かサイト範囲を設定できます。組織レベルでは、データが全サイトに共有されます。サイトレベルでは、データが個々のサイトのみで使用されます。それぞれの範囲内で、レプリケーション対象のさまざまなデータセットを選択できます。たとえば、組織のすべてのカタログや、特定のストアフロントのプロモーションやクーポンなどを選べます。これは、データのレプリケーションでサポートされている最低レベルの粒度です。この機能は、一部のデータはレプリケート可能な状態である一方で、まだ準備できていないデータもある場合に役立ちます。たとえば、コンテンツの新しいアセットは本番にレプリケートできる状態であっても、新しいカタログ定義はまだできていないような場合です。

いくつか制限事項があります。レプリケートするデータセット内から、カタログまたはプロモーションの 1 つの商品を選択することはできません。データのレプリケーションで次のものはステージングからコピーされません。

  • Orders (注文)
  • 在庫リスト
  • Business Manager ユーザープロフィールおよびログイン情報

データのレプリケーションのスケジュール

レプリケーションプロセスは 4 通りの方法でスケジュールできます。

  • 自動: デフォルトでは指定した日時に、あるいはレプリケーションプロセスを定義した直後にレプリケーションが実行されます。
  • 手動: 適切な許可のあるユーザーが Business Manager でレプリケーションをいつでも開始できます。
  • 繰り返し: 毎日、毎週、毎月のスケジュールに従ってレプリケーションが実行されます。
  • ジョブステップ: ジョブによってトリガーされた時点でレプリケーションが実行されます。

レプリケートするときには注意が必要です。データのレプリケーションの繰り返しに失敗すると、それ以降ジョブの繰り返しが実行されません。レプリケーションによって通常は、ページキャッシュがクリアされ、ストアフロントのパフォーマンスに大きな影響を及ぼすことがあります。

ベストプラクティス

以下に、データのレプリケーションのベストプラクティスをいくつか示します。

  • 最初にステージングから開発へのレプリケーションプロセスをテストします。
  • 開発環境でレプリケートされた設定をテストして、期待どおりに機能することを確認します。
  • 必ず転送を実行してから公開し、転送プロセスを確認できるようにします。
  • 異なるデータレプリケーショングループ間の連動関係を特定する。
  • カタログの検索インデックスも必ずレプリケートします。
  • 本番ステップへの転送は、ストアフロントの活動が最小限のときに実行します。
  • データのレプリケーション中は、増分インデックスやスケジュール済みインデックス化を無効にし、他のジョブも停止します。転送のために増分インデックスを無効にする必要はありませんが、公開する前に無効にする必要があります。検索インデックスはレプリケートするか、レプリケート先インスタンスに手動で構築することができます。
  • B2C Commerce の定期メンテナンス時間中に大量のデータのレプリケーションを行わないようにします。
  • Business Manager の許可を使用して、データのレプリケーションを実行できるユーザーを制限します。

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

Business Manager のコードのレプリケーションでは、レプリケート元インスタンスとレプリケート先インスタンス間でコードのバージョンをレプリケートします。コードのバージョンは、カスタムカートリッジを格納するフォルダーです。インスタンスは複数のコードのバージョンを保持できますが、アクティブなバージョンのみを使用します。

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

デベロッパーマシンからコードを Sandbox またはステージングインスタンスにアップロードします。

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

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

レプリケーションタイプ

レプリケート先システムを設定して、手動、自動、ジョブステップによる開始のコードのレプリケーションプロセスを作成します。レプリケーションには次の種類があります。

レプリケーションタイプ

説明

コードの転送

レプリケート元システムで現在有効なコードのバージョンが、レプリケート先システムに転送されます。

バージョン内のすべてのファイルの名前がすでにインストールされているバージョンと一致していても、レプリケーションのたびにレプリケート先システムで新しいコードのバージョンが作成されます。データのレプリケーションとは異なり、同期は行われません。同期によって、レプリケート先の既存のバージョンや、アクティブなバージョンにも影響する可能性があるためです。

コードの転送と公開

コードの転送は、新しいバージョンが即座に有効化された後に実行されます。

コード公開

転送はありません。以前に転送されたバージョンが有効になります。このモードを使用できるのは、以前のレプリケーションの種類がコードの転送の場合のみです。

2 つのシステムのバージョン名が変わる可能性があるため、常に正しい処理が行われるようにロジックを追加します。このバージョンがすでに存在しない場合は、公開に失敗します。すでに有効になっている場合は何も起こりません。

コードを元に戻す

この操作は (データ転送のない) コード公開に似ていますが、以前有効だったバージョンにロールバックします。

この前のプロセスがコードの転送と公開またはコード公開のいずれかである必要があります。元に戻すバージョンがすでにアクティブでない場合は何も起こりません。バージョンがすでに存在しない場合や、ロールバックするバージョンが存在しない場合は、プロセスに失敗します。

E メールによる通知

受信者のカンマ区切りリストを使用して、コードのレプリケーションの E メールによる通知を設定できます。プロセスの終了または失敗後にメールが送信されます。プロセスの応答が途絶えた場合は、メール送信されません。

レプリケーショングループ

レプリケーショングループ (またはタスク) を使用すると、データやプロセスを管理しやすい方法で整理できます。また、データをサイトレベル、組織レベル、あるいはその両方でレプリケートできます。たとえば、カスタムオブジェクトを組織レベルとサイトレベルの両方でレプリケートすることができます。

Business Manager では、まとめてレプリケートされた複数のオブジェクトをグループ化します。オブジェクト間の関係を確認する時間を取り、オブジェクトの複雑さを理解します。

データ/コードのレプリケーションとインポート/エクスポート

インポート/エクスポートとデータのレプリケーションのどちらも、インスタンスデータベースへの入力に使用します。

  • レプリケーションでは、コード/データが B2C Commerce システムにすでに存在する場合に、そのコード/データがあるインスタンスから別のインスタンスに移動される。
  • インポートとエクスポートでは、外部システムと B2C Commerce のデータベース間でデータが移動される。

次のステップ

このモジュールでは、B2C Commerce アーキテクチャについてたくさんのことを学びました。サイトや組織を PIG と SIG に構造化する方法、インポートとエクスポートの意味合い、レプリケーションプロセスでコードとデータをあるインスタンスから別のインスタンスに移動する方法を見てきました。いよいよ光り輝く新しいバッジを獲得するときです。

リソース

Salesforce ヘルプ: B2C Commerce のレプリケーション

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

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

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