マルチチャネルサイトのアップグレード。 人生を楽にする方法

サイトのアップグレードは、なじみのない海で泳ぐようなものです。どのような種類の水中礁に出会うかわかりません。 しかし、もしあなたのサイトが多くのチャンネルからなる大きくて複雑なシステムであり、それぞれが独自の技術スタック上に構築されているとしたらどうでしょうか？ 間違ったコースを選択するだけでなく、drれ、サイトの顧客の機能のすべての機能を理解しようとすることもできます。



今日の記事では、 Adobe Experience Managerの助けを借りて近代化の成功の経験を共有し、このソリューションをマルチチャネルサイトに適用する方法を説明したいと思います。





続きを読む







最新ではなく、むしろシンプルなサイトの近代化は興味深い仕事ですが、彼らが言うように、「ねじれ」なしで。 もう1つは、顧客のサイトが50以上の異なるビジネスであり、それぞれが独自のテクノロジーセット（hybris、.NET、Javaなど）を使用している場合です。 上記のすべてを1つの完全に機能するシステムに結合し、サイトの各チャネルを定性的に更新することは一種の課題ですが、不可能はありません。



上記の点に加えて、私たちによって更新されたサイトの各チャンネルはそれ自体の生活を送っていたという事実に注目したいと思います。 このような「独立性」は、最も単純な変更の導入でさえ開発者の参加を必要とするという事実につながりました。 すべてのチャネルに同時に新しいロゴをロードするなどの単純な更新は、テスト時のビルドと展開の調整という点でかなり複雑な手順になりました。 新しいビジネスの追加と既存のビジネスのサポートの難しさ、モバイルデバイスとタブレットのサポートの欠如（これは私たちの時代にはすでに非常に重要です）およびローカリゼーションの問題により、顧客はサイトの最適化のために私たちに連絡しました。

Adobe Experience Managerを選ぶ理由

このソリューションには、マルチチャネルサイトの最適化に最適な機能が備わっています。 まず第一に、これは基本的なコンポーネントとセクション（バックエンドとフロントエンドの両方）の高レベルの再利用です。これは、新しいチャネルに最適化し、不足している機能を完成させて時間を短縮できるため、非常に重要ですと努力。 2番目のポイントは、国際化とローカリゼーションのサポートをそのまま使用できることです。これにより、顧客はビジネスを他の国に拡大する計画があるため、開発が大幅に簡素化されます。 AEMはコンテンツ管理およびエクスペリエンス管理システムでもあり、サイトで表示されるものを管理する上で非常に柔軟性があります。 とりわけ、これはコンテンツ編集です。機能をモジュールに分割し、プログラマーやコードを記述せずにモジュールを管理する機能、OSGiテクノロジーのおかげでバックエンドロジックを作成し、コンテンツをスケーリングおよびパーソナライズします。

近代化：彼らが使用したもの、彼らがしたこと、その理由

上記のテキストから明らかなように、管理者にとっての機能と利便性の基盤として、Adobe Experience Managerのテクノロジーを採用しました。 もちろん、この技術だけでは十分ではありませんでした。 Bootstrapに基づいて、静的サイトテンプレートを再設計し、バックエンドパーツとビジネスロジックを追加しました（モバイルデバイス用にHTML 5を使用した適応レイアウトがあり、一般に、現代のサイトに典型的なすべてのバンを追加しました）。 また、さまざまなタイプのデバイスの機能と最適化されたパフォーマンスを改善し、クラウドサービスの追加によりアプリケーションのスケーラビリティのためのアーキテクチャソリューションを追加しました。



顧客のビジネスの多くの分野は類似しているため、再利用可能なコンポーネントを作成することが決定されました。 別のチャネル用に新しいコンポーネントを開発するたびに、実際に同じ場合、なぜ異なるように構成されているのですか（異なるテキストまたはサービスへのデータ送信方法）。 さまざまなビジネスケースに対して、コンポーネントの基本オプションと特定オプションを設定し、同様のケースでの使用を簡素化しました。 このソリューションのおかげで、新しい機能の追加とサービスの統合がより透明になりました。 もちろん、サービスに新しいフィールドを理解させるためにバックエンドの小さな更新が必要ですが、フロントエンド自体はずっと簡単になりました。 次に、新しい機能を追加するには、エディターを使用して、目的と煙テストの結果に応じてコンポーネントを構成するために必要な操作を実行し、ページを公開する必要があります。



再利用可能なコンポーネントを作成するだけでなく、これらすべてのコンポーネントをページに追加し、それらの間の相互作用の特定のロジックを実装するためのフレームワークを開発することも困難でした。 たとえば、サイトのチャネルの1つで、次のロジックを構成する必要がありました。異なるタイプの住宅用不動産を選択する場合、ユーザーに特定のタイプの質問をする必要があります。 つまり、ユーザーがアパートに住んでいることを選択した場合、どの階に住んでいるかを質問する必要があります。 したがって、彼が個人の家に住んでいる場合、そのような質問は彼にとっては無関係です。



高品質のデータ処理を行うには、回答の検証の設定など、コンポーネント間を統合する必要がありました。たとえば、1985年に生まれたことをユーザーが選択した場合、40年以上財産を所有することはできません。



これをどうやってやったの？ そのような機能を実装し、コンポーネント間でやり取りし、サービスに保存して送信するために、Adobe Experience ManagerとAngular.jsの機能を統合しました。 たとえば、表示ロジックを制御するために、AEMで使用される各コンポーネントには、設定に可視性と呼ばれるフィールドがあります。 このフィールドは、コンポーネントがユーザーに表示されるかどうかを決定します。 このフィールドは使用するのが最も便利ではないことを認識しておく価値がありますが、そのおかげで純粋なJavaScriptを使用して関数を記述せずに、コンポーネントをAngularエコシステムに統合することができます。 ここの例は式user.answers.dateOfBirth> 01-01-1970です。これは、指定されたコンポーネントをラップするng-ifディレクティブに置換される生年月日で検証します。 Angularの双方向バインディングのおかげで、フィールドに変更を加えても、すべてが1つの全体に結合されるため、気付かれることはありません。 変更を行った後、このフィールドを表示するかどうかにかかわらず、再カウントが行われます。

他にどんな面白いものが使用されましたか？

私たちが適用した別の興味深いソリューションは、フロントエンドストレージスキームをバックエンド送信スキームから分離することでした。 顧客のサイトは主にフォームに記入することで構成されているため、ユーザーの応答がJSON形式でローカルストレージ（HTML5機能）に保存されるようにしました。 次に、フロントエンドとバックエンド向けのデータが分離され、後の変換のために後者がAEMに送信されます。 入力データは、フロントエンドパーツとRESTサービスの統合レベルでサービススキームに変換されます。RESTサービスは、サイトユーザーに適したサービスの検索に関与します。 同様に、逆方向にデータ変換を実行します：ユーザーがログインして、すでに入力されているデータから何かを選択したい場合、RESTサービスが提供するデータは再びフロントエンドで使用されるデータ形式に変換されます。 これを実現するために、サービスとの各統合（たとえば、データベースで最適な製品を検索するサービスにデータを送信する）を説明し、適切な形式で説明し、構造ノードとしてAEMリポジトリに保存しました。

パーソナライズ機能

AEMは、コンテンツをパーソナライズするための優れた機会を提供するという点で優れています。 私たちのケースでは、フレームワークとともにすぐに使用できるモジュールを使用し、自分用に最適化し、既存のセグメントに追加のユーザーセグメントを作成しました。 結果は何ですか？ チャンネルのホームページはパーソナライズされ、ウェルカムメッセージがあり、ユーザーのクエリ履歴が表示されます。 ユーザーがアカウントからログアウトしても、ページはユーザー名を記憶しますが、ログインを提案します。 ユーザーがシステムが間違っていると主張し、それが彼/彼女ではない場合、ユーザーは匿名ユーザーとしてサイトを使用するように求められ、この場合はまったく異なるコンテンツが表示されます。 原則として、グリーティングを削除して他のコンポーネントに置き換えるまで、すべてのタイプのユーザーに対して異なるタイプのユーザーを構成できます。 これを行うには、新しいコンポーネントを作成し、サイト管理者がそれを構成する必要があります。つまり、アクセス可能なセットからルールを選択します。この場合、このコンポーネントが表示されます。

しかし、すべてが見た目ほど単純ではありません...

最初のライブリリースの約1年前に開発したサイトの最初のチャンネル。 ピーク時には、10人で構成される5つのチームが働き、サービスとの統合およびコンポーネントアーキテクチャの構築、それらの間の統合、サービスの変換などのためのフレームワークを直接作成しました。 さらに、非機能的なサービスとサイトパフォーマンスの最適化に従事していました。 2番目のチャネルは約6か月で更新され、コンポーネントの2次使用は約60〜70％に達しました。



現在、10人で構成される3つのチームがプロジェクトに取り組んでおり、ビジネス要件、更新、コンポーネントの改善の要望に応じて機能を完成させるとともに、新しいコンポーネントの作成中に発生するアーキテクチャの問題に取り組んでいます。



サイトアーキテクチャ自体はパッシブクラスタリングであり、現在、ユーザーの要求を処理する3つのアプリケーションサーバーがあります。 ただし、パフォーマンスの問題が発生した場合に、システムの水平スケーリングを簡単かつ迅速に開始できるように、すべてが構造化されています。 Vagrant / DockerおよびAmazon Cloudを介した展開スクリプトを使用して、仮想マシンを上げ、AEMをインストールし、サイトに最新のソースを展開して、アプリケーションのエコシステム全体に追加できます。



特にモバイルデバイスのパフォーマンスについては、Angularを使用したため、クライアントでのプロセッサの消費が大きい非生産的なアプリケーションに簡単に移行できました。 この場合、HTML構造の最適化、Angularのウォッチャー関数の数を減らすための単方向バインディングの使用、およびいくつかのAngularディレクティブの対応が役立ちました。



サイト自体のパフォーマンスを最適化するために、高レベルのデータキャッシュが使用されます。 ユーザーに表示されるコンテンツのほとんどは、Webサーバーが提供する静的な情報です。アプリケーションサーバーへの呼び出し回数を大幅に削減しました。 これは、ほとんどのプロジェクトに静的情報をキャッシュするディスパッチャがあるため、AEMを使用するためのベストプラクティスによるものです。 理想的には、アプリケーションサーバーへの要求は、サーバーまたはサイトのデータが変更された場合、または新しいコードがロールアウトされた場合にのみ到達する必要があります。



また、高いGoogleページスコア統計を達成するために多くの改善を行いました。 ブラウザキャッシュを最大限に活用するために、JS、CSSなどの連結、画像のスプライトへの結合、SVGアプローチ、フィンガープリンティング機能により、サイトへのリクエスト数を最適化しました。 もちろん、これは超自然的なものではありませんが、忘れてはなりません。

とにかく顧客はあなたの助けを必要とします

AEMのすべての利点にもかかわらず、いずれの場合でも、顧客は特定の方向に特に必要なコンポーネントの開発、またはユーザーの新しいセグメントの追加などのいくつかのエキゾチックなシナリオの説明の支援が必要です。

もちろん、技術的にはまだ開発のフィールドがあります。JavaScriptを無限に単純化したり、顧客が将来使用できる新しい高レベルの関数を作成したりなど、さまざまなことができます。



サイトの他のチャネル用の新しいコンポーネントの開発、アーキテクチャ上の問題の解決、コンポーネントの再設計、その他の興味深いタスクを待っています。 ただし、AEMの既存の経験のおかげで、残りのチャネルの更新は時間の問題です。 そして、このソリューションのおかげで、顧客に非常に多くの柔軟性を与えていることを実感できます。すでに行ったことに基づいて、顧客はレンガから新しいビジネスを構築できます。 そしてそれは素晴らしいことです。