製品カタログデータ
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
Commerce Connectソリューションにおける製品カタログデータの保存・取得には、製品同期、データプロバイダー、インデックスハイブリッドモデルの3つの一般的なモデルがあります。Commerce Connectのサービス層は互いに独立して動作するため、製品データの保存・取得にはどの方法でも使うことができ、残りのサービスレイヤーは統合や組み込みのエンゲージメント提供に活用できます。
Commerce Connect製品データモデル
Commerce Connectには、Sitecoreコンテンツに製品データを保存するサポートが組み込まれています。Commerce Connectには、製品データモデルと、1つ以上の外部システムと製品データを交換するための製品同期サービス層が含まれています。
外部商取引システムは製品データの保存方法が異なります。Commerce Connect製品データモデルは、使用される外部システムに関わらずスケーラブルな標準データモデルを提供するよう設計されています。
このモデルは非常にスケーラブルで、以下のような利点があります。
- 典型的なeコマースシナリオの堅実な基盤です。
- 冗長な製品データはありません。
- 同期が必要な商品データは最小限に抑えられます。
- eコマースベンダーが商品データをマッピングする簡単な方法です。
- 開発者が最小限の労力で外部商取引システムを置き換えられる標準的な構造と、製品管理のための既知の構造。
- アイテムバケットやContentSearchなどのSitecore XP機能の恩恵を受けています。
製品同期モデル
以下の状況では、製品同期モデルを使用し、製品をSitecoreコンテンツとして保存するのがベストプラクティスです。
- 例えば、外部のコマースシステムに保存されている商品データをプレゼンテーションデータやマーケティングコンテンツで補完したい場合、商品にマーケティング情報を追加することです。
- 複数のデータソースをサポートする ために、複数の異なるシステムからデータが収集されている場合に備えて。
- 外部システムからのデータ取得が遅い 場合、つまり1つ以上の外部システムからの製品カタログデータの取得が遅い場合。
商品にマーケティング情報を追加する
コマースシステムに保存される情報の種類には通常、制限があります。Commerce Connectの前提の一つは、外部コマースシステムにはコア製品データのみが含まれていることです。コアデータは、すべてのチャネルで共有される静的な製品情報です。コアデータは通常、見栄えが良い形で保存されません。マーケティングコンテンツなどの情報は、他の外部システムから提供されるか、Sitecoreに追加することができます。
また、Sitecoreはチャネルごとに異なる情報を扱うことができます。製品モデルはチャネルごとに異なるメッセージングに対応していませんが、これらの情報は製品テンプレート内の個別フィールドやチャネルサブフォルダ内のサブアイテムとして簡単に追加できます。Sitecoreは、すべてのサポートチャネルにおける顧客プレゼンテーションのための製品情報の集約者となります。異なるチャネルのプレゼンテーションや販売テキストは、レンダリング前にSitecoreで管理できます。
複数のデータソースをサポートするために
場合によっては、製品データが複数のソースから提供されることもあります。分類と分類は製品カタログのデータと訪問者への提示方法において重要な部分です。例えばERPシステムで使用される分類は通常カスタムされており、店舗プレゼンテーション側の分類に合うことは稀です。したがって、プレゼンテーション分類に必要なデータや仕様書は、外部システム外の分類システムに存在し、同期の一部として組み込むことができます。標準的な分類システムはUNSPSC®とCNET DataSource™です。
- ユニバーサル標準製品およびサービス分類(UNSPSC)は、特にインターネット上で企業間の商取引を効率化するために、業界で合意された命名基準に従って製品やサービスを明確にコーディングするために作られました。UNSPSCは、商品やサービスの分類に論理的な枠組みを提供するオープンでグローバルな電子商取引標準です。
- CNET Content SolutionsにはDataSourceという製品が含まれています。DataSourceは、複数のソースから非標準化された製品情報を電子製品カタログ用の一貫したコンテンツに変換します。また、外部カタログとCNET Content Solutions DataSource製品データベースを自動的にマッチングし、それらのカタログにDataSourceの仕様、製品属性、豊富なコンテンツを加えるカタログマッピングサービスでもあります。
データの取得先を決定するロジックは、製品同期層を構成するプロセッサとパイプラインに組み込まれなければなりません。同期プロセスは、データモデル内の個々のオブジェクトを個別に処理するように分割されます。各パイプラインはデータモデル内の単一のオブジェクトタイプで動作します。データの取得方法やデータオブジェクトの入力方法は、統合の実装次第です。別々のパイプラインプロセッサを実装し、各プロセッサがSitecoreとの同期が行われる前にオブジェクトの情報の一部を取得し、その情報をオブジェクトに入力する責任を負うようにすることも可能です。
外部システムからのデータ取得が遅い場合
すべての外部システムが同じようにパフォーマンスを発揮するわけではありません。ERPシステムは非常に遅いことで知られています。データプロバイダーでの遅延のもう一つの理由は、外部システムが別のサーバーインスタンスに存在し、遅延が大きい場合かもしれません。そのような場合、データプロバイダーとの連携はパフォーマンスに悪影響を及ぼす可能性があり、製品データをSitecoreのコンテンツでネイティブに提供するのが望ましいです。
分散システムのサポート
Content Management (CM)、Content Delivery (CD)、外部コマースシステムインスタンスが異なる地理的場所にあるか、同じネットワーク内の異なるサーバーインスタンス上にある場合、遅延が高くなる可能性があります。例えば、CMとCDはクラウド上にあり、外部コマースシステムは現場にある場合があります。このシナリオでは、リアルタイム通話やアイテムデータプロバイダーを使って外部コマースシステムからデータを取得することは不可能でも実用的でもないでしょう。
さらに、アイテムデータプロバイダーを使用することで、Sitecoreと外部システム間の接続問題が発生した場合にシステムが脆弱になります。一度データがSitecoreのコンテンツと同期されると、それは即座かつ常に利用可能となります。
Sitecore内の製品リポジトリを最新の状態に保つことは、リソースを消費しません
価格や在庫情報は動的であるため、コア製品データの一部として扱われず、必要に応じてこの情報を取得するための別のサービス層があります。これにより、Sitecoreの製品リポジトリには価格や在庫情報は含まれず、静的なデータのみが存在します。リポジトリに100万件の商品があっても、そのうち定期的に更新・追加・削除が必要なのはごく一部に過ぎません。
Sitecoreで製品データが同期された例として、nopCommerceと統合されたStarterKitソリューションが見ることができます。このソリューションはGitHubにあります。
データプロバイダーモデル
製品同期を使ってCommerce Connectとの統合を構築するのは大きな作業です。しかし、十分なパフォーマンスを発揮できるSitecoreデータプロバイダーの作成とサポートも同様に大きな作業です。
データプロバイダーの実装は、外部のコマースシステムにおける製品データの構造に依存します。データプロバイダーを使用するコマースシステムはuCommerceとSitecore Commerceの2つです。これらのシステムには、製品データが商品を含むネストされたカテゴリで構造化されているという共通点があります。これらのシステムの違いの一つは、製品アイテムが異なるフィールドを含む点です。 GitHubでSitecore CommerceとReference Storefrontを用いた例のソリューションを見つけることができます。
インデックスハイブリッドモデル
ハイブリッドソリューションとしては、外部システムまたはSitecoreコンテンツに保存された製品データに基づいてSitecore製品インデックスを作成する方法があります。例えば、Sitecore Commerceはインデックスをカタログ閲覧体験を推進する主要な手段として使用しています。製品詳細がレンダリングされると、データプロバイダーを使って外部カタログからリアルタイムで読み込まれます。インデックスはSitecoreコンテンツに保存されたカタログデータをクロールすることで作成されます。
インデックスを照会する際、返還されたオブジェクトの一部としてConnectのプロダクトオブジェクトモデルを使用できます。Sitecore Content Searchの実装により、結果を返す前にインデックスのデータでオブジェクトを埋めることができます。インデックスに保存されていない情報は、インデックスから取得したProduct IDを参照として外部コマースシステムからデータを読み込むために外部システムから取得できます。
Sitecoreが返されたオブジェクトを自動的に埋め込むためには、インデックスフィールド名がオブジェクトのプロパティと一致するか、属性を使って設定する必要があります。
データ保存モデルと検索モデルの比較
データプロバイダーソリューションが最も適しているように思えるかもしれません。なぜなら、製品データは通常外部のコマースシステムに所有されており、自然にそこに属するからです。しかし、製品データをSitecoreやインデックスに保存する理由はいくつかあります。
以下の表は、3つのデータ保存および検索モデルの違いを示しています。
製品同期
データプロバイダー
インデックスハイブリッド
書き換え/更新可能
カタログデータは更新可能です
はい
データが同期されると、コンテンツをSitecoreで更新できます。
外部システムやデータ提供者によります。
例
Serverの更新可能Microsoft Dynamics AX for Retailは更新できませんいいえ
指数は静的です。
データの拡張が可能です
はい
追加のフィールドや項目をモデルに追加することができます。
外部システムやデータプロバイダーの実装によります。
いいえ
追加のコンテンツはSitecoreで別途管理する必要があります。
複数のソースへのサポート
はい
複数のシステムからデータを取得するためのプロセッサを同期パイプラインに注入することができます。
可能性はあります
通常、情報源は一つだけです。
可能性はあります
通常、情報源は一つだけです。
カタログデータへのアクセス遅延
全くありません
Sitecoreの速度次第です。
外部システムの統合度や近接性によります。
統合検索エンジンによります。
カタログデータの公開と維持に必要な時間と資源
はい
定期的な製品同期が必要です。
いいえ
はい
定期的な再インデックス作成が必要です。
典型的なeコマースシナリオの堅実な基盤
はい
店舗のシナリオを念頭に置いて設計されています。
仮想構造やデータ提供者が公開するデータによります。
インデックスの内容やその完全度、あるいは必要な情報を得るために外部システムに頻繁に呼び出す必要があるかによります。
冗長な製品データを避けることができます
はい
いいえ
Sitecoreコンテンツからカタログデータをインデックス化する際に、以下の点が課題となります。
通常、製品のデータは単一のSitecore項目として公開されるため、複数の製品が同じ値を持つと、そのデータは複数回表示されます。
製品は複数の異なるカテゴリやカタログに属するため、コンテンツツリー構造内の複数の異なる場所に現れます。
いいえ
商品のデータはすべてのインデックスドキュメントに保存されているため、複数の商品が同じ値を持つと、そのデータは何度も表示されます。
商品は複数のカテゴリーやカタログに属するため、インデックス内の複数の場所に現れます。
eコマースベンダーが商品データをマッピングする簡単な方法
はい
外部システムのデータの構造や、Sitecoreで木構造としてどのように公開する必要があるかによります。
外部システムのデータの構造や、どのようにフラットインデックス構造にマッピングする必要があるかによります。
開発者が最小限の労力で外部商取引システムを置き換えられる標準構造と、製品管理のための既知の構造
はい
いいえ
各データプロバイダーはカタログデータの異なる仮想構造を公開します。
はい
クローラーとインデクサを作成すれば、インデックスが同じフィールドとデータを保持できます。