この統合フレームワークは、次のことを実行するメカニズムとコンポーネントを提供します。
つまり、
e コマースフレームワークは、以下のものと併用できます。
e コマース統合フレームワークは AEM アドオンです。
ご利用のエンジンに応じて、営業担当者が詳しくご説明します。
このフレームワークは、独自プロジェクトの基本要件となります。
フレームワークを実際の仕様に適合させるには、ある程度の開発作業が必要です。
標準の AEM インストールには、汎用 AEM(JCR)e コマース実装が含まれています。
現時点では、デモンストレーション目的またはユーザーの要件に応じたカスタム実装の基盤として使用されています。
操作を最適化するために、AEM と e コマースエンジンはそれぞれの専門分野に専念します。情報は、両者の間でリアルタイムに転送されます。次に例を示します。
AEM がすること:
リクエスト:
以下を指定します。
e コマースエンジンがすること:
以下を指定します。
プロセス:
詳細は、e コマースエンジンとプロジェクトの実装によって異なります。
この統合レイヤーを使用するために、すぐに使える AEM コンポーネントが多数用意されています。現在は次のものを使用できます。
様々な検索オプションも使用できます。
統合フレームワークは、API、機能を説明する幅広いコンポーネント、接続方法の例を示すいくつかの拡張を提供します。
フレームワークを使用して、以下のような機能にアクセスできます。
AEM e コマースは、e コマースエンジンとともに実装されます。
標準の AEM インストールには、汎用 AEM(JCR)e コマース実装が含まれています。
現時点では、デモンストレーション目的またはユーザーの要件に応じたカスタム実装の基盤として使用されています。
JCR をベースとする汎用的な開発によって AEM 内に実装される AEM e コマースは、
API の使用方法を説明するための、スタンドアロンの AEM ネイティブな e コマースのサンプルです。これにより、商品データ、ショッピングカート、チェックアウトと共に、既存のデータ表示とマーケティングキャンペーンを制御することができます。この場合、商品データは AEM にネイティブなリポジトリ(アドビの JCR 実装)に保存されます。
標準的な AEM のインストールには、一般的な e コマースの実装の基本が含まれています。
コマースエンジンから AEM e コマースサイトにデータを読み込む場合、コマースプロバイダーを利用してインポーターにデータを供給します。1 つのコマースプロバイダーが複数のインポーターをサポートできます。
コマースプロバイダーは、次のどちらかの目的でカスタマイズされた AEM コードです。
現在、AEM では次の 2 つのサンプルコマースプロバイダーを利用できます。
ただし、通常は、プロジェクトがその PIM と商品データスキーマに固有のカスタマイズされた独自コマースプロバイダーを作成する必要があります。
geometrixx インポーターは、CSV ファイルを使用します。実装の上のコメントに、受け入れられているスキーマ(と許可されているカスタムプロパティ)の説明があります。
ProductServicesManager は、(OSGi を通じて)ProductImporter インターフェイスと CatalogBlueprintImporter インターフェイスの実装のリストを保守します。これらの実装は、インポーターウィザードの「インポーター/コマースプロバイダー」ドロップダウンフィールドに、commerceProvider
プロパティを名前に使用して一覧表示されます。
ドロップダウンの特定のインポーター/コマースプロバイダーを利用できる場合は、必要な追加データがあれば(インポータータイプに応じて)次のどちらかに定義する必要があります。
/apps/commerce/gui/content/catalogs/importblueprintswizard/importers
/apps/commerce/gui/content/products/importproductswizard/importers
該当する importers
フォルダーの下のフォルダーは、インポーター名と一致している必要があります。次に例を示します。
.../importproductswizard/importers/geometrixx/.content.xml
読み込み元ファイルの形式は、インポーターによって定義されます。あるいは、インポーターは、コマースエンジンへの接続(例:WebDAV または http)を確立できます。
統合されたシステムには、データを保守する以下の役割が用意されています。
次のものを保守する商品情報管理(PIM)ユーザー
次のものを保守するオーサー/マーケティングマネージャー
次のことを実行するサーファー/買い物客
実際の場所は実装によって異なりますが、汎用実装または e コマースエンジンを使用する場合の例を以下に示します。
次の 2 つのカテゴリを区別できる場合、意味のある構造(cq:Page
ノードのツリー)を使用して URL を明確にできるので、従来の AEM コンテンツ管理に非常に近くなります。
構造的カテゴリ
製品の概要を定義するカテゴリツリー。例を以下に示します。
/products/mens/shoes/sneakers
マーケティングカテゴリ
製品が所属できるその他すべてのカテゴリ。例を以下に示します。
/special-offers/christmas/shoes
)
商品を表し、管理するには、商品に関する幅広い情報を保持する必要があります。
商品データは、
AEM(汎用)に直接保持できます。
e コマースエンジンに保持して、AEM で利用できます。
データタイプにより、必要に応じて同期したり、直接アクセスしたりできます。例えば、商品価格などの非常に変動しやすく重要なデータは、ページ要求のたびに e コマースエンジンから取得して、常に最新であることを保証します。
どちらの場合でも、商品データが AEM に入力されるか読み込まれると、製品コンソールで表示できます。商品のカードビューとリストビューには、次のような情報が表示されます。
商品によっては、バリアントに関する情報も保持できます。例えば、衣料品の場合は、販売されている様々なカラーをバリアントとして保持します。
各商品に関して保持される個々の属性は、使用する e コマースエンジンと AEM 実装によって異なる場合があります。属性は、商品ページを表示したり、商品情報を編集したりするときに(必要に応じて)利用でき、次のものを含めることができます。
画像
商品の画像。
タイトル
商品名。
説明
テキストによる商品の説明。
タグ
関連商品のグループ化に使用するタグ。
デフォルトのアセットカテゴリ
アセットのデフォルトカテゴリです。
ERP データ
エンタープライズリソースプランニング(ERP)に関する情報。
SKU
在庫管理単位(SKU)に関する情報。
カラー
サイズ
価格
商品の単価。
概要
商品の特長の概要。
機能
商品の特長の詳細。
個々の商品について、選択されたアセットを保持できます。一般的には、画像とビデオが含まれます。
カタログは、管理および買い物客に対する表示を容易にするために、商品データをグループ化したものです。多くの場合、カタログは言語、地理的領域、ブランド、季節、趣味、スポーツなど多くの属性に従って構造化されています。
AEM は、商品コンテンツを複数言語でサポートします。データを要求すると、統合フレームワークが現在のツリーからその言語を取得します(/content/geometrixx-outdoors/en_US
の配下のページの場合は en_US
など)。
多言語ストアの場合、各言語ツリー用のカタログを個別に読み込む(または MSM を使用してコピーする)ことができます。
言語と同様に、大規模な多国籍企業は、複数のブランドを提供しなければならないことがあります。
複数の商品をカタログにまとめるために、タグも使用できます。タグは、季節的なオファーなど、より動的なカタログに使用できます。
実装に応じて、基本カタログに必要な商品データを次のものから AEM に読み込むことができます。
商品データの変更は必ず発生します。
初期読み込み後、商品データの変更は必ず発生します。
e コマースエンジンを使用している場合、商品データはその e コマースエンジンに保持され、AEM で使用できなければなりません。このような商品データは、更新されたときに同期が必要です。
同期は、データのタイプによって異なります。
これに加え、特定の更新を選択して高速更新をおこなうことができます。
価格情報などの非常に変動しやすいデータは、ページ要求のたびにコマースエンジンから取得して、常に最新であることを保証します。
商品数が多い(通常は 100,000 以上)大規模なカタログを e コマースエンジン(PIM)から読み込むと、多数のノードによってシステムに影響を与えることがあります。商品にアセット(商品画像など)が関連付けられている場合は、オーサリングインスタンスが低速化する可能性もあります。これは、このようなアセットの後処理に CPU とメモリが集中することによるものです。
この問題を回避するために、様々な方法を選択できます。
JCR ノードの直下に多数の子ノード(1000 以上)がある場合は、パフォーマンスが影響を受けないようにするために、バケット(疑似フォルダー)が必要です。バケットは、読み込み時にアルゴリズムに従って生成されます。
これらのバケットは、カタログ構造に取り込まれた疑似フォルダーの形を取りますが、公開 URL に表示されないように設定できます。
このシナリオでは、次の 2 つのオーサーインスタンスを設定します。
プライマリオーサーインスタンス
PIM から商品データをインポートします。PIM ではアセットパスの後処理は無効になっています。
専用の DAM オーサーインスタンス
PIM から商品アセットをインポートして後処理を実行したあと、プライマリオーサーインスタンスで使用できるように商品アセットをレプリケートします。
商品に読み込むアセット(画像)が含まれない場合は、アセットの後処理に影響を受けることなく、商品データを読み込むことができます。
AEM e コマース実装では、パフォーマンステストを考慮に入れる必要があります。
オーサー環境:
バックグラウンドアクティビティ(インポートなど)が通常のユーザーアクティビティ(ページ編集など)と同時に発生する可能性があり、フロントエンドのパフォーマンスの優先度のほうが(一般的に)高い場合でも、オンラインオーサーのパフォーマンスが低下してフラストレーションにつながり、稼動開始の決定が妨げられることがあります。
パブリッシュ環境:
レプリケーションは、コンテンツが迅速かつ確実に公開されるようにする重要なプロセスです。レプリケーションは、公開するコンテンツをオーサーがどのようにグループ化するかによって影響を受ける場合があります。
フロントエンド:
フロントエンドの無効化とキャッシュの無効化が混在すると、予期せぬパフォーマンスの低下につながる可能性があります。この問題はテストによって回避できます。
このようなパフォーマンステストには、ターゲットに関する次のような知識と分析が必要です。
コンテンツのボリューム
ユーザーアクティビティ:
バックグラウンドプロセス
メンテナンス要件(バックアップ、Tar PM の最適化、データストアのガベージコレクションなど)
すべての実装で、以下の点に留意してください。
商品、在庫管理単位およびカテゴリは膨大な数になることがあるので、できる限り少ないノード数でコンテンツをモデリングしてください。
ノードが多くなればなるほど、コンテンツ(parsys など)は柔軟になります。しかし、何事もバランスです。(例えば)3 万もの商品を操作する場合に(デフォルトで)個々の柔軟性が必要でしょうか。
できる限り重複を避ける(ローカライズを参照)か、ローカライズ時に重複によっていくつのノードが作成されるかを考えてください。
クエリの最適化に備えて、コンテンツにはできる限りタグ付けしてください。
次に例を示します。
/content/products/france/fr/shoe/reebok/pump/46 SKU
コンテンツレベル(国、言語、カテゴリ、ブランド、製品など)ごとに 1 つのタグが必要です。 検索
//element(*,my:Sku)[@country=’france’ and @language=’fr’
および
@category=’shoe’ and @brand=’reebok’ and @product=’pump’]
以下を検索するよりも大幅に速くなります
/jcr:root/content/france/fr/shoe/reebok/pump/element(*,my:Sku)
ユーザーが蓄積している技術を利用し、コンテンツアクセスモデルおよびサービスを非常に細かく分解して計画します。これは一般的なベストプラクティスですが、最適化フェーズではより不可欠になります。頻繁に読み取られる(そしてバンドルのキャッシュをいっぱいにしたくない)データ用に、アプリケーションキャッシュを追加してください。
例えば、属性管理は商品の読み込みによって更新されるデータに関係するので、しばしばキャッシュに適した候補となります。
プロキシページの使用を検討します。
カタログセクションには、次のものが表示されます。
商品ページには、個々の商品に関する包括的な情報が表示されます。e コマースエンジンに登録された価格の変更など、動的な更新も反映されます。
商品ページは、コマース製品テンプレート内などで製品コンポーネントを使用する AEM ページです。
製品コンポーネントには、次のものが表示されます。
買い物客は、アイテムを買い物かごに追加する際に、この情報を使用して以下を選択できます。
基盤となる商品ページへのリンクを含む紹介や概要など、主に静的な情報を表示する AEM ページです。
製品コンポーネントは、必要なメタデータ(すなわち cartPage
と cartObject
へのパス)を提供する親ページを持つすべてのページに追加できます。これは、デモサイト Geometrixx Outdoors では UserInfo.jsp
によって提供されています。
製品コンポーネントは、個々の要件に応じてカスタマイズすることもできます。
プロキシページを使用してリポジトリの構造を単純化し、大規模カタログのストレージを最適化できます。
カタログの作成では、商品あたり 10 ノードを使用します。AEM 内で更新およびカスタマイズできる商品ごとに、個別のコンポーネントを提供するからです。このようにノード数が多いと、カタログに何百、何千もの商品が含まれる場合、問題が生じる場合があります。問題を回避するために、プロキシページを使用してカタログを作成できます。
プロキシページでは、実際の商品コンテンツをまったく含まない 2 ノード構造(cq:Page
と jcr:content
)を使用しています。コンテンツは、要求時に商品データとテンプレートページを参照することで生成されます。
ただし、デメリットもあります。AEM 内の商品情報をカスタマイズすることはできません。(サイト用に定義された)標準テンプレートが使用されます。
プロキシページを持たない大規模カタログを読み込んだ場合、問題は発生しません。
いつでももう一方の手段に変更できます。カタログのサブセクションを変更することもできます。
割引券は、買い物客に買い物をしてもらうためや顧客の忠誠度に見返りを与えるために割引を提供する、十分に試行された手法です。
割引券は、次のものを提供します。
外部コマースエンジンも割引券を提供できます。
AEM では、
割引券は、Web サイトコンソールを使用して作成/編集するページベースのコンポーネントです。
割引券コンポーネントは、次のものを提供します。
割引券には、独自の開始日時や終了日時は設定されておらず、親キャンペーンの開始日時や終了日時を使用します。
AEM では割引券という用語を使用します。これは、クーポンという用語と同義です。
プロモーションと割引券を併用すると、次のようなシナリオを実現できます。
プロモーションは、通常は商品情報マネージャーではなくマーケティングマネージャーが保守します。
プロモーションは、Web サイトコンソールを使用して作成/編集されるページベースのコンポーネントです。``
プロモーションは、次のものを提供します。
プロモーションをキャンペーンに関連付けて、有効/無効日付/回数を定義できます。
プロモーションをエクスペリエンスに関連付けて、セグメントを定義できます。
エクスペリエンスに関連付けられていないプロモーションは、単独では呼び出されませんが、割引券によって呼び出せます。
プロモーションコンポーネントには、次のものが含まれます。
AEM では、プロモーションはキャンペーン管理にも組み込まれます。
プロモーションは、エクスペリエンス内またはキャンペーン内に直接保持できます。
プロモーションをエクスペリエンス内に保持する場合は、プロモーションをオーディエンスセグメントに自動的に適用できます。
例えば、geometrixx-outdoors サンプルサイトでは、次のプロモーションが実施されます。
/content/campaigns/geometrixx-outdoors/big-spender/ordervalueover100/free-shipping
がエクスペリエンス内にあるので、セグメント(ordervalueover100
)が解決されるたびに自動的に起動されます。
エクスペリエンス内に存在しない(キャンペーン内にのみ存在する)プロモーションの場合は、自動的にはオーディエンスに適用されません。ただし、買い物客が割引券を買い物かごに入力し、その割引券がプロモーションを参照している場合には、プロモーションが呼び出されます。
例えば、次のプロモーションでは、
/content/campaigns/geometrixx-outdoors/article/10-bucks-off
エクスペリエンス外にあるので、自動的には起動されません(つまり、セグメント化に基づいています)。 ただし、このプロモーションを参照する割引券が、記事のキャンペーンに含まれるいくつかのエクスペリエンスにあります。これらの割引券コードを買い物かごに入力すると、プロモーションが呼び出されます。
hybris プロモーションと hybris 割引券は、買い物かごに影響を及ぼし、価格に関連するすべてのものを対象とします。プロモーション固有のマーケティングコンテンツ(バナーなど)は、hybris プロモーションに含まれません。
買い物客が登録したら、アカウントの詳細を AEM と e コマースエンジン間で同期する必要があります。機密データは個別に保持されますが、プロファイルは共有されます。
正確なメカニズムは、シナリオによって異なることがあります。
ユーザーアカウントがどちらのシステムにも存在する場合:
ユーザーアカウントが AEM にのみ存在する場合:
ユーザーアカウントが e コマースエンジンにのみ存在する場合:
e コマースエンジンを使用している場合、AEM はアカウント ID とパスワード(オプションでユーザーグループ)だけを保存します。その他すべての情報は、e コマースエンジンに保存されます。
e コマースエンジンを使用している場合、AEM インスタンスにログインするユーザー用に作成されたアカウントが、そのエンジンとやり取りするその他すべての AEM インスタンスに(ワークフローを使用するなどして)レプリケートされていることを確認する必要があります。
そうでない場合は、このような他の AEM インスタンスも、エンジン内に同じユーザーのアカウントを作成しようとします。このようなアクションは、エンジンから DuplicateUidException
を受信して失敗します。
多くの場合、買い物客が買い物かごにアクセスするにはサインアップする必要があります。サインアップするには、顧客固有のアカウントを作成できるよう、登録(アカウントの作成)が必要です。
匿名の買い物かごとチェックアウトもサポートされています。
サインアップ後、買い物客はアクションを追跡したり、注文を受け渡したりできるように、アカウントを使用してログインできます。
シングルサインオン(SSO)の機能が導入されているので、作成者は AEM と e コマースシステムの両方で 2 回ログインせずに済みます。
e コマースエンジンからのトランザクションデータは、買い物客に関する個人情報と結合されます。AEM は、このデータの一部をプロファイルデータとして使用します。AEM のフォームのアクションによって、情報が e コマースエンジンに書き戻されます。
アカウント情報を管理しやすくなるページが用意されています。このページにアクセスするには、geometrixx ページ上部の「マイアカウント」をクリックするか、/content/geometrixx-outdoors/en/user/account.html
に移動します。
サイトには、配達先、請求先および代替住所を含む、選択対象のアドレスを保存する必要があります。デフォルトのアドレス形式に基づくフォームを使用して実装することも、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
の値が、選択されたアドレスのパスに設定されます。
e コマースエンジンは、コンテキスト(基本的には買い物客の情報)を使用して保持している価格を判断してから、正しい情報を AEM に返します。
買い物をするとき、買い物客は商品ページを参照して、アイテムを選択し、買い物かごに入れます。チェックアウトに進むと、注文できます。
匿名の顧客は、次のことが可能です。
インスタンスの設定によっては、チェックアウト前にアドレス情報すなわち顧客の登録が必要な場合があります。
登録済みの顧客は、次のことが可能です。
買い物かごには次のものがあります。
選択されたアイテムの概要
選択されたアイテムの商品ページへのリンク
次のことを実行する機能
買い物かごは、使用しているエンジンに応じて次のように保存されます。
どちらの場合も、アイテムはログイン/ログアウトをまたがって(ただし同じコンピューター/ブラウザー上でのみ)買い物かごに残ります(そして復元できます)。次に例を示します。
anonymous
として閲覧し、商品を買い物かごに追加する
Allison Parker
としてログインします - 彼女の買い物かごは空です
商品を買い物かごに追加する
ログアウト - 買い物かごには anonymous
の商品が表示される
Allison Parker
として再度ログインします - 彼女の商品が買い物かごに復元されます
anonymous の買い物かごは、同じコンピューター/ブラウザー上でのみ復元できます。
admin
アカウントを使用して買い物かごの中身の復元をテストすることはお勧めしません。e コマースエンジン(hybris など)の admin
アカウントと競合する可能性があるからです。
定義済みの時間が経過したら保留中の買い物かごを削除するように hybris を設定できます。
価格の変更が発生すると、チェックアウト前に(両方のシステムに)反映されます。
使用する実装に応じて、注文に関する情報は e コマースエンジンまたは AEM のどちらかに保持されます。この情報は、AEM によってレンダリングされます。
以下を含む、様々な情報が保存されます。
注文 ID
注文の参照番号。
注文日時
発注日。
ステータス
注文のステータス。例:発送済み
通貨
注文の通貨。
コンテンツ項目
並べ替えられた品目のリスト。
小計
注文された品目の合計金額。
税
注文に対して支払うすべての税金の金額。
送料
送料。
合計
注文の合計金額(注文された品目、税、送料)。
請求先住所
請求書を送付する住所。
支払いトークン
支払い方法。
支払いステータス
支払のステータス。
発送先住所
商品を発送する住所。
発送方法
発送の方法。例:陸路、海路または空路。
追跡番号
配送会社が使用する追跡番号。
追跡リンク
配送中に注文の追跡に使用するリンク。
注文を作成ウィザードで使用されるフィールドは、タッチ操作向けの基礎モードがその場所に対して定義されているかどうかで決まります。一般的な例では、次の場所にあります。
/etc/scaffolding/geometrixx-outdoors/order/jcr:content/cq:dialog
注文が AEM 内に保持されている場合、注文コンソールには注文ごとに次の内容が表示されます。
注文後、多くの場合、買い物客は戻って以下を実行します。
注文の配達を受け取った後、買い物客は一定期間におこなわれた注文の履歴を表示することもできます。
注文の受け渡しと追跡は、通常は e コマースエンジンによって管理されます。注文履歴コンポーネントを使用して、AEM で情報を表示できます。このコンポーネントには、適用された割引券やプロモーションを含む、関連する詳細がすべて表示されます。次に例を示します。
チェックアウトは、標準の AEM フォームを使用して実装されます。マーケティングマネージャーは、チェックアウトを使用して、マーケティングコンテンツでエクスペリエンスをカスタマイズできます。
その後、e コマースエンジンが AEM フォームからの入力を使用して、チェックアウトプロセスを管理します。
クレジットカード情報を含む支払いの詳細は、多くの場合、e コマースエンジンが管理します。AEM は、そのようなトランザクション情報をエンジンに転送します(情報はエンジンから支払い処理サービスに転送されます)。
Payment Card Industry(PCI)コンプライアンスを実現できます。
注文は画面上で確認され、注文の追跡によって追跡できます。
AEM は商品に標準のページを使用しているので、標準の検索コンポーネントを使用して検索ページを作成できます。
より完全な実装が必要な場合は、次のどちらかを実行できます。
CommerceService
に検索メソッドを実装し、検索ページで e コマース検索コンポーネントを使用する。e コマースエンジンを使用している場合は、e コマースエンジンソリューションに e コマース検索 API を完全に実装できるので、標準で提供されている e コマース検索コンポーネントを使用できます。ファセット検索を利用して、JCR やエンジンを検索できます。