Multichannel site upgrade. How to make your life easier
Modernization of any site is like swimming in unfamiliar waters - you never know what kind of underwater reefs you come across. And what if your site is a big, tangled system consisting of multiple channels, each of which is also built on its own technology stack? You can not only choose the wrong course, but also drown, trying to understand all the features of the functioning of the customers site.
In today's article, we would like to share the experience of successful modernization with the help of Adobe Experience Manager and tell you how to apply this solution to a multi-channel site.
Read more
')
Modernization is not the most modern, but fairly simple site - an interesting task, but, as they say, without the "highlight". Another thing is when a customer's site represents more than fifty different businesses, each of which uses its own set of technologies (hybris, .NET, Java, etc.). Combining all of the above in one perfectly working system and qualitatively update each channel of the site is a kind of challenge, but nothing is impossible.
In addition to the above points, I would like to note the fact that each channel of the site we are updating lived its own life. Such "independence" led to the fact that making even the simplest changes required the participation of developers. A simple update, such as simultaneously loading a new logo for all channels, became quite a complicated procedure in terms of coordinating builds and deployments at the time of testing. The difficulty of adding new businesses and supporting existing ones, as well as the lack of support for mobile devices and tablets (which is quite critical nowadays) and problems with localization caused the customer to contact us to optimize the site.
This solution has the features that are ideally suited for optimizing a multi-channel site. First of all, this is a high level of reuse of basic components and sections (both the back-end and the front-end), which in our case is extremely important, since they can be optimized for new channels, refining the missing functionality, and thereby reducing the time and effort. The second point is the support of internationalization and localization out of the box, which greatly simplifies development, because customers have plans to expand their business to other countries. AEM is also a content management and experience management system that has great flexibility in managing what we see on the site. Among other things, this is content editing: the ability to split functionality into modules and manage them without involving programmers and writing code, creating back-end logic using OSGi technology, scaling and personalizing content.
As is already clear from the text above, we took the Adobe Experience Manager technology as a basis due to its capabilities and convenience for administrators. Of course, the use of this technology alone was not enough. Based on Bootstrap, we reworked the static site template, adding the back-end part and business logic (adaptive layout appeared, including for mobile devices, HTML 5 was used, in general, all the buns inherent in modern sites were added). We also improved the functionality and optimized performance for different types of devices, added additional architectural solutions for the scalability of the application through the addition of cloud services.
Since many of the customer’s business lines are similar, it was decided to create components for reuse. Why every time to develop a new component for another channel, if in fact it is the same, just configured differently (different text or method of sending data to the service)? For various business cases, we set up basic and specific options for components, which simplified their use in similar cases. Thanks to this solution, the addition of new functionality and the integration of the service have become much more transparent. Of course, small updates on the back-end are necessary to teach the service to understand the new field, but the front-end itself has become much easier. Now, in order to add new functionality, you need to go through the editor, perform the necessary manipulations on the configuration of the component depending on its purpose and the results of smoke testing, and publish the page.
The difficulty was not only to create reusable components, but also to develop a framework that allows you to add all these components to a page and implement a certain logic of interaction between them. For example, on one of the site’s channels we needed to set up the following logic: when choosing different types of residential property, the user should be asked certain types of questions. That is, if the user chooses that he lives in an apartment building, the question should be asked on which floor he lives. Therefore, if he lives in a private house, then such a question is irrelevant to him.
For high-quality data processing, we needed to perform integration between the components, including setting up checking answers: for example, if the user chose that he was born in 1985, he cannot own the property for more than 40 years.
How did we do it? To implement this functionality, the interaction between components and save and send to the service, we integrated the capabilities of Adobe Experience Manager and Angular.js. For example, to control the display logic of each component used in the AEM, there is a field in the configuration called visibility. This field determines whether the component will be visible to users or not. We have to admit that the field is not the most convenient to use, but thanks to it you can use not pure JavaScript to write some functions, but integrate the component into the Angular eco-system. An example here is the expression user.answers.dateOfBirth> 01-01-1970, which performs validation by date of birth, which is substituted into the ng-if directive that wraps the specified component. Due to the presence of two-way binding in Angular, making changes to any field does not go unnoticed, since they are all integrated into a single whole. After making changes, a recalculation occurs, whether we should now show this field or not.
Another interesting solution that we have applied is to separate the data storage scheme on the front-end from the sending scheme on the back-end. Since the customer’s site largely consists of forms to fill out, we made sure that the user's responses are stored in local storage (HTML5 functionality) in JSON format. Next, there is a separation of data intended for the front-end and back-end, and sending the latter to the AEM for subsequent transformation. The conversion of incoming data into the service scheme occurs at the level of integration of the front-end part with REST services, which are engaged in the search for suitable services for site users. In the same way, we perform data conversion in the opposite direction: if the user is logged in and wants to select something from the already filled data, then the data provided by the REST service is transformed into the data format used on the front-end. To achieve this, we each integration with the service (for example, sending data to a service that searches for the most suitable products in the database), described in the appropriate format and stored in the AEM repository as structural nodes.
AEM is good because it provides excellent opportunities for personalizing content. In our case, we used the module that comes out of the box with the framework, optimized it for ourselves, creating additional user segments to the existing ones. What was the result? The main page of the channel has become personalized, has a greeting and displays the history of user requests. In case the user leaves the account, the page will still remember the username, but will offer to login. If the user insists that the system is wrong, and it is not at all he / she, they will be asked to use the site as an anonymous user, and in this case completely different content will be shown. In principle, all types of users can be configured with different content, up to the deletion of the greeting and its replacement with some other component. To do this, you need to create a new component, and the site administrators to configure it, that is, select rules from a previously available set, in which case this component should be displayed.
We developed the first channel of the site about a year before the first live release. Five teams of ten people worked at the peak, who wrote directly the framework for integration with services and for building component architecture, integration between them, for transforming services, etc. plus engaged in non-functional services and site performance optimization. The second channel managed to be renewed in about six months, and the secondary use of the components was about 60-70%, which is a lot.
Now the project has three teams of ten people each, which are finalizing the functionality in accordance with business requirements, updates, suggestions for improving components, and also working on architectural problems arising in the course of creating new components.
The site architecture itself is a passive clustering, and at the moment we have three application servers that serve to process user requests. However, everything is built in such a way that in case of any performance problems, we can easily and quickly start scaling the system quickly and easily. Using deployment scripts, through Vagrant / Docker and Amazon Cloud, we can raise a virtual machine, install AEM and deploy the latest sources of our site on it, adding it to the entire eco-system of the application.
As for performance, especially on mobile devices, since we used Angular, it was easy to go into an unproductive application with a large processor consumption on the client. In this case, we were helped by the optimization of the HTML structure, the use of one-way binding to reduce the number of watcher functions on Angular, and the correspondence of some Angular directives.
To optimize the performance of the site itself, a high level of data caching is used. Most of the content that users see is static information provided by the web server - we have significantly reduced the number of calls to the application server. This is due to the best practices of working with AEM, since in most projects there is a dispatcher, which serves to cache static information. Ideally, a request to the application server should only reach if the data on the server or site has changed or a new code has been rolled into it.
We also made a lot of improvements to achieve high Google page score statistics. To maximize the use of the browser cache, we optimized the number of requests to the site through the concatenation of JS, CSS, etc., combining images into sprites, SVG-approaches, fingerprinting-functionality. This, of course, is not something supernatural, but you should not forget about it either.
Despite all the advantages of AEM, customers in any case need your help in developing components that are necessary specifically for a particular area, or describing some exotic scenarios like adding a new user segment, etc.
Of course, technically there is still a field for development: you can infinitely simplify JavaScript, create new high-level functions that customers can use in the future, and much more.
We are still awaiting the development of new components for other channels of the site, the solution of architectural problems, the redesign of components and other interesting problems. However, thanks to the existing experience with the AEM, updating the remaining channels is a matter of time. And the more pleasant it is to realize that thanks to this solution we give quite a lot of flexibility to our customers - based on what we have already done, they can, like from bricks, build new businesses. And this is great.
In today's article, we would like to share the experience of successful modernization with the help of Adobe Experience Manager and tell you how to apply this solution to a multi-channel site.
Read more
')
Lyrical digression about the Adobe Experience Manager: what it is and why you need it
Adobe Experience Manager , previously hiding under the names CQ5, Day CQ5 and Adobe CQ5, is a web content management system designed to create, edit, manage and optimize websites through various digital channels. AEM is platform independent and runs on a Java server. Allows you to create any number of web pages / sites through the use of reusable components and templates.
Modernization is not the most modern, but fairly simple site - an interesting task, but, as they say, without the "highlight". Another thing is when a customer's site represents more than fifty different businesses, each of which uses its own set of technologies (hybris, .NET, Java, etc.). Combining all of the above in one perfectly working system and qualitatively update each channel of the site is a kind of challenge, but nothing is impossible.
In addition to the above points, I would like to note the fact that each channel of the site we are updating lived its own life. Such "independence" led to the fact that making even the simplest changes required the participation of developers. A simple update, such as simultaneously loading a new logo for all channels, became quite a complicated procedure in terms of coordinating builds and deployments at the time of testing. The difficulty of adding new businesses and supporting existing ones, as well as the lack of support for mobile devices and tablets (which is quite critical nowadays) and problems with localization caused the customer to contact us to optimize the site.
Why Adobe Experience Manager?
This solution has the features that are ideally suited for optimizing a multi-channel site. First of all, this is a high level of reuse of basic components and sections (both the back-end and the front-end), which in our case is extremely important, since they can be optimized for new channels, refining the missing functionality, and thereby reducing the time and effort. The second point is the support of internationalization and localization out of the box, which greatly simplifies development, because customers have plans to expand their business to other countries. AEM is also a content management and experience management system that has great flexibility in managing what we see on the site. Among other things, this is content editing: the ability to split functionality into modules and manage them without involving programmers and writing code, creating back-end logic using OSGi technology, scaling and personalizing content.
Modernization: what was used, what was done and why
As is already clear from the text above, we took the Adobe Experience Manager technology as a basis due to its capabilities and convenience for administrators. Of course, the use of this technology alone was not enough. Based on Bootstrap, we reworked the static site template, adding the back-end part and business logic (adaptive layout appeared, including for mobile devices, HTML 5 was used, in general, all the buns inherent in modern sites were added). We also improved the functionality and optimized performance for different types of devices, added additional architectural solutions for the scalability of the application through the addition of cloud services.
Since many of the customer’s business lines are similar, it was decided to create components for reuse. Why every time to develop a new component for another channel, if in fact it is the same, just configured differently (different text or method of sending data to the service)? For various business cases, we set up basic and specific options for components, which simplified their use in similar cases. Thanks to this solution, the addition of new functionality and the integration of the service have become much more transparent. Of course, small updates on the back-end are necessary to teach the service to understand the new field, but the front-end itself has become much easier. Now, in order to add new functionality, you need to go through the editor, perform the necessary manipulations on the configuration of the component depending on its purpose and the results of smoke testing, and publish the page.
The difficulty was not only to create reusable components, but also to develop a framework that allows you to add all these components to a page and implement a certain logic of interaction between them. For example, on one of the site’s channels we needed to set up the following logic: when choosing different types of residential property, the user should be asked certain types of questions. That is, if the user chooses that he lives in an apartment building, the question should be asked on which floor he lives. Therefore, if he lives in a private house, then such a question is irrelevant to him.
For high-quality data processing, we needed to perform integration between the components, including setting up checking answers: for example, if the user chose that he was born in 1985, he cannot own the property for more than 40 years.
How did we do it? To implement this functionality, the interaction between components and save and send to the service, we integrated the capabilities of Adobe Experience Manager and Angular.js. For example, to control the display logic of each component used in the AEM, there is a field in the configuration called visibility. This field determines whether the component will be visible to users or not. We have to admit that the field is not the most convenient to use, but thanks to it you can use not pure JavaScript to write some functions, but integrate the component into the Angular eco-system. An example here is the expression user.answers.dateOfBirth> 01-01-1970, which performs validation by date of birth, which is substituted into the ng-if directive that wraps the specified component. Due to the presence of two-way binding in Angular, making changes to any field does not go unnoticed, since they are all integrated into a single whole. After making changes, a recalculation occurs, whether we should now show this field or not.
What else interesting was used?
Another interesting solution that we have applied is to separate the data storage scheme on the front-end from the sending scheme on the back-end. Since the customer’s site largely consists of forms to fill out, we made sure that the user's responses are stored in local storage (HTML5 functionality) in JSON format. Next, there is a separation of data intended for the front-end and back-end, and sending the latter to the AEM for subsequent transformation. The conversion of incoming data into the service scheme occurs at the level of integration of the front-end part with REST services, which are engaged in the search for suitable services for site users. In the same way, we perform data conversion in the opposite direction: if the user is logged in and wants to select something from the already filled data, then the data provided by the REST service is transformed into the data format used on the front-end. To achieve this, we each integration with the service (for example, sending data to a service that searches for the most suitable products in the database), described in the appropriate format and stored in the AEM repository as structural nodes.
Description of the transformation in the form of nodes in the repository
We take the output JSON, which will be used to send to the service, and describe it in the same format in which the outgoing JSON should be, i.e. The node structure in the repository repeats the structure of the JSON document. Each node can simply be using one of the values from the incoming JSON. In the case of some more complex logic, we can use server-side JS to transform input JSON into output. For example, we know that in the JS-file, which is located under the node, there is a function transform, which should return the output data. If the required field is not empty and defined, then we return it. If it is empty, then we return a predetermined value - one. This is an example of a simple data conversion from one format to another using JavaScript. Execution of scripts that lie in the repository and describe the transformation of input data on the weekend, is performed by the Jh-engine Rhino, completely written in Java.
Personalization options
AEM is good because it provides excellent opportunities for personalizing content. In our case, we used the module that comes out of the box with the framework, optimized it for ourselves, creating additional user segments to the existing ones. What was the result? The main page of the channel has become personalized, has a greeting and displays the history of user requests. In case the user leaves the account, the page will still remember the username, but will offer to login. If the user insists that the system is wrong, and it is not at all he / she, they will be asked to use the site as an anonymous user, and in this case completely different content will be shown. In principle, all types of users can be configured with different content, up to the deletion of the greeting and its replacement with some other component. To do this, you need to create a new component, and the site administrators to configure it, that is, select rules from a previously available set, in which case this component should be displayed.
However, not everything is as simple as it looks ...
We developed the first channel of the site about a year before the first live release. Five teams of ten people worked at the peak, who wrote directly the framework for integration with services and for building component architecture, integration between them, for transforming services, etc. plus engaged in non-functional services and site performance optimization. The second channel managed to be renewed in about six months, and the secondary use of the components was about 60-70%, which is a lot.
Now the project has three teams of ten people each, which are finalizing the functionality in accordance with business requirements, updates, suggestions for improving components, and also working on architectural problems arising in the course of creating new components.
The site architecture itself is a passive clustering, and at the moment we have three application servers that serve to process user requests. However, everything is built in such a way that in case of any performance problems, we can easily and quickly start scaling the system quickly and easily. Using deployment scripts, through Vagrant / Docker and Amazon Cloud, we can raise a virtual machine, install AEM and deploy the latest sources of our site on it, adding it to the entire eco-system of the application.
As for performance, especially on mobile devices, since we used Angular, it was easy to go into an unproductive application with a large processor consumption on the client. In this case, we were helped by the optimization of the HTML structure, the use of one-way binding to reduce the number of watcher functions on Angular, and the correspondence of some Angular directives.
To optimize the performance of the site itself, a high level of data caching is used. Most of the content that users see is static information provided by the web server - we have significantly reduced the number of calls to the application server. This is due to the best practices of working with AEM, since in most projects there is a dispatcher, which serves to cache static information. Ideally, a request to the application server should only reach if the data on the server or site has changed or a new code has been rolled into it.
We also made a lot of improvements to achieve high Google page score statistics. To maximize the use of the browser cache, we optimized the number of requests to the site through the concatenation of JS, CSS, etc., combining images into sprites, SVG-approaches, fingerprinting-functionality. This, of course, is not something supernatural, but you should not forget about it either.
Customers need your help anyway.
Despite all the advantages of AEM, customers in any case need your help in developing components that are necessary specifically for a particular area, or describing some exotic scenarios like adding a new user segment, etc.
Of course, technically there is still a field for development: you can infinitely simplify JavaScript, create new high-level functions that customers can use in the future, and much more.
We are still awaiting the development of new components for other channels of the site, the solution of architectural problems, the redesign of components and other interesting problems. However, thanks to the existing experience with the AEM, updating the remaining channels is a matter of time. And the more pleasant it is to realize that thanks to this solution we give quite a lot of flexibility to our customers - based on what we have already done, they can, like from bricks, build new businesses. And this is great.
Source: https://habr.com/ru/post/277041/
All Articles