AEM 6.3: First Impressions

AEM 6.3: First Impressions

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.


@Model(
adaptables = Resource.class,
resourceType = "acme/components/sling-model"
)
@Exporter(name = "jackson", extensions = "json")
public class MyModel {
@Inject @Named("jcr:title")
private String title;
@Inject @Named("jcr:created")
private Calendar createdAt;
public String getTitle() {
return title;
}
@JsonIgnore
public Calendar getCreatedAt() {
return createdAt;
}
}

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.

mickjleroy@gmail.com

Consultant at Shine Solutions and Adobe Certified AEM Lead Developer

9 Comments
  • Robert Kelly
    Posted at 09:31h, 04 May Reply

    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.

  • Michael Leroy
    Posted at 11:11h, 04 May Reply

    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.

    • Robert Kelly
      Posted at 22:58h, 24 May Reply

      Great points there. As far as the Infra automation, we’re using both Chef for the enterprise approach and DockerCompose internally to test these waters. We’re not provisioning to AWS (yet). I’m interested in your approach using Packer, Puppet to see where we’re aligned.
      We’re also focusing on test automation, I agree about the test content needing to be present. Today we’re working on a few different approaches. We are building test content pages using existing established templates and adding new components to test their interactions. There are Cucumber/Selenium tests in place for that content on the Author, Publisher, and dispatcher instances. Where we’re having trouble is the Authoring testing a bit. Our teams haven’t nailed an approach down that can sufficiently test the act of authoring, using dialogs, etc. Have you moved in that direction yet?

  • Pingback:TEL monthly newsletter – April 2017 – Shine Solutions Group
    Posted at 15:15h, 08 May Reply

    […] AEM gun, Michael Leroy, blogged about his first impressions of AEM 6.3, calling out the good and not so good things about […]

  • Eldad Askof
    Posted at 22:00h, 12 June Reply

    Hi,

    We are looking in upgrading AEM 6.1 to 6.3 but the cost estimations that are coming from our dev team are crazy. have you encountered a lot of work when doing such upgrades?

    • Michael Leroy
      Posted at 23:59h, 12 June Reply

      Hi Eldad,

      The amount of work required to complete an upgrade can vary wildly depending on the following:
      1) the size and complexity of the code base
      2) the number of customizations made to the AEM authoring UI
      3) adherence to best practices regarding code/content

      If you are looking to shave off some time/cost, a good place to start may be to look closely at the estimation breakdown and identify tasks that are “must haves” and tasks that are “nice to have”.

  • Eldad Askof
    Posted at 11:04h, 13 June Reply

    Totally agree and this is what we are looking at but some of the items seem to me as mandatory and i’m wondering how these were resolved elsewhere.
    For example the fact that OSGI configuration is now encrypted requires to build all properties files again or Authoring framework changing to coral UI 3 has direct impact on all our customized dialogs.

    Did anyone encounter the same issues?

    • Michael Leroy
      Posted at 13:28h, 13 June Reply

      I wouldn’t expect the encryption of properties to take up a significant amount of time. It comes down to refactoring the files to make use of the encrypted value and coming up with a strategy to manage the keys across environments.
      However, the authoring UI changing to coral UI 3 can require a large amount of refactoring depending on your customizations.

Leave a Reply

%d bloggers like this: