概念 concepts

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

つまり、

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

この統合レイヤーを使用するために、すぐに使える 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

また、タグを使用して、製品を 1 つのカタログにグループ化することもできます。 タグは、季節的なオファーなど、より動的なカタログに使用できます。

カタログの設定（初期読み込み） 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 コマースエンジンに登録されている価格の変更などです。

製品ページは、 製品 コンポーネント例えば、 コマース製品 テンプレート：

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

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

製品ランディングページ 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では、プロモーションも Campaign Management:

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

パーソナライズ機能 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 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 forms で実装されます。 これにより、マーケティングマネージャーはマーケティングコンテンツでエクスペリエンスをカスタマイズできます。

次に、e コマースは、AEM forms からの入力を使用してチェックアウトプロセスを管理します。

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

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

決済カード業界 (PCI) の複雑さを実現できます。

注文の確認 confirmation-of-order

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

検索 search-features

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

より詳細な実装が必要な場合は、次のいずれかを実行できます。

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