コマース統合

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

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

ほとんどの組織では、通常、コマースシステムは記録システムとは見なされません。組織は、ほとんどの場合、ビジネスプロセスとデータの処理を他のレガシービジネスアプリケーションや情報システムに依存しています。たとえば、ほとんどのeコマースの実装では、ストアフロントからの注文は通常、エンタープライズリソースプランニング(ERP)や注文管理システムなどのバックオフィスシステムに送信され、さらに注文処理されます。もう1つの一般的な統合シナリオは、CRMまたはPOS(Point of Sale)システムに存在する顧客データをeコマースサイトと共有する必要がある場合です。

Sitecore Experience Commerce (XC) は、継続的な運用の一環として他の外部エンティティと対話するように設計されています。 Commerce Service APIは、サービス エンドポイントを介したCommerceコマンドの実行をサポートします。このセクションでは、Sitecore XCエンドポイントを使用して、基幹業務 (LOB) アプリケーションや (ERP) システムなどの他のビジネス システムとの商取引関連データの交換をサポートする方法、またはサードパーティのサービス プロバイダーと統合する方法について説明します。

Sitecore XC RESTful、OData準拠のWeb APIに基づく例に加えて、Commerce Viewsを活用するオーサリングAPIであるViews and Actions APIを使用する例もあります。

メモ

Views and Actions APIは、ビジネス・ユーザー・インターフェースを提供するように設計された オーサリングAPIであり、統合シナリオ用には最適化されていません。

コマース統合にViews and Actions APIを使用する場合は、次の点を考慮する必要があります。

  • Views and Actions APIは、一度に1つのCommerceエンティティのみを処理でき、バッチ処理をサポートしていません。

  • Views and Actions APIは、Commerce WebサービスAPIよりも多くのオーバーヘッドを伴います。Views and Action APIの呼び出しは、通常、アクションのビューを取得し、更新された値でビューのプロパティを変更してから、アクションを実行する必要がある3段階のプロセスです。

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、