製品カタログデータ

Version:
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

Commerce Connectソリューションで製品カタログ データを格納および取得する方法には、製品同期、データ プロバイダー、インデックス ハイブリッド モデルの3つの一般的なモデルがあります。Commerce Connectサービス レイヤーは互いに独立して動作するため、製品データの保存と取得に任意の方法を使用し、残りのサービス レイヤーを統合や組み込みのエンゲージメントの提供に使用できます。

Commerce Connect製品データ モデル

Commerce Connectには、Sitecoreコンテンツに商品データを保存するためのサポートが組み込まれています。Commerce Connectには、商品データを1つ以上の外部システムと交換するための商品データ モデルと商品同期サービス レイヤーが含まれています。

外部のコマース システムは、さまざまな方法で商品データを保存します。Commerce Connect製品データ モデルは、使用される外部システムに関係なく、スケーラブルな標準データ モデルを提供するように設計されています。

このモデルは拡張性が高く、次の利点があります。

  • 一般的なeコマースシナリオの強固な基盤。

  • 冗長な製品データはありません。

  • 同期が必要な製品データは最小限です。

  • eコマースベンダーが製品データをマッピングする簡単な方法。

  • 開発者が最小限の労力で外部コマースシステムを置き換え、製品を管理するための既知の構造を実現できる標準構造。

  • アイテム バケットやContentSearchなどのSitecore XP機能を利用できます。

製品同期モデル

次の状況では、製品同期モデルを使用し、製品データをSitecoreコンテンツとして保存することをお勧めします。

  • To add marketing information to products - 外部コマースシステムに保存されている製品データを、プレゼンテーションデータやマーケティングコンテンツなどで拡張する場合。

  • To support multiple data sources – データが複数の異なるシステムから収集されている場合。

  • When retrieving data from the external system is slow – 1つ以上の外部システムからの製品カタログ データの取得が遅い場合。

製品にマーケティング情報を追加するには

通常、コマースシステムに保存される情報の種類には制限があります。Commerce Connectの前提の1つは、コア製品データのみが外部コマース システムに含まれていることです。コアデータは、すべてのチャネルで共有される静的な製品情報です。コアデータは通常、見栄えのする方法で保存されません。マーケティング コンテンツなどの情報は、他の外部システムから取得するか、Sitecoreに追加する必要があります。

また、Sitecoreはチャネルごとに異なる情報を処理できます。製品モデルは、チャネルごとに異なるメッセージングに対応していませんが、この情報は、製品テンプレート自体の個々のフィールドの形式で、またはチャネル サブフォルダのサブアイテムとして簡単に追加できます。Sitecoreは、サポートされているすべてのチャネルで顧客向けプレゼンテーションのための製品情報のアグリゲーターになります。さまざまなチャネルのプレゼンテーション テキストとセールス テキストは、レンダリング前にSitecoreで管理できます。

複数のデータソースをサポートするには

一部のシナリオでは、製品データは複数のソースから提供されます。分類と分類は、製品カタログ データの重要な部分であり、訪問者にどのように表示されるかです。たとえば、ERPシステムで使用される分類は、通常、カスタムメイドであり、ストアフロントのプレゼンテーション側で必要な分類に適合することはめったにありません。そのため、プレゼンテーションの分類に必要なデータと仕様は、外部システムの外部にある分類システムに存在し、同期の一部として組み込むことができます。2つの標準分類システムは、UNSPSC® とCNET DataSource™ です。

  • Universal Standard Products and Services Classification(UNSPSC)は、特にインターネット上での企業間の商取引を合理化するために、業界で合意された命名基準に従って製品とサービスを明確にコーディングするために作成されました。UNSPSCは、商品やサービスを分類するための論理的なフレームワークを提供する、オープンでグローバルな電子商取引標準です。

  • CNET Content solutionsには、DataSourceという製品が含まれています。データソースは、複数のソースからの標準化されていない製品情報を電子製品カタログの一貫したコンテンツに変換します。また、外部カタログをCNET Content Solutions DataSource製品データベースに自動的に一致させて、それらのカタログをDataSource仕様、製品属性、およびリッチコンテンツで強化するカタログマッピングサービスでもあります。

