Adobe Experience Manager’s latest release became generally available on the 26th of April 2017 and being Adobe Partners we got the opportunity to try it out hot off the press. It’s a minor release but introduces some new key features that go a long way to make Adobe Experience Manager a more enjoyable product to use. Not only from an authoring standpoint but also for developers. Here’s some of the great things about 6.3 as well as the “not so great”.

The Good

Online Revision Cleanup Support

This new release ships with a brand new Tar file format: Oak Segment Tar. It claims to perform better than the previous TarMK format and also fully supports online revision cleanups. This last point should be music to the ears of anyone who has worked on cloud automation with AEM. There will no longer be a need to shutdown an instance to perform a repository compaction and it is now scheduled to run frequently as part of the maintenance tasks.

It’s worth noting that AEM 6.3 does not support the previous TarMK format, which means a repository migration is necessary. Thankfully, Adobe claims to have made the upgrade process more resilient.

Livefyre Integration

Adobe acquired Livefyre back in May 2016 and has now integrated it within Adobe Experience Manager as a set of components along with a user-generated content ingestion & moderation console. Once a Livefyre cloud service configuration is setup, it allows content authors to add components (located under “/libs/social/integrations/livefyre/components“) on a page to surface user generated content from social media like Twitter and Instagram. The combination of traditional branded experiences and social media content will prove to be an effective way to drive engagement with customers. The use of Livefyre does require a separate Assets and Livefyre license but doesn’t require a Communities license.

Authoring Improvements

There have been a few minor improvements to the Page Editor like the addition of the component title  (the “jcr:title” property) on the bottom right hand side of a component when hovering and clicking on it. It’s a small change but makes it really easy to identify the component being used.

component-title

Another improvement that also makes it easier to identify components on a large page is the new Content Tree available from the side rail in Edit mode.

Content Fragments: Summarise & Sync

The Content Fragments introduced in AEM 6.2 got some love in this release too with the introduction of the “Summarise text” and “Sync with master” features. The Summarise feature uses NLP to read through the sentences of an existing fragment variation and identifies the sentences that can be removed. A very handy comparison tool is presented to users once the analysis is complete allowing content authors to select/de-select sentences to remove.

fragment-summarize

The second feature is a Sync that allows fragment variations to be sync’d with the master variation in case changes have been made to it. It’s worth pointing out that this is a one-way sync, which means variations can only sync with master and not the other way around. This sync also needs to be performed manually for each variation. Before the sync is completed users are presented with a comparison but unlike the Summarise comparison, no changes can be made in this instance.

fragment-sync

These improvements to manage reusable content will incentivize companies to think of content as independent of the delivery channel and push the idea of content as a service even more. That brings us to the next improvement…

Sling Model Exporter

Traditionally, Sling models were used to provide an abstraction of a resource or request, providing HTL scripts with the required data to produce HTML. Since Sling Models version 1.3.0, an Exporter framework is included which allows models to be serialised to JSON format (powered by Jackson) and automatically registered against a resource type. The Jackson Exporter is quite configurable (i.e. MapperFeature, SerializationFeature); However it merely goes through the model’s getters to build a JSON rendition.

To attach the exporter framework to a Sling model, define a resourceType using the @Model annotation and use the @Exporter annotation to specify the Jackson exporter along with the Sling extension (and optionally the selectors). It’s also possible to make use of Jackson annotations to alter the JSON representation of the model.

If the Exporter framework is to become the norm for driving content as a service, I wonder what the future holds for the Siren+JSON API that was introduced in AEM 6.1. It was my understanding this API was created specifically for delivering content from AEM to third parties; However, it looks as though the Exporter framework is more flexible by providing developers with full control of what/how content is delivered.

The Not So Good

LiveCopies Overview

I was excited to hear that with AEM 6.3, the Blueprint Control Centre was being replaced by a brand new Touch UI based LiveCopies Overview console. Unfortunately, I found the new console to be quite difficult to use and makes it harder to find out the status of a LiveCopy. The old Blueprint Control Centre used a tree view on the left hand side that I think is a lot more intuitive and also didn’t require a full page reload to drill down into child pages.

Here’s a side by side comparison – you be the judge:

Javascript Minification

With AEM 6.3, a lot of libraries got an update: the underlying Jetty servlet engine, Sling, Oak, etc. However, AEM 6.3 is still making use of the YUI compressor by default – a project that is no longer under active development (latest release was in May 2013). The more recent Google Closure compiler is in fact bundled with AEM but will only compress client libraries that contain the jsProcessor[]=min:gcc property.

Sass Support (or lack thereof)

Adobe seems reluctant to add support for the Sass CSS pre-processor despite the front-end community favouring Sass (if Google trends for those keywords is anything to go by). What bewilders me is it’s a feature that is so easy to develop and I feel would benefit a lot of development teams working with Sass-based style guides. Shameless plug: I developed a Sass compiler for AEM that adds native support for compilation of “.scss” files.

Bonus

Admin Password Prompt

On initial start up of the 6.3 Quickstart, users are prompted to set the default admin password to avoid running AEM with the default admin password. This is great for hardening the platform but can be annoying when working with automation suites. The good news is it’s possible to prevent this prompt from appearing by using the nointeractive flag like so:

java -jar aem-6.3-author-p4502.jar -nointeractive

The instance will startup normally with the default “admin” password.

Conclusion

So far I’m impressed with AEM 6.3 and I like the direction Adobe is going with the idea of Fluid content adapting to it’s delivery channel. AEM is laying a strong foundation with it’s updated repository and coupled with it’s capabilities to curate content from social media with Livefyre and the updated management of content fragment, it will enable content authors to create some highly engaging experiences.

Written by Michael Leroy

Consultant at Shine Solutions and Adobe Certified AEM Developer

3 comments

  1. Hi Michael – Nice post. Looking forward to trying out 6.3 soon. I was interested in a comment you made above regarding using automation suites… We are looking for new ways to automate AEM delivery, testing, etc. We have a few things in place but I wanted to know what automation you’ve put in place or have seen in practice. It would be awesome to build out some best practices there.

  2. Thanks for your comment Robert!

    Assuming you’re referring to infrastructure automation, some of our Shiners have been hard at work developing an AEM automation solution that we are actively rolling out in some of Australia’s largest companies. The AEM automation efforts at Shine Solutions have been open sourced and are available at https://github.com/shinesolutions. The repositories you may find interesting are “aem-aws-stack-builder”, “aem-aws-stack-provisioner”, “aem-orchestrator”, “puppet-aem-resources” and “packer-aem”. Feel free to checkout the code and use it as you see fit 🙂

    If you’re referring to testing automation, in my opinion the approach that works best is to write functional tests (i.e. using Cucumber/Geb) against some test content. That way the tests are checking the component behavior and prevents QA teams having to madly update their test cases as soon as content changes.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s