概念 concepts

この統合フレームワークは、次のことを実行するメカニズムとコンポーネントを提供します。

つまり、

操作を最適化するために、AEM と e コマースエンジンはそれぞれの専門分野に専念します。情報は、両者の間でリアルタイムに転送されます。次に例を示します。

この統合レイヤーを使用するために、すぐに使える AEM コンポーネントがいくつか用意されています。現在は次のものを使用できます。

様々な検索オプションも使用できます。

アーキテクチャ architecture

この統合フレームワークは、API、機能を説明するための一連のコンポーネント、および接続方法の例を示すいくつかの拡張機能を提供します。

フレームワークを使用して、以下のような機能にアクセスできます。

実装 implementations

AEM e コマースは、e コマースエンジンとともに実装されます。

コマースプロバイダー commerce-providers

コマースエンジンから AEM e コマースサイトにデータを読み込む場合、コマースプロバイダーを利用してインポーターにデータを供給します。1 つのコマースプロバイダーが複数のインポーターをサポートできます。

コマースプロバイダーは、次のどちらかの目的でカスタマイズされた AEM コードです。

現在、AEM では次の 2 つのサンプルコマースプロバイダーを利用できます。

ただし、通常はプロジェクトで、その PIM と商品データスキーマに固有の、カスタマイズされた独自のコマースプロバイダーを作成する必要があります。

ProductServicesManager は、（OSGi を通じて）ProductImporter インターフェイスと CatalogBlueprintImporter インターフェイスの実装のリストを保守します。これらの実装は、インポーターウィザードの「インポーター／コマースプロバイダー」ドロップダウンフィールドに、commerceProvider プロパティを名前に使用して一覧表示されます。

ドロップダウンの特定のインポーター／コマースプロバイダーを利用できる場合は、必要な追加データがあれば（インポータータイプに応じて）次のどちらかに定義する必要があります。

該当する importers フォルダーの下のフォルダーは、インポーター名と一致している必要があります。次に例を示します。

読み込み元ファイルの形式は、インポーターによって定義されます。インポーターが、コマースエンジンへの接続（WebDAV や http など）を確立する場合もあります。

ロール roles

統合されたシステムには、データを保守する以下の役割が用意されています。

実際の場所は実装によって異なりますが、汎用実装または e コマースエンジンを使用する場合の例を以下に示します。

製品 products

製品データか、マーケティングデータか product-data-versus-marketing-data

構造カテゴリか、マーケティングカテゴリか structural-versus-marketing-categories

次の 2 つのカテゴリを区別できる場合、意味のある構造（cq:Page ノードのツリー）を使用して URL を明確にできるので、従来の AEM コンテンツ管理に非常に近くなります。

製品データ product-data

製品を描写し、管理するには、製品に関する幅広い情報を保持する必要があります。

製品データは、以下のようになります。

どちらの場合でも、製品データが AEM に入力されるか読み込まれると、製品 ​コンソールで表示できます。この表示では、製品のカードビューとリストビューには、以下のような情報が表示されます。

製品バリアント product-variants

製品によっては、バリアントに関する情報も保持できます。例えば、衣料品の場合は、販売されている様々なカラーをバリアントとして保持します。

製品属性 product-attributes

それぞれの製品に関して保持される個々の属性は、使用する e コマースエンジンと AEM の実装によって異なる場合があります。属性は、製品ページを表示したり、製品情報を編集したりするときに（必要に応じて）利用でき、次のものを含めることができます。

製品アセット product-assets

個々の製品について、選択されたアセットを保持できます。一般的には、画像とビデオが含まれます。

カタログ catalogs

カタログは、管理および買い物客に対する表示の両方を容易にするために、製品データをグループ化したものです。多くの場合、カタログは言語、地域、ブランド、季節、趣味、スポーツなど多くの属性に従って構造化されています。

カタログの構造 catalog-structure

複数言語のカタログ catalogs-in-multiple-languages

AEM は、製品コンテンツを複数言語でサポートします。データを要求すると、統合フレームワークが現在のツリーからその言語を取得します（/content/geometrixx-outdoors/en_US の配下のページの場合は en_US など）。

多言語ストアの場合、それぞれの言語ツリー用のカタログを個別に読み込む（または MSM を使用してコピーする）ことができます。

複数ブランドのカタログ catalogs-for-multiple-brands

言語と同様に、大規模な多国籍企業は、複数のブランドに対応する必要があります。

タグによるカタログ catalogs-by-tags

複数の製品をカタログにまとめるために、タグも使用できます。タグは、季節的なオファーなど、より動的なカタログに使用できます。

カタログの設定（初期読み込み） catalog-setup-initial-import

実装に応じて、基本カタログに必要な製品データを AEM に以下のものから読み込むことができます。

カタログのメンテナンス（データ同期） catalog-maintenance-data-synchronization

製品データに対する追加の変更は避けられません。

e コマースエンジンとのデータ同期（継続中） data-synchronization-with-an-ecommerce-engine-ongoing

初期読み込みの後、製品データの変更は避けられません。