データの取得元を決定するロジックは、製品同期レイヤーを構成するプロセッサとパイプラインに組み込む必要があります。同期プロセスは、データモデルの個々のオブジェクトを個別に処理するように分割されます。各パイプラインは、データ モデル内の1つのオブジェクト タイプで動作します。データの取得方法とデータオブジェクトの入力方法は、統合の実装によって異なります。個別のパイプライン プロセッサを実装して、各プロセッサがオブジェクトの情報の一部を取得し、Sitecoreとの同期が行われる前にその情報をオブジェクトに入力する責任を持つようにすることができます。

外部システムからのデータ取得が遅い場合

すべての外部システムが同等に優れたパフォーマンスを発揮するわけではありません。ERPシステムは遅いことで有名です。データプロバイダーを使用してパフォーマンスが低下する別の理由は、外部システムが別のサーバーインスタンスに存在し、レイテンシーが高い場合です。このようなシナリオでは、データ プロバイダーと連携するとパフォーマンスに悪影響を及ぼす可能性があるため、製品データをSitecoreコンテンツでネイティブに利用できるようにしておくことをお勧めします。

分散システムのサポート

コンテンツ管理 (CM)、コンテンツ配信 (CD)、および外部コマース システム インスタンスが異なる地理的な場所にある場合、または同じネットワーク上の異なるサーバー インスタンス上にある場合は、待機時間が長くなる可能性があります。たとえば、CMとCDはクラウドにあり、外部のコマース システムはオンプレミスにある場合があります。このシナリオでは、リアルタイム呼び出しや品目データ プロバイダーを使用して外部コマース システムからデータを取得することは、おそらく不可能であり、実用的でもありません。

さらに、アイテム データ プロバイダーを使用すると、Sitecoreと外部システム間の接続に問題が発生した場合に、システムが脆弱になります。データがSitecoreコンテンツに同期されると、そのデータはすぐに、そして常に利用可能になります。

Sitecoreの製品リポジトリを最新の状態に保つことは、リソースを大量に消費しません

価格情報と在庫情報は動的であるため、コア製品データの一部としては扱われず、必要に応じてこの情報を取得するための個別のサービス層があります。これにより、Sitecoreの製品リポジトリには価格や在庫情報が含まれず、静的データのみが含まれるようになります。リポジトリに100万点の製品があっても、通常、定期的に更新、追加、削除する必要があるのはそのうちのごく一部です。

Sitecoreの製品リポジトリに同期される製品データの例は、nopCommerceと統合されたStarterKitソリューションで確認できます。ソリューションはGitHubにあります。

データ プロバイダー モデル

製品の同期を使用してCommerce Connectとの統合を作成するのは大きなタスクです。ただし、適切なパフォーマンスを実現するSitecoreデータ プロバイダーを作成してサポートすることも、同様に大きなタスクです。

データプロバイダーの実装は、外部コマースシステムでの商品データの構造化によって異なります。データ プロバイダーを使用する2つのコマース システムは、uCommerceとSitecore Commerceです。これらのシステムに共通しているのは、商品データが商品を含むネストされたカテゴリで構造化されていることです。これらのシステムの1つの違いは、製品アイテムに含まれるフィールドが異なることです。Sitecore Commerceとリファレンス ストアフロントを使用したソリューションの例は、GitHubで見つけることができます。

インデックスハイブリッドモデル

ハイブリッド ソリューションは、外部システムまたはSitecoreコンテンツに保存されている製品データに基づいてSitecore製品インデックスを作成することです。たとえば、Sitecore Commerceは、カタログの閲覧エクスペリエンスを促進する主要な手段としてインデックスを使用します。製品の詳細がレンダリングされると、データ プロバイダーを使用して外部カタログからライブで読み取られます。インデックスは、Sitecoreコンテンツに保存されているカタログ データをクロールすることによって構築されます。

