Experience of using Liferay Portal in eCommerce

Many of us have repeatedly written all sorts of shops. But large e-commerce projects in a rapidly growing and growing company have to be developed infrequently. These solutions are subject to additional requirements, such as configurability, adaptability to change, the possibility of embedding in other systems and so on. To write such a solution, Netcracker used the Liferay Portal framework. As a result, got enough advantages, but it was not without problems.

Task

The company Netcracker , in which I work, is developing integrated software solutions for global camera operators and telecom operators. The business of such companies is extremely dependent on the development of technologies, which, as you know, change very often, which greatly affects the approaches to the solution of seemingly standard tasks in the industry.
If you try to briefly formulate the task, it will sound like this: you need to create a corporate website (hereinafter referred to as the Site) of one of the largest foreign national telecommunication operators, covering about 10 million active subscribers.
The site should provide the ability to view the catalog of services provided, information about services and their availability in different regions with the ability to immediately purchase any of them, as well as allow them to be configured in accordance with the description. In addition, one of the most important functions of the site is a customized user account, through which you can manage the acquired services, change their configuration and do whatever your heart desires without contacting the call center. Also, the opportunity should be implemented that allows in the future to easily expand and modify the site interface, without integrating into the details of integrations, methods of data acquisition and coding.
All data about services, their prices, purchase transactions and changes are provided by modules of the product line Netcracker, built on the basis of the platform - Netcracker Framework. This data can be easily obtained through the REST API provided by these modules.
It remains only to receive data, cache everything possible, display on the site, arrange it beautifully and launch the site
But since we have many additional requirements, we have to think about non-functional usage scenarios. For example, the customer needs to:

1. Regularly carry out promotions, make discounts, introduce new services.
2. Periodically change the design of pages, user interface elements. For example, urgently arrange a website for the New Year and Black Friday.
3. To be able to display on the site content that contractors provide.
4. Integrate the cart into each page of the operator’s common portal.
5. To be able to add new services of existing types as well as new types of services without a single line of code.

Technology selection

Liferay Portal was chosen as the platform for creating the solution. It is a portal solution that supports the JSR-168 and JSR-286 specifications (portlet specification), which contains many different modules that allow you to build expandable, manageable and configurable applications out of the box. Among other things, Liferay Portal (hereinafter Liferay) includes a full CMS, integration with social networks, forums, chat rooms and more. Liferay allows you to build pages from cubes called portlets, which can be created either by solution developers themselves or by third-party companies using the JSR-286 specification.
Liferay is one of the most popular free solutions for building corporate portals and public access portals. For example, known to many Java-developers JUG.ru is built on it.
Thanks to the architecture offered by Liferay, the configuration without writing code will be reduced to paging the necessary blocks (portlets) on the page, setting parameters and access / display rights to them.
In addition, Liferay offers a very good set of modules of the Out-of-The-Box type CMS, integration with social networks, search engine optimization, integration with Single Sign On systems and third-party analytical services.

Features of the implementation

Considering tasks 1 and 2 (described above), we realized that it is necessary to enable the customer himself to directly influence the display of each portlet and the entire site as a whole. In addition, to offload the server and improve the perception of the site, I wanted to make many operations asynchronous and dynamic. To this end, the project began to use the template engine Google Closure Templates .
This engine allows you to easily use once written template both on the server and on the client. In addition, localization, internationalization, breakdown into subpatterns and much more are well thought out. Most of all attracted conciseness, avoiding the logic in the templates, getting rid of many types of standard errors (such as escaping, etc.). I also liked the fact that templates are compiled entities, which allows a serious increase in performance both on the server and on the client.
We decided to make sure that the customer could always correct the template for any portlet (page cube) at its discretion. The general view of the portal can be edited in the theme template.
For ease of development, a microform was written that allows you to write each portlet using Spring MVC and Google Closure Templates as a View, as well as a small JavaScript class that encapsulates in itself: all the logic of asynchronous access to portlets, deferring their drawing on the client, data retrieval , accessing the DOM portlet container and more. The ability to link the JS class responsible for the dynamics in this portlet and the portlet itself was also added.
Due to this, the developer does not think about the fact that templates should be compiled and writes the usual code for him in Spring, HTML, JavaScript.
')

Result

Liferay Portal was a fairly stable portal. We were pleased with its initial focus on horizontal scaling, the presence of a heap of Java API's and extension points, allowing you to change almost anything. Also, I was very pleased with a large number of configuration properties, the change of which allowed us to quickly move from highly optimized page code and statics to its developer configuration, in which it is much easier to debug. In general, the impression was created that the platform was created by programmers for programmers!
Google Closure Templates met absolutely all expectations. Now this is my favorite among template engines!
The ability to build pages for the site of cubes, which are not directly connected with each other, and communicate only via the event bus, is really beautiful. The code turns out well structured, broken into logical parts. At the same time, you get additional benefits: the ability to use the same portlet with different appearances on different pages without a single line of code , ease of changing the page appearance due to easy (drag & drop) moving blocks across the page, independence of the entire page from the performance of a specific portlet.

Problems and Solutions

The main problem that we encountered and which we have not yet solved beautifully, was the Liferay configuration. The fact is that it stores practically everything that allows a site to be called a site: the contents of the CMS, the settings of each portlet, the pages associated with the pages, the themes of the pages, the layouts and much more. Therefore, there is a serious need to somehow be able to transfer this configuration from one place to another. In addition, you need to store and version this configuration. Well, in addition to the development would very much like to be able to merge configuration changes. For now we see two ways to transfer the configuration to Liferay:

• The first way is the Staging environment. The essence of it is that two Liferay instances are set: one is the master of changes, the second is production. At the first, you make all the changes, make sure that they work, and then click the [Apply] button. After that, all changes are miraculously moved to the production server. But, unfortunately, this approach does not satisfy many of the requirements described above.
• The second way - Export / Import - it would seem, an ideal and correct thing, but even here it was not without surprises. Export is carried out in a special format LAR, which is a regular zipnik with a bunch of XML. And the problem is that there is no logic in these XML. Each type of configuration, each type of data and so on is translated into XML in its own way ! Moreover, in this XML, such an amount of constantly changing and dependent on the service information that their merge is simply impossible. So, when importing the same configuration from two different servers, the result is 90% different.

We solve the Liferay configuration problem for the time being just by storing the finished LAR file. It's impossible to merge it, but you can at least version the changes and roll back in minutes.
Especially difficult is the fact that portlet technology is considered a big plus. The fact is that Liferay itself is a separate Java web application. And all portlets should be designed as another separate web application. This means that they have different contexts, classesade, sessions, requests, and so on. This leads to a lot of problems when using Spring, and when trying to do some basic things that could be used in all portlets. Liferay also complicates this problem by adding black magic (the constant substitution of classifier), then copying, then not copying the parameters of the requests and sessions from the application to the application and changing the code of the portlets with the deployment.
In general, Liferay has prepared quite a few adventures for us, but most of them were possible to solve with the help of expansion points and a large community around the platform.

findings

The Liferay solution has not yet come to full production, but some conclusions can be drawn:

1. Liferay is a powerful tool for building both internal and mass portals.
2. Liferay allowed us to solve the tasks set before us without additional capital investments in the development of our “bicycle”.
3. Liferay is a system that allows you to make secure, loaded and feature-rich solutions as flexible as possible.

Despite all this, there is much to improve. In the near future we plan to do research in the wake of the experience gained, to find out if there are any other solutions of the same class that help solve the problem easier / more correctly. If there are options - please in the comments, we will be grateful.

Thank you all for reading the article to the end. I hope she was quite interesting.