Inside Adobe Experience Manager (AEM) 6.4: backend technology
As an Adobe Global Alliance Partner and Experience Cloud Partner of the Year 2018 EMEA, Netcentric have made it our mission to bring the latest AEM offerings to our clients. So much so that, when the need for a new Netcentric website arose, it simply seemed natural to use the latest available version of AEM at that time. This gave us the opportunity to explore the new AEM offering and test it, whilst building our own digital identity on top of it. We’ve already brought you a deep dive into the frontend technology of AEM 6.4. Now, this guide will deliver expert insights into the backend technology that underpins the Netcentric website.
Adobe Experience Manager 6.4 native
https://solutionpartners.adobe.com/home/news/2018/02/get_ready_for_aem_6_.html
Image from: https://solutionpartners.adobe.com/home/news/2018/02/get_ready_for_aem_6_.html
All the code of the Netcentric website is AEM 6.4 native, meaning that development was carried out from scratch in AEM 6.4. Consequently, nothing has been migrated from previous iterations.
As described in Adobe’s useful guide, a new file structure is recommended in order to take advantage of AEM 6.4 restructuring, and to prepare for the upgrade to AEM 6.5. Therefore, these details were taken into consideration during the development of Netcentric’s new site.
Adobe Experience Manager Core Components
As already described in our outline of the Core Components of AEM 6.3, Core Components is a set of reusable and production-ready components. They are structural elements designed to fast-track the development of your website, and naturally, we decided to include the latest version of them whilst developing our powerful new site.
These components were the foundation of our development, meaning that all customizations and extensions were made based on these components. This integration gave us the opportunity to evolve with the core components and to easily adapt to the new versions. Our main mantra was to integrate the AEM core components with as little customization as possible, thus enhancing maintainability and expanding applicability.
The following AEM Core Components were used for the Netcentric website: Form Button, Form Container, Form Options, Image, List, Navigation, Social Media Sharing, Text, Title, and Teaser.
Experience Fragments
Adobe introduced Experience Fragments to further facilitate content reuse. Experience Fragments are constructs made up of content and layout that live in AEM under Experience Fragments, not AEM Sites. Once created, they can be referenced in AEM Sites and included on pages, thus allowing authors to easily reuse and maintain content. Once the experience fragment is updated, the change is then propagated to all pages in which the respective experience fragment is referenced.
This behavior was requested for our footer, enabling us to provide the same experience in almost all of our pages. Some conditional logic was added to this experience fragment so a minimal footer is used in some cases. However, in this case, the author still edits just one experience fragment, which streamlines processes for authors and boosts content coherence everywhere.
Editable templates
Editable templates is a feature that allows the author to improve templates directly, without the need for new deployments. In our project, we explored this feature to provide a set of flexible templates for users. In several cases, authors were able to improve the template layout without requesting changes from the development team. Again, delivering power to the author since, after all, content is king.
The process inside
The development team took the core value of "exceed the highest standards" in all elements, with the newest client-side libraries used everywhere. Furthermore, the unit tests were developed using JUnit 5, Mockito 2 and the last version of AEM Mocks. In order to verify the quality of our unit tests, PIT test was used to verify whether changes to our code were detected by our unit tests. Indeed, this feature helped us to minimize bugs, or at least locate them as early as possible.
Our internal CI tool was configured to generate releases and deploy them to our production servers. This made it easier to generate new releases and enables our developers to improve code instead of using their time to generate the packages.
