Experience using Liferay Portal in eCommerce

Many of us have written shops of various kinds more than once. But large e-commerce projects in a rapidly growing and developing company have to be developed infrequently. Such decisions are subject to additional requirements, such as configurability, adaptability to changes, the ability to integrate into other systems, and more. Netcracker used the Liferay Portal framework to write such a solution. As a result, we got enough advantages, but it was not without problems.

Task

Netcracker , the company I work for, is developing integrated software solutions for global teleoperators 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 approaches to solving seemingly standard tasks in the industry.
If you try to summarize 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 telecom 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, and also allow them to be configured in accordance with the description. In addition, one of the most important functions of the site is the configured personal account of the user, through which you can manage the acquired services, change their configuration and, without contacting the call center, do whatever your heart desires. Also, an opportunity should be realized that allows in the future to easily expand and modify the site interface without introducing itself into the integration details, data acquisition and coding methods.
All data on services, their prices, purchase transactions and changes are provided by the Netcracker product line modules, 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 get the data, cache everything possible, display it on the site, design and launch the site beautifully.
But since we have many additional requirements, we have to think about non-functional use cases. For example, a customer needs:

1. Regularly hold promotions, make discounts, introduce new services.
2. Periodically change the design of pages, user interface elements. For example, urgently make a site for the New Year and Black Friday.
3. Be able to display content on the site that is provided by contractors.
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 - this is a portal solution that supports the JSR-168 and JSR-286 (portlet specification) specifications, which contains many different modules that allow building extensible, managed and configurable applications out of the box. Among other things, Liferay Portal (hereinafter Liferay) includes a full CMS, integration with social networks, forums, chats and more. Liferay allows you to build pages from cubes called portlets, which can be created by both the solution developers themselves and third-party companies using the JSR-286 specification.
Liferay is one of the most popular free solutions for building enterprise portals and shared portals. For example, the well-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 throwing the necessary blocks (portlets) on the pages, setting parameters and access / display rights for them.
In addition, Liferay offers a very good set of Out-of-The-Box modules such as CMS, integration with social networks, optimization for search engines, integration with Single Sign On systems and third-party analytic services.

Implementation Features

Thinking over tasks 1 and 2 (described above), we realized that it was 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 started using the Google Closure Templates template engine .
This engine makes it easy to use a once-written template both on the server and on the client. In addition, localization, internationalization, breakdown into subpatterns and much more are thought out very qualitatively. Most attracted to laconicism, avoiding logic in templates, getting rid of many types of standard errors (such as escaping, etc.). I also liked that templates are compiled entities, which can significantly increase performance both on the server and on the client.
We decided to make sure that the customer could always tweak the template for any portlet (page cube) at its discretion. The general view of the portal can be edited in the theme template.
For the convenience of development, a microframework 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, delayed rendering of them by the template on the client, receiving data , access to the portlet DOM container, and more. The ability to link the JS class responsible for the dynamics in this portlet and the portlet itself was also added.
Thanks to this, the developer does not think about the fact that the templates should be compiled and writes the usual code for it in Spring, HTML, JavaScript.

Result

Liferay Portal turned out to be a fairly stable portal. He was pleased with the initial focus on horizontal scaling, the presence of Java API's heap 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 switch from highly optimized page code and statics to its developer configuration, which is much easier to debug in. In general, it seemed that the platform was created by programmers for programmers!
Google Closure Templates met all expectations. Now this is my favorite among the template engines!
The ability to build pages for a site from cubes that are not directly connected to each other, but communicate only on the event bus, is really wonderful. The code is well structured, broken into logical parts. At the same time, you get additional advantages: the ability to use the same portlet with different appearance on different pages without a single line of code , the simplicity of changing the appearance of the page due to the easy (drag & drop) movement of blocks on the page, the independence of the entire page from the health of a particular portlet.

Problems and Solutions

The main problem that we encountered and which we still haven’t solved beautifully was the configuration of Liferay. The fact is that it stores almost everything that a site can be called a site: the content of the CMS, the settings of each portlet that are attached to the page, page themes, 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 must store and version this configuration. Well, in addition, during development, I would really like to be able to delay configuration changes. So far we see two ways to transfer the configuration to Liferay:

• The first way is the Staging environment, the essence of which is that two Liferay instances are installed: one is the change wizard, the second is production. At the first, you make all the changes, make sure that they work, and after that you click the [Apply] button. After that, all changes are miraculously transferred to the production server. But, unfortunately, this approach does not satisfy many of the requirements described above.
• The second way - Export / Import - would seem to be an ideal and correct thing, but even here there were some surprises. Export is carried out in a special LAR format, which is an ordinary zip with a bunch of XML. And the problem is that no logic is observed in these XML. Each type of configuration, each type of data, etc. is translated into XML in its own way ! Moreover, in this XML there is so much constantly changing and environment-dependent overhead information that their merge is simply impossible. So when importing the same configuration from two different servers, the result is different by 90%.

The Liferay configuration problem is resolved so far by simply storing the finished LAR file. It’s impossible to control it, but you can at least version the changes and roll back in minutes.
Particular difficulties are caused by what is considered a big plus in portlet technologies. 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, classloaders, sessions, requests, etc.. This leads to a bunch of problems both 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 (constant substitution of classloaders), either copying, or not copying request and session parameters from application to application and changing portlet code during deployment.
In general, Liferay prepared for us many adventures, but most of them were possible to solve due to the provided expansion points and the large community around the platform.

conclusions

Liferay's solution has not yet reached full-fledged 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 for 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 decisions as flexible as possible.

Despite all this, there is something to improve. In the near future we plan to do a study 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 comment, we will be grateful.

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