D6 Tools & Assets Documentation

With AEM, there is one production environment. You make edits or updates in the "authoring" environment and once complete, the public sees the "published" versions on the live site. This works for simple websites that are not updated regularly or for sites which don’t require approvals, but you run into issues when:

• Your business users or legal team are unable or unwilling to sign into AEM
• Content cannot be reviewed or reviewed accurately in the authoring environment
• Sign-off and approvals are performed based on versions that cannot be browsed or viewed completely

One or more of these issues are likely roadblocks you’ve encountered. We know this because every single one of our clients faced them at some point, and all of them asked us to solve the problem. We explored potential approaches to solutions including a launch feature, temporary web pages, a Package Manager, and a preview environment. While these out-of-the-box tools help address some of the issues, they don’t solve the bigger picture.

Launch

The launch feature was built for the use case of having to create content to publish later. It was built to allow you to update your current content and plan a big future release. The problem with the launch is that you still can't: 

• View the content outside the authoring environment
• Show the content to 3rd parties that don't have CMS access
• View the content in context/browse the website
• Unable to author content that depends on code that might not be in production yet

Temporary Webpages

A temporary web page is a workaround to the launch feature. Your site might have an entire section "/testing/" where you publish content for test purposes or authoring. You can share those links with any party who needs to review and approve e.g. product owners, business users, legal, etc. The issue remains:

• Users are still unable to browse the website and view the content in context
• No SEO compliance
• Waste of time and resources

Once you publish a temporary web page, it’s live. That means Google could accidentally crawl your test content, opening up the possibility of being seen by your users in an unfinished or unapproved state. And even after content is approved, you still need to go back and manually update the old web pages.

Package Manager

Another potential approach is AEM's Package Manager. This code deployment tool allows you to deploy content or anything within the repository from one instance to another, from Author to Publisher or from QA Author to Production Author. There are three main issues with packages:Typically dependent on developers

• Error-prone as it's a manual process of picking paths
• Dependency on developers
• Manual process of picking paths makes them prone to errors
• Possibility of overwriting version control history

Preview Environment

Adobe enabled preview environment in the cloud, meaning instead of having two instances in your authoring environments (author/publisher), you now have three (author/preview/publisher). Preview environment is similar to a publisher environment. It's in the same tier as your instances, which has limitations that complicate your decision-making process.

If you want to author content for preview while making an emergency fix to the same page, it’s almost impossible because you need to choose a publish environment.

Our Solution

We developed a flexible architecture solution as a result of conversations with our clients to determine an authoring workflow that really works. Most of our customers now run a traditional 3/4 environment architecture:

1. Development
2. QA
3. Stage (optional)
4. Production

Each environment is set up with authors, publishers, and dispatchers. QA or Staging are replicated production environments for our customers to run performance tests, code validation or testing so we created a tool where authors (the same team that creates content) can easily push data from QA or Staging into Production.

The three most important factors are:

Ability to preview content in a dispatcher environment. This enables the business user the ability to view and navigate content in context in a site that will closely resemble the live site once published.

Simplicity in design. Simplicity in execution.

Ability to preview content in a dispatcher environment. This enables the business user the ability to view and navigate content in context in a site that will closely resemble the live site once published.

How To Configure It

Configure the OSGi class "com.dos.cms.aem.foundation.authoring.ConfigExpressionResolver" with the following two properties:

• publishToName: The name of the other environment (e.g. Production Author)
• publish: The scheme/host of the other environment (e.g. https://author.mycompany.com)

Additionally, you must allow the Referrer filter to accept requests from different environments, you must also enable CORS filters from the incoming domain.

Supports

• Webpages
• Assets (including Content Fragments)

Known Limitations

No support for:

• Tags
• Assets stored outside AEM (e.g. cloud microservices) that do not use the AEM upload asset API/asset creation (works fine in Managed Service environments)
• User permissions
• Users/groups

The tool must be configured on HTTPS to ensure cookies can be used with XSS requests.