インデックスをクエリするときに、返されたオブジェクトの一部としてConnect製品オブジェクトモデルを使用できます。Sitecore Content Searchの実装では、結果を返す前に、インデックスからのデータをオブジェクトに入力できます。インデックスに格納されていない情報は、インデックスから取得した製品IDを参照として外部コマースシステムからデータをロードするための外部システムまたはコンテンツから取得できます。

Sitecoreが返されたオブジェクトを自動的に入力するには、インデックス フィールド名がオブジェクトのプロパティと一致するか、属性を使用して設定する必要があります。

データストレージモデルと取得モデルの比較

データプロバイダーソリューションは、通常、製品データが外部のコマースシステムによって所有され、自然にそこに属しているため、最も適しているように思えるかもしれません。ただし、製品データをSitecoreやインデックスに保存する理由はいくつかあります。

次の表は、3つのデータ ストレージと取得モデルの違いを示しています。

製品の同期

データプロバイダー

インデックスハイブリッド

書き込み可能/更新可能

カタログデータを更新可能

Yes

データが同期されたら、Sitecoreでコンテンツを更新できます。

Depends外部システムとデータプロバイダー上。

例:Commerce Serverを更新できるMicrosoft Dynamics AX for Retailは更新できません

No

インデックスは静的です。

データの拡張が可能

Yes

モデルには、追加のフィールドやアイテムを追加できます。

Depends外部システムとデータ プロバイダーの実装。

No

Sitecoreで個別に管理するための追加コンテンツが必要になります。

複数のソースのサポート

Yes

複数のシステムからデータを取得するためのプロセッサを同期パイプラインに挿入できます。

Potentially

通常、ソースは1つだけです。

Potentially

通常、ソースは1つだけです。

カタログ・データへのアクセスの待ち時間

None

Sitecoreの速度にのみ依存します。

Depends外部システムの統合と近接性について。

Depends統合検索エンジンで。

カタログデータの公開と保守に必要な時間とリソース

Yes

定期的な製品の同期が必要です。

No

Yes

定期的なインデックスの再作成が必要です。

一般的なeコマースシナリオの強固な基盤

Yes

ストアフロントのシナリオを念頭に置いて設計されています。

Dependsデータ プロバイダーによって公開される仮想構造とデータ。

Dependsインデックスの内容と、それがどの程度完全であるか、または必要な情報を取得するために外部システムを頻繁に呼び出す必要があるかどうかについて。

冗長な製品データを回避できます

Yes

No

Sitecoreコンテンツからカタログ データをインデックス化する際には、次のことが課題になります。

通常、製品のデータは1つのSitecoreアイテムとして公開されるため、複数の製品が同じ値を持つ場合、データは複数回表示されます。

製品は複数の異なるカテゴリとカタログに属することができるため、コンテンツ ツリー構造の複数の異なる場所に表示されます。

No

製品のデータはすべてのインデックスドキュメントに格納されるため、複数の製品が同じ値を持つ場合、データは複数回表示されます。

商品は複数のカテゴリやカタログに属することができるため、インデックス内の複数の場所に表示されます。

eコマースベンダーが製品データをマッピングする簡単な方法

Yes

Depends外部システムのデータの構造と、それをツリー構造としてSitecoreで公開する方法について。

Depends外部システムのデータの構造と、フラットなインデックス構造にどのようにマップする必要があるかについて説明します。

開発者が最小限の労力で外部コマースシステムを置き換えることができる標準構造と、製品を管理するための既知の構造

Yes

No

すべてのデータ プロバイダーは、カタログ データに対して異なる仮想構造を公開します。

Yes

クローラとインデクサは、インデックスが同じフィールドとデータを保持するように作成できます。

この記事を改善するための提案がある場合は、 お知らせください!