e コマースエンジンを使用する場合、製品データはそこに保持され、AEM で利用できる必要があります。このような製品データは、更新されたときに同期が必要です。

同期は、データのタイプによって異なります。

カタログ - パフォーマンスと拡張 catalogs-performance-and-scaling

大量の製品（100,000 を超える）を含む大規模なカタログを e コマースエンジン（PIM）から読み込むと、ノード数が多いため、システムに影響を与えることがあります。製品にアセット（製品画像など）が関連付けられている場合は、オーサリングインスタンスの速度が低下する可能性もあります。これは、このようなアセットの後処理によって CPU とメモリに大きな負荷がかかるためです。

この問題を回避するために、様々な戦略を選択できます。

バケッティング bucketing

JCR ノードに多数の直接の子ノード（例えば、1000 以上）がある場合、パフォーマンスに影響を与えないようにするには、バケット（疑似フォルダー）が必要です。バケットは、読み込み時にアルゴリズムに従って生成されます。

これらのバケットは、カタログ構造に導入される疑似フォルダーの形式を取りますが、パブリック URL では見えないように設定できます。

アセットの後処理を専用インスタンスにオフロードする offload-asset-post-processing-to-a-dedicated-instance

このシナリオでは、次の 2 つのオーサーインスタンスを設定します。

商品データのみを読み込む only-import-product-data

読み込むアセット（画像）が商品に含まれていない場合は、アセットの後処理の影響を受けずに、商品データを読み込むことができます。

パフォーマンステスト performance-testing

AEM e コマースの実装では、パフォーマンステストを考慮する必要があります。

このようなパフォーマンステストには、ターゲットに関する次のような知識と分析が必要です。

パフォーマンス - その他 performance-miscellaneous

すべての実装において、次の点に注意してください。

カタログセクションページ catalog-section-pages

カタログセクションには、例えば以下のような情報が表示されます。

製品ページ product-pages

製品ページには、個々の製品に関する包括的な情報が表示されます。e コマースエンジンに登録された価格の変更など、動的なアップデートも反映されます。

製品ページは、例えば、コマース製品 ​テンプレート内などで​ 製品 ​コンポーネントを使用する AEM ページです。

製品コンポーネントには、次のものが表示されます。

買い物客は、アイテムを買い物かごに追加する際に、この情報を使用して以下を選択できます。

製品ランディングページ product-landing-pages

例えば、基になる製品ページへのリンクを含む紹介や概要など、主に静的な情報を表示する AEM ページです。

製品コンポーネント product-component

製品 ​コンポーネントは、必要なメタデータ（すなわち cartPage と cartObject へのパス）を提供する親ページを持つすべてのページに追加できます。これは、デモサイト Geometrixx Outdoors では UserInfo.jsp によって提供されています。

製品 ​コンポーネントは、個々の要件に応じてカスタマイズすることもできます。

プロキシページ proxy-pages

プロキシページを使用してリポジトリの構造を単純化し、大規模カタログのストレージを最適化できます。

カタログの作成では、AEM 内でアップデートおよびカスタマイズできる製品ごとに個別のコンポーネントが提供されるため、製品ごとに 10 個のノードが使用されます。カタログに数百、さらには数千の製品が含まれている場合、この多数のノードが問題になる可能性があります。問題を回避するために、プロキシページを使用してカタログを作成できます。

プロキシページでは、実際の商品コンテンツをまったく含まない 2 ノード構造（cq:Page と jcr:content）を使用しています。コンテンツは、要求時に商品データとテンプレートページを参照することで生成されます。

ただし、トレードオフがあります。AEM 内の製品情報をカスタマイズすることはできません。（サイト用に定義された）標準テンプレートが使用されます。

プロモーションと割引券 promotions-and-vouchers

割引券 vouchers

割引券は、買い物客を引きつけて購入させたり、顧客のロイヤルティに報いるために割引を提供する、十分に試行された手法です。

AEM で以下を行います。

プロモーション promotions

プロモーションと割引券を併用すると、次のようなシナリオを実現できます。

プロモーションは、商品情報マネージャーではなくマーケティングマネージャーが保守します。

AEM では、プロモーションはキャンペーン管理にも組み込まれます。

プロモーションは、エクスペリエンス内または直接キャンペーン内に保持できます。

パーソナライズ機能 personalization

顧客の登録とアカウント customer-registration-and-accounts

買い物客が登録したら、アカウントの詳細を AEM と e コマースエンジン間で同期する必要があります。機密データは個別に保持されますが、プロファイルは共有されます。

正確なメカニズムは、シナリオによって異なることがあります。

e コマースエンジンを使用している場合、AEM はアカウント ID とパスワード（オプションでユーザーグループ）だけを保存します。その他すべての情報は、e コマースエンジンに保存されます。

顧客の新規登録 customer-sign-up

多くの場合、買い物客が買い物かごにアクセスするには新規登録する必要があります。サインアップするには、顧客固有のアカウントを作成できるよう、登録（アカウントの作成）が必要です。

顧客のログイン customer-sign-in

新規登録後、買い物客はアクションを追跡したり、注文を受け渡したりできるように、アカウントを使用してログインできます。

シングルサインオン single-sign-on

シングルサインオン（SSO）の機能が導入されているので、作成者は AEM と e コマースシステムの両方で 2 回ログインせずに済みます。

マイアカウント myaccount

e コマースエンジンからのトランザクションデータは、買い物客に関する個人情報と結合されます。AEM は、このデータの一部をプロファイルデータとして使用します。AEM のフォームのアクションによって、情報が e コマースエンジンに書き戻されます。

アカウント情報を管理しやすくなるページが用意されています。このページにアクセスするには、Geometrixx ページ上部の「マイアカウント」をクリックするか、/content/geometrixx-outdoors/en/user/account.html に移動します。

アドレス帳 address-book

サイトには、配達先、請求先および代替住所を含む、選択対象のアドレスを保存する必要があります。デフォルトのアドレス形式に基づくフォームを使用して実装することも、AEM が提供するアドレス帳コンポーネントを使用することもできます。

このアドレス帳コンポーネントでは、次のことが可能です。

デフォルトとするアドレスを選択できます。

アドレス帳コンポーネントにアクセスするには、マイアカウント ​ページから「アドレス帳」をクリックするか、/content/geometrixx-outdoors/en/user/account/address-book.html に移動します。

「新しいアドレスを追加…」をクリックして、アドレス帳に新しいアドレスを追加できます。フォームが表示されたら、入力して「アドレスを追加」をクリックします。

アドレス帳は、買い物かごのチェックアウト時に使用されます。

アドレスは、user_home/profile/addresses の下に保持されます。
例えば、Alison Parker の場合は、/home/users/geometrixx/aparker@geometrixx.info/profile/addresses の下です。

デフォルトとするアドレスを選択できます。この情報は、アドレスと一緒にではなく、買い物客のプロファイルに保持されます。プロファイルのプロパティ address.default の値が、選択されたアドレスのパスに設定されます。

顧客固有の価格 customer-specific-pricing

e コマースエンジンは、コンテキスト（基本的には買い物客の情報）を使用して保持している価格を判断してから、正しい情報を AEM に返します。

買い物かごと注文 shopping-cart-and-orders

買い物をする際に、買い物客は商品ページを閲覧し、アイテムを選択して買い物かごに入れます。チェックアウトに進むと、注文できます。

匿名の買い物客 anonymous-shoppers

匿名の顧客は、次のことが可能です。

登録済みの買い物客 registered-shoppers

登録済みの顧客は、次のことが可能です。

買い物かごの中身の概要 shopping-cart-content-overview

買い物かごには次の情報が表示されます。

買い物かごは、使用しているエンジンに応じて次のように保存されます。

どちらの場合も、アイテムはログイン／ログアウトをまたがって（同じコンピューター／ブラウザーの場合に限り）買い物かごに残ります（復元することもできます）。例：

価格の変更が発生すると、チェックアウト前に（両方のシステムに）反映されます。

注文情報 order-information

使用する実装に応じて、注文に関する情報は e コマースエンジンまたは AEM のどちらかに保持され、この情報は AEM によってレンダリングされます。

次の情報を含む様々な情報が保存されます。

注文が AEM 内に保持されている場合、注文コンソールには注文ごとに次の内容が表示されます。

注文の追跡 order-tracking

注文後、多くの場合、買い物客は戻って以下を実行します。

注文の配達を受け取った後、買い物客は一定期間に行われた注文の履歴を表示することもできます。

注文の受け渡しと追跡は、通常は e コマースエンジンによって管理されます。注文履歴コンポーネントを使用して、AEM で情報を表示できます。このコンポーネントには、適用された割引券やプロモーションを含む、関連する詳細がすべて表示されます。例：

チェックアウト checkout

チェックアウトは、標準の AEM フォームを使用して実装されます。マーケティングマネージャーは、チェックアウトを使用して、マーケティングコンテンツでエクスペリエンスをカスタマイズできます。

その後、e コマースエンジンが AEM フォームからの入力を使用して、チェックアウトプロセスを管理します。

支払いのセキュリティ payment-security

クレジットカード情報を含む支払詳細は、多くの場合、e コマースエンジンが管理します。AEM は、そのようなトランザクション情報をエンジンに転送します（情報はエンジンから支払い処理サービスに転送されます）。

Payment Card Industry（PCI）コンプライアンスを実現できます。

注文の確認 confirmation-of-order

注文は画面上で確認され、注文の追跡によって追跡できます。

検索 search-features

AEM は商品に標準のページを使用しているので、標準の検索コンポーネントを使用して検索ページを作成できます。

より完全な実装が必要な場合は、次のどちらかを実行できます。

e コマースエンジンを使用している場合は、e コマースエンジンソリューションに e コマース検索 API を完全に実装できるので、標準で提供されている e コマース検索コンポーネントを使用できます。ファセット検索を利用して、JCR やエンジンを検索できます。