eコマースでLiferayポータルを使用した経験

私たちの多くは、さまざまな種類のお店を何度も書いています。 しかし、急速に成長し、発展している会社の大規模なeコマースプロジェクトは、まれにしか開発する必要がありません。 このような決定には、構成可能性、変更への適応性、他のシステムへの統合機能など、追加の要件があります。 Netcrackerは、Liferayポータルフレームワークを使用してこのようなソリューションを作成しました。 その結果、十分な利点が得られましたが、問題がないわけではありませんでした。

挑戦する

私が勤務している会社のNetcrackerは、グローバルなテレオペレータおよびテレコムオペレータ向けの統合ソフトウェアソリューションを開発しています。 このような企業のビジネスは、ご存じのように頻繁に変化するテクノロジーの開発に大きく依存しており、業界の標準的なタスクを解決するアプローチに大きく影響します。

タスクを要約しようとすると、次のように聞こえます。約1,000万人のアクティブな加入者を対象とする、最大の外国通信通信事業者の1つの企業Webサイト（以下、Webサイトと呼びます）を作成する必要があります。

サイトは、提供されたサービスのカタログ、異なる地域でのサービスとその可用性に関する情報を表示する機能を提供し、それらのいずれかをすぐに購入し、説明に従って構成できるようにする必要があります。 さらに、サイトの最も重要な機能の1つは、取得したサービスを管理し、構成を変更し、コールセンターに連絡することなく、あなたが望むあらゆることを実行できるユーザーの構成済み個人アカウントです。 また、将来、統合の詳細、データ取得、およびコーディング方法に煩わされることなく、サイトインターフェイスを簡単に拡張および変更できる機会を実現する必要があります。

サービス、価格、購入取引、および変更に関するすべてのデータは、プラットフォーム-Netcracker Frameworkに基づいて構築されたNetcracker製品ラインモジュールによって提供されます。 このデータは、これらのモジュールが提供するREST APIを介して簡単に取得できます。

データを取得し、可能な限りすべてをキャッシュし、サイトに表示し、サイトを美しくデザインして起動するだけです。

しかし、追加の要件が多数あるため、機能しないユースケースについて考える必要があります。 たとえば、顧客には次のものが必要です。

1. 定期的にプロモーションを開催し、割引を行い、新しいサービスを導入します。
2. ページ、ユーザーインターフェイス要素のデザインを定期的に変更します。 たとえば、新年とブラックフライデーのサイトを早急に設計します。
3. 請負業者が提供するサイトにコンテンツを表示できるようにします。
4. オペレーターの共通ポータルの各ページにカートを統合します。
5. 1行のコードなしで、既存のタイプの新しいサービスと新しいタイプのサービスを追加できるようにするため。

技術の選択

Liferayポータルは、ソリューションを作成するためのプラットフォームとして選択されました-これは、拡張可能で、管理され、構成可能なアプリケーションをすぐに構築できるさまざまなモジュールを含む、 JSR-168およびJSR-286 （ポートレット仕様）仕様をサポートするポータルソリューションです。 とりわけ、Liferay Portal（以降Liferay）には、完全なCMS、ソーシャルネットワークとの統合、フォーラム、チャットなどが含まれています。 Liferayを使用すると、ポートレットと呼ばれるキューブからページを構築できます。これは、ソリューション開発者自身とJSR-286仕様を使用するサードパーティ企業の両方で作成できます。

Liferayは、エンタープライズポータルおよび共有ポータルを構築するための最も人気のある無料ソリューションの1つです。 たとえば、多くのJava開発者によく知られているJUG.ruは 、 その上に構築されています。

Liferayが提供するアーキテクチャのおかげで、コードを記述しない構成は、必要なブロック（ポートレット）をページにスローし、パラメーターを設定し、それらのアクセス権/表示権に限定されます。

さらに、Liferayは、CMS、ソーシャルネットワークとの統合、検索エンジンの最適化、シングルサインオンシステムとサードパーティの分析サービスとの統合など、すぐに使用できる非常に優れたモジュールセットを提供します。

実装機能

タスク1および2（上記）を検討すると、顧客自身が各ポートレットおよびサイト全体の表示に直接影響を与えることができることが必要であることがわかりました。 さらに、サーバーをオフロードしてサイトの認識を向上させるために、多くの操作を非同期で動的にしたかったのです。 このため、プロジェクトはGoogle Closure Templatesテンプレートエンジンの使用を開始しました。

このエンジンにより、一度作成したテンプレートをサーバーとクライアントの両方で簡単に使用できます。 さらに、ローカリゼーション、国際化、サブパターンへの分解などが非常に定性的に考えられています。 最も簡潔で、テンプレートのロジックを避け、多くのタイプの標準エラー（エスケープなど）を取り除きます。 また、テンプレートはコンパイルされたエンティティであり、サーバーとクライアントの両方でパフォーマンスを大幅に向上できることも気に入っています。

顧客がその裁量でポートレット（ページキューブ）のテンプレートを常に微調整できることを確認することにしました。 ポータルの一般的なビューは、テーマテンプレートで編集できます。

開発の利便性のために、Spring MVCおよびGoogle Closure Templatesをビューとして使用して各ポートレットを作成できるマイクロフレームワークと、それ自体をカプセル化する小さなJavaScriptクラスを作成できるようにしました。 、ポートレットのDOMコンテナへのアクセスなど。 このポートレットおよびポートレット自体のダイナミクスを担当するJSクラスをバインドする機能も追加されました。

これにより、開発者はテンプレートをコンパイルする必要があるという事実を考えず、Spring、HTML、JavaScriptで通常のコードを記述します。

結果

Liferayポータルは、かなり安定したポータルであることが判明しました。 彼は、水平スケーリング、Java APIと拡張ポイントのヒープの存在に最初から焦点を当てており、ほとんど何でも変更できることに満足していました。 また、多数の構成プロパティに非常に満足しており、その変更により、高度に最適化されたページコードと静的から、デバッグがはるかに簡単な開発者構成にすばやく切り替えることができました。 一般的に、プラットフォームはプログラマーのためにプログラマーのために作成されたようです！

Google Closure Templatesはすべての期待に応えました。 今、これはテンプレートエンジンの中で私のお気に入りです！

互いに直接接続されていないが、イベントバスを介してのみ通信するキューブからサイトのページを構築する機能は、本当に素晴らしいです。 コードは適切に構造化されており、論理部分に分割されています。 同時に、追加の利点があります： コードの単一行なしで異なるページで異なる外観の同じポートレットを使用できること、ページ上のブロックの簡単な（ドラッグアンドドロップ）移動によるページの外観の変更の単純さ、特定のポートレットの健全性からのページ全体の独立性。

問題と解決策

私たちが直面した主な問題はまだ美しく解決されていませんが、Liferayの構成です。 実際には、サイトをサイトと呼ぶことができるほとんどすべてを保存します。CMSのコンテンツ、ページにアタッチされる各ポートレットの設定、ページテーマ、レイアウトなどです。 したがって、この構成をある場所から別の場所に転送できるようにする必要があります。 さらに、この構成を保存してバージョン管理する必要があります。 さらに、開発中に、構成の変更を遅らせたいと思っています。 これまでのところ、設定をLiferayに転送する2つの方法があります。

• 最初の方法はステージング環境であり、その本質は2つのLiferayインスタンスがインストールされていることです。1つは変更ウィザードで、2つ目は本番です。 最初に、すべての変更を行い、それらが機能することを確認してから、[適用]ボタンをクリックします。 その後、すべての変更が本番サーバーに奇跡的に転送されます。 しかし、残念ながら、このアプローチは上記の要件の多くを満たしていません。
• 2番目の方法-エクスポート/インポート-は理想的で正しいことのように思えますが、ここでも驚きがありました。 エクスポートは、特別なLAR形式で実行されます。これは、XMLを束ねた通常のzipです。 そして問題は、これらのXMLでロジックが観察されないことです。 各タイプの構成、各タイプのデータなどは、独自の方法で XML に変換されます！ さらに、このXMLでは、絶えず変化する環境依存のオーバーヘッド情報が非常に多いため、それらのマージは単に不可能です。 したがって、2つの異なるサーバーから同じ構成をインポートすると、結果は90％異なります。

Liferay構成の問題は、これまでのところ、完成したLARファイルを保存するだけで解決されています。 制御することはできませんが、少なくとも変更をバージョン管理して数分でロールバックできます。

特定の困難は、ポートレットテクノロジーで大きなプラスと考えられるものによって引き起こされます。 実際、Liferay自体は別個のJava Webアプリケーションです。 また、すべてのポートレットは、別の別個のWebアプリケーションとして設計する必要があります。 これは、 異なるコンテキスト、クラスローダー、セッション、リクエストなどがあることを意味します。 これは、Springを使用する場合と、すべてのポートレットで使用できる基本的なことを実行しようとする場合の両方で、多くの問題につながります。 Liferayはまた、ブラックマジック（クラスローダーの定数置換）を追加することにより、この問題を複雑にします。アプリケーションからアプリケーションにリクエストおよびセッションパラメータをコピーするかしないか、およびデプロイ中にポートレットコードを変更します。

一般に、Liferayは多くの冒険を準備しましたが、提供された拡張ポイントとプラットフォーム周辺の大規模なコミュニティにより、それらのほとんどは解決することができました。

結論

Liferayのソリューションはまだ完全な生産には至っていませんが、いくつかの結論を引き出すことができます。

1. Liferayは、内部ポータルとマスポータルの両方を構築するための強力なツールです。
2. Liferayにより、「自転車」の開発に追加の設備投資をすることなく、タスクを解決できました。
3. Liferayは、安全でロードされた機能豊富なソリューションを可能な限り柔軟に作成できるシステムです。

これらすべてにもかかわらず、改善すべきことがあります。 近い将来、同じクラスの他のソリューションが問題をより簡単に/より正確に解決するのに役立つかどうかを知るために、得られた経験をきっかけに調査を行う予定です。 オプションがある場合-コメントしてください、私たちは感謝します。



最後まで記事を読んでくれてありがとう。 彼女が十分に面白いことを願っています。