We did a podcast about Query Editor in which we talked about the usefulness of this tool. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Tool. Remember, these should only be used in your non-production lanes.

What is it?
From the ACS GitHub page about Query Editor: “QueryEditor is a WebUI that allows QueryBuilder queries to be written, executed and debugged in real time.”

How it works
In October 2015, Joey wrote a blog post comparing and contrasting the three most prominent query engines in Adobe Experience Manager, but he would admit: “I have never totally gotten my brain wrapped around the Query Builder syntax.” Part of that is because Joey is more geared around the systems side of the house, but I think part of it is also the fact that he has always been very comfortable with XPath.

However, as Joey pointed out on the podcast, there are several things in Adobe Experience Manager that are either easier to do with Query Builder, or—in some cases—just not possible with the other syntaxes. So, if you’re like Joey, and you occasionally struggle with Query Builder syntax—or you just want to be able to more easily interact with the repository while working on your queries—here’s a tool to help. One note we’d like to add: we have found using the “Auto-Query” feature to be pretty sluggish, unless you have very little content in the repo.

Example application
Perhaps you know the subset of node you need to work with, and—since this will be a regular process you need to run—you’re trying to find the most effective way to leverage Query Builder to select those nodes. You could use the Query Editor to fine tune your query, and validate that it gives you the desired set of nodes, before putting it into your code for deployment.

We did a podcast about the CSV Asset Importer in which we talked about the usefulness of this tool. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Tool. Remember, these should only be used in your non-production lanes.

What is it?
From the ACS GitHub page about CSV Asset Importer: “CSV Asset Importer is a tool that accepts a CSV file whose rows represent an Asset to import.”

How it works
When you need to do that initial import of a bunch of Assets for your development work, no one wants to sit there and upload them manually; even creating the correct JCR package structure can be a bit of a pain, especially if you want to import specific items of asset metadata. Thankfully, the ACS guys have created a great tool that allows you to define the list of assets to be imported, their on-disk location and where in the DAM they should end up, as well as their associated metadata, all in a single CSV file. Adobe Experience Manager will then do the hard work of importing the asset, applying the metadata, and executing the required workflows.

Example application
Again, like most of the other ACS AEM Tools, it pretty much just does what it says. We have used it on several projects to import a large batch of assets rather than manually uploading them. If you’re preparing to load a long list of assets into your Adobe Experience Manager instance, this is a very handy way to control the ingestion process. Please pay special attention to the “Important Considerations” mentioned in the documentation.

We have covered ACS AEM Commons and ACS AEM Tools at length. So we thought it was time for us to discuss ACS AEM Samples, the third leg of the ACS AEM suite. ACS AEM Samples is “Well commented code samples of AEM building blocks to help educate AEM developers”. It can be used as a skeleton or starting point for your implementation but it is not production ready code. “No guarantees exist around the effects of installing this package in AEM” as it hasn’t been vetted for “unobtrusiveness”. Samples is just a good place to start if you want to learn about Adobe Experience Manager, need a refresher, or need a good place to start with your implementation. In this podcast, we discuss a bit about what it is and then some use cases that allowed Joey to use it. Specifically, we talk about how he used OSGI Service, Filter Servlet, and the Query Builder.

We’ve talked before about the dissonance between Adobe Experience Manager’s Publish and Dispatcher instances, but this dissonance is not limited to content pages; another case that comes up often is when caching image renditions from DAM Assets. If you directly refer to the Asset’s rendition through the Dispatcher, you might have found a surprising result when you then tried to render the Asset node directly. Let’s break down what’s happening here…

Explanation
The Dispatcher caches content. It doesn’t do anything particularly intelligent in the caching process – it just asks the Publish node for a file – say, “en.html” – and stores whatever results are returned until they get invalidated or flushed.

Demonstrating the Problem
An easy way to put an image on a page is to write the DAM path into the src of an img element.

 or ${properties['fileReference']}

which gives

Say we have /content/dam/site/dog.jpg in the DAM. If we hit that, we see an image of a dog. The Asset Upload Workflow also makes a bunch of renditions, so if we hit /content/dam/site/dog.jpg/jcr:content/renditions/cq5dam.thumbnail.48.48.png, we see the same image rendered at a constant 48×48 pixels.

If the requests are issued in that order, we would find a file on the Dispatcher at /content/dam/site/dog.jpg which contains the full-sized image, while the latter is served correctly, but never cached.

If we request the thumbnail rendition first, we see a cached file named something like /content/dam/site/dog.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png. But when we request /content/dam/site/dog.jpg to see the original asset, we get a 403 response from the Dispatcher because “dog.jpg” is a directory leading to the thumbnail, rather than a file.

To make the problem even more painful, it’s not uncommon to have multiple Dispatchers in some kind of load balanced environment, and you may end up with the requests coming in using the “successful” ordering on one Dispatcher, while going in the “broken” order on another, leading to inconsistent errors depending on which Dispatcher serves a particular request.

Possible Solutions
We have found a few different ways of working around this issue; with the flexibility of AEM, there are probably even more ways, but these are kind of our “default set” of tools we reach for when we find ourselves in this situation. Having multiple solutions allows us some flexibility to pick and choose our preferred option based on other project constraints.

Solution #1: Use the Named Image Transform Servlet
If you are using ACS Commons, you can use the Named Image Transform Servlet. It will produce paths that look like /content/dam/dog.png.transform/my-transform-name/image.png, which will not create conflicting cache.

If you are not using ACS AEM Commons – why not? See our extended series on the array of useful items contained in this Adobe-sponsored, open source package.

Solution #2: Put the image in a subresource and use the image servlet on parbase (/libs/foundation/components/parbase/img.GET.java). There are two steps to do this:
1. Get the subnode in place with the dialog

By doing ./image-resource/propertyName in the name fields, we are creating a subresource at image-resource (or whatever arbitrary name we selected) as a child of our current resource, and putting propertyName in it as a property. You can also pick stuff up the same way using ${properties[‘image-resource/propertyName’]}. We have noted some difficulty leveraging this method at page creation time in AEM 6.1, where the code that handles the dialog appears to be too simplistic to obey this directive.

2. Use the subresource to render the image

which gives

${resource.path} gives us the path of the current resource, which is a particular node with its sling:resourceType equal to our component, which has an image-resource subresource.

This puts the cached file at /content/site/en/page/jcr:content/parsys/…/image-resource.img.png, which will not conflict with the DAM path. However, this does take us back to the original “dissonance” problem of having stale cache if the image is edited in the DAM and the path doesn’t change.

Solution #3: Reference the “original” rendition
Using one of the various forms of content rewriting, you can detect any attempts to directly reference the Asset node and append “/jcr:content/renditions/original” to the requested path, so that the Dispatcher consistently sees the Asset node as a directory containing “rendition” items.

At Axis41, our general preference is to lean toward the first option (namely, the ACS AEM Commons Named Image Transform); however, it’s useful to know there are other methods as well, in case you ever find yourself in need of an alternative.

If you have run into this problem and found other solutions that you think we’re overlooking, we’d love to hear from you at info@aempodcast.com.

We did a podcast about the Named Transform Image Servlet a while ago in which we talked about the usefulness of this feature. Here is a written breakdown of that podcast for this specific ACS AEM Commons feature.

What is it?
From the ACS GitHub page about Named Transform Image Servlet: “Many website designs demands consistency of images based on their use within components. For example, a panoramic spotlight may demand the image be 960 × 400, and bio picture must be 100 × 100 and greyscale.

The ACS AEM Commons Named Transform Image Servlet allows specific image transforms to be defined centrally via OSGi configurations. These image transforms can be easily invoked via parameterized HTTP GET requests to image resources in AEM.”

How it works
You create an OSGi configuration that has a name and a set of predetermined image transformations; examples might include resizing, cropping, rotating, making grayscales, etc. At the time the image is referenced, you can append this named transform to the image just by using the correct Sling selector syntax. The GitHub page gives a lot of default transform options.

Audience impact (authors, devs)

• Devs – set up the transforms
• Authors – choose them in the way they do their asset references

Example application
Let’s imagine a site where each article has a “Featured Image”; these images fit well-defined parameters, but the original source images will be uploaded in 4k resolution. Every time a new article is published, we want it to get an equal share to appear in the main page’s carousel. We could require the authors to go in directly and crop the image to the desired dimensions, but since we decided that we’ll have rules around the kinds of images that can be uploaded, we might just want Adobe Experience Manager to do that work for us. In this case, we might define a new transform called “carousel”, and the appropriate component could then reference the article’s “Featured Image” with this transform applied; we now have a usable carousel image for every article, without requiring a human to perform the desired crops and resizes.

We did a podcast about the Ensure Oak Index in which we talked about the usefulness of this feature. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Commons feature.

What is it?
From the ACS GitHub page about Ensure Oak Index: “The Oak repository used by Adobe Experience Manager 6, allows from fine tuning of search performance via the definition of Oak Index definitions. The index definition nodes, usually stored under /oak:index, define the index and also store the index data (in a node structure invisible to the AEM tooling).

Ideally the Oak Index definitions used by an application could be stored with in the application’s content package, however, it is possible (and even likely) that upon deployment the content packages index definition may wipe out the actual index data (again, invisible via Adobe Experience Manager tooling) when updating the node, necessitating a reindex, which depending on the repository size and index configuration can be costly (and generally unnecessary).

Ensure Oak Index is tooling that allows Oak Index Definitions (referred to in this document as Ensure Definitions) to be defined in a content package, and then safely translated to real Oak Indexes.”

Said another way, Oak indexing in Adobe Experience Manager 6.0+ allows tuning performance; however, the control of how and when these indexes are created has only been binary to this point—once the /oak:index nodes are created, you can end up immediately performing a very expensive indexing operation. The Ensure Oak Index feature provides finer-grained control of when—and how—these indexes are rebuilt.

How it works
You create nodes of type oak:Unstructured; other than that, the nodes should emulate the structure of the equivalent /oak:index nodes, but adding new boolean properties to provide the finer-grained control. These new properties are: ignore, delete, forceReindex, and recreateOnUpdate.

Audience impact (devs, admins)

• Admins – Gives better control over when packages can cause potentially disruptive reindexing
• Devs – Define Ensure indexes as part of their process

Example Application
This is a good tool for the cases when it may take a long time for your indexes to stabilize. While that process is taking place, your production site can run slow, so you can use this tool to let those indexes stabilize in a separate environment and then deploy those stabilized indexes to your production environment with a smaller impact.

Recently in a project I was working on, we had the need to cache our clientlibs and have them reliably recache every time there was a change. I looked around and found that there is an ACS AEM Commons tool made for just this purpose. In this post I’ll demonstrate how we went about using this tool to version our clientlibs.

The Versioned ClientLibs ACS AEM Commons feature uses a Sling rewriter to add an MD5 hash to the paths of your clientlibs, forcing them to recache after every modification. Typically Adobe Experience Manager will use the lastModified property to determine when to recache, however versioned-clientlibs is a more reliable approach.

To implement the versioned-clientlibs feature, simply copy the node from /libs/cq/config/rewriter/default to some path inside your application. In this example, we’ll choose /apps/acslibs/config/rewriter. For the most part this path is arbitrary, however the config node must be inside a four-level-deep path that ends in config/rewriter to work.

Your config file should be named versioned-clientlibs.xml and should look something like this:

Along with your config for the versioned-clientlibs, you should also copy down the default config node and make sure versioned-clientlibs is added to the transformTypes. Here’s an example of the content.xml for the default config:

If you want to validate whether your configuration was successful, you can check the Sling Rewriter tab in the OSGI Web Console (/system/console/status-slingrewriter). Under “Active Configurations” you should see a configuration section for the versioned-clientlibs.

Versioned ClientLibs

Default

Along with the rewriter configuration, you’ll also need to configure Apache to send the right headers. Here’s an example of what the config should look like:

SetEnvIf Request_URI "(\.min)?\.[a-f0-9]+\.js" long_expires=true
    SetEnvIf Request_URI "(\.min)?\.[a-f0-9]+\.css" long_expires=true
    Header set Cache-Control max-age=2592000 env=long_expires

That’s it. Now your clientlibs should recompile every time there’s a change to them.

It should be noted that per the ACS Adobe Experience Manager Commons documentation there are exceptions to which files this rewriter will support. These are the files this rewriter will NOT support:

• URIs embedded in CSS or JavaScript, including: background-images, web fonts, etc.
• Relative URIs, e.g., etc/clientlibs/mysite/styles.css
• URIs including a scheme or protocol-relative location, e.g., http://example.com/etc/clientlibs/mysite/styles.css and //example.com/etc/clientlibs/mysite/styles.css
• URIs to non-AEM HtmlClientLibrary resources, e.g., /etc/designs/mysite.css
• Tags contained in conditional comments
• Clientlibs included by JavaScript (e.g., when leveraging the property channels)

So if you’re looking for a way to reliably update your ClientLibs every time there is a change, this is a pretty simple approach.

Having prepared for the journey, you’re now ready to venture into the desert of Adobe Experience Manager and learn about the mystical Author. Ok, I am not sure I would really call the AEM Author mystical, but it sure can bewilder the uninitiated. For those of you who are returning for the second installment of this series of articles, I mentioned we would be digging into the various responsibilities within AEM. We’re going to discuss the Author instance, from its purpose through setup and maintenance. The setup and configuration for Author can also be found in Adobe’s documentation. The same process can be followed more or less for the Publish instance, which we will talk about in our next article. For those of you who haven’t read my first article, it covers some high-level information on AEM. Unless you are already familiar with the basic concepts surrounding AEM, I would suggest giving it a quick read before moving on.

Another quick note is that throughout the article I will reference ACS AEM Commons, which is a package provided by Adobe Consulting Services. Essentially, they generalize and make available tools they have created and package them as an add-on to AEM. These features can be extremely helpful and potentially save you and your developers a lot of time and frustration. I recommend including this package on all of your AEM installations. Let’s get started.

The AEM Caravan Lead
As you embark on your journey, it’s important to look to the leader to guide the expedition. Similarly within Adobe Experience Manager, it’s important to look to the Author to guide the creation and management of content. This server should be thought of as the lead instance in AEM. Developers will create templates and components for the the content creators to use on Author; content creators will create pages and import digital assets here as well. As a systems guy or gal, this is where all the configs are stored. The idea here is that everything, even configs that apply only to a Publish instance, is stored on Author and then replicated to Publish servers. Run modes, Author or Publish, for example, are then used to tell the servers if configs should be loaded or not. So really, in a worst case scenario, as long as you have a good backup of your Author instance, you will be able to restore your AEM stack. This does mean that inherently AEM has a single point of failure, the Author. I would suggest becoming very serious about your backup processes, if you are not already—especially when it comes to the Author.

As I mentioned above, Author is where content is created; when you first start an Author instance it installs code that is Author specific, basically the editing dialogs and tools. Just in case any of you were thinking “Well, I’ll just set up one Author and then save time by copying that instance and use it as a Publish”—don’t do it. I know you were thinking it, but don’t do it. You will end up having two Authors and you will run into all kinds of “fun”. This is because of installation run modes, and we’ll talk about those in a minute.

Currently Adobe Experience Manager is in a period of transition when it comes to the web interface; they are working toward Touch UI. What this means is the classic, older tools are being replaced gradually. So tools you might have used the past, including those that are mentioned in this article and others, might change slightly or entirely. With that in mind, I am going to share some paths that as an admin will be helpful to remember. I am going to list them with a quick description and include the alternate paths if there are old and new versions.

• High-level navigation of the content tree; manage, activate, or deactivate pages
  • /siteadmin (classic tool)
  • /sites.html
• Allows you to create users and groups, and manage permissions and members
  • /useradmin (classic tool: permissions can be managed here or under “Access Control” in the CRXDE)
  • /libs/granite/security/content/useradmin.html and
  • /libs/granite/security/content/groupadmin.html
• High-level navigation of digital assets
  • /damadmin (classic tool)
  • /assets.html
• High-level navigation for AEM tools, including ACS Commons
  • /miscadmin
• Disk space reports
  • /etc/reports/diskusage.html
• Replication agents and tree activation
  • /etc/replication.html
• Workflow manager
  • /libs/cq/workflow/content/console.html
• OSGI console access
  • /system/console/bundles – Default page, list of bundles
  • /system/console/configMgr – List of service configurations
  • /system/console/slinglog – Quick access to logging information and configs
  • /system/console/jcrresolver – Useful for testing sling mapping configurations
• Tree-like navigation of the nodes in the JCR
  • /crx/de/index.jsp (CRXDE)

Gaining AEM Ground
As you make your way across the desert, you want to be sure that you’re doing everything possible to maximize your time. You also want to do that with regard to your AEM installation to ensure you’re getting the most out of your investment. When you read through documentation on getting started with AEM, you have the option of double-clicking a JAR file, which will start a local instance of AEM that you can play with; this is great for local testing but not so helpful for a headless server environment. As a rule of thumb when I want to work with Adobe Experience Manager, I have gotten into the habit of doing an unpack on the JAR file (java -jar /path/to/file/aem.jar -unpack), which will extract everything into a directory named “crx-quickstart”. This is an important directory; it is pretty much where all of AEM will live—think of it as AEM’s home directory. This directory can be copied or moved and it will contain your entire AEM installation.

Starting or stopping AEM after an unpack is fairly simple as there are scripts located in the crx-quickstart/bin directory. You can either run these directly, or the better option would be to create a daemon service script that exports the values needed to start AEM, such as the JVM Options and run modes.

I have mentioned run modes a few times, so let me take a quick moment to talk about them here as there are really two types.

Installation run modes are applied the first time you run AEM and then fixed for the entire lifetime of the instance; they cannot be changed later on down the road.

• Persistence Manager – Determine how data persists, i.e., crx2, crx3, crx3mongo
• Role – Determines what responsibilities are assigned to AEM, i.e., Author or Publish
• Samplecontent – installs Adobe’s sample Geometrixx content

Note: By default, samplecontent is added to the installation run modes. If you specify “nosamplecontent”, you will instead get a version of AEM that matches Adobe’s Production-Ready Checklist. What is obvious about this is that sample content and users are not installed, but it also causes some bundles from being installed that you cannot easily get back. For actual production environments this can be helpful, but in the non-production stacks it might make things a little difficult. For non-production environments, you may want to consider allowing sample content to be installed and then remove the Geometrixx packages after.

Customized run modes are applied on each startup and can be changed with a restart of AEM. They allow you to define run modes that can be used to identify the instance that’s running and modify its configurations accordingly. An example would be to set a “production” run mode, so you can identify configs that should only be applied to a production instance.

Conserving Water
In the desert, you have to know how to manage your water supply. The same holds true for “flushing” cached content in AEM. Now, I mentioned in the first article how information that is created on the Author is passed through the stack to reach the end user. This process can run through several workflows, but at the end of the day it is still all handled by replication events. I also mentioned a little earlier in this article that you want to ideally keep everything on Author and then replicate (push) that out to Publish instances. This holds true for the Dispatcher agents as well. You should be in the habit of configuring those nodes on the Author, even though they live under the agents.publish directory, and then push them to your pubs. Now, you might ask, “Why not just have the Author flush the cached content from the Dispatchers?” Well I am glad you asked—you see the issue with having the Author flush content that has just been activated is that sometimes it takes the Publish instances a moment to ingest that content. This is especially true if there are a lot of replication events happening. This then creates an issue where the Dispatcher is trying to re-cache that page but the Publish isn’t ready to render it, so you end up caching broken pages. Thus, you should have your Publish instances flush your Dispatchers in all cases but one.

What is that one case you ask? Another great question. There is a tool packaged with ACS commons called the “Dispatcher Flush UI”, which allows you to create pages that content creators can use to flush pages manually from the Dispatcher. This is safe to do from the Author, but you will need to make sure you enable a flush agent for each Dispatcher on your Author, and that you have the “Ignore default” option selected. This allows ACS Commons to send a flush request from the Author while normal activations will continue to use flush agents on Publish.

Scheduled Breaks
During your journey, you need to ensure that you’ve scheduled time for breaks. You also might want to schedule something of similar importance within AEM. I mentioned the importance of taking backups a little earlier, and if you’re wondering how you can trigger these on a schedule, then you are in luck. We can cover this in more detail later, but for those of you who are looking for a solution right now, when AEM triggers a backup it sends a ReSTful request to start the process. Knowing this can help get you started.

Speaking of ReSTful, calls I should also mention there are quite a few articles out there that cover different cURL commands that can be used with AEM, as such I will not cover those commands in this article. I will however mention something that may prove useful: Adobe Experience Manager is built on a ReSTful framework, which means anything you can do through a console or the CRXDE you can make a ReST call to perform the same action. Although finding exactly the calls that are being made can sometimes be difficult, more often than not they are pretty simple to determine using this method I have picked up along the way. Chrome’s debug tool has this nifty option to copy any request from the network tab as a cURL. This means you can click the Preserve Log box, go into a local AEM instance, make your request using the CRXDE, and then see the result of that request in Chrome. You can then select that request and copy as cURL. Viola! You can now make the same request through the command line, shell script, or what have you.

We have now covered a bit of the basics talking about the Author environment, and getting the Author server started up. Although we could dig even deeper into the Author, this should help you to better understand how Author fits into the AEM stack. That’s two articles down and more to come—make sure to subscribe to the blog to stay tuned. We will be covering the Publish environment next as we continue to traverse the AEM landscape.

We have talked a lot about ACS AEM Commons on the site. We think that it is a great resource to Adobe Experience Manager developers. But since we have never talked about ACS Adobe Experience Manager Tools, we thought it was high time that we did. In this podcast Joey and I take time to discuss exactly what ACS Adobe Experience Manager Tools is and discuss in detail three specific tools: Explain Query, Query Editor, and CSV Asset Importer.

Really there is no great difference between Commons and Tools. But, as the website for ACS AEM Tools website clearly states, these are not things that you should ever use in your production environments. So please make sure that you don’t!

We did a podcast about Explain Query in which we talked about the usefulness of this tool. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Tool. Remember, these should only be used in your non-production lanes.

What is it?
From the ACS GitHub page about Explain Query: “Explain Query is a tool that explains how Oak is executing a query. For any given query, Oak attempts to figure out the best way to execute based on the repositories’ defined Oak indexes (under /oak:index). Depending on the query, different indexes may be chosen by Oak. Understanding how Oak is executing a query is the first step to optimizing the query.”

How it works
Perhaps the biggest change in the Adobe Experience Manager 6.x line is the transition to Jackrabbit Oak, which brings with it a whole new way of storing data. As a result of the new storage engine, you will likely find yourself occasionally revisiting how your content is indexed so that JCR queries can bring back the correct results in a reasonable amount of time.

Traditional relational databases have historically included a utility to help you determine where you need to improve or expand your indexes, but JCR users have largely been left to their own devices. Whether it’s a new migration to the 6.x line, or a new feature you’re implementing in an existing implementation, or just that performance has tanked because some part of the content tree grew in an unexpected way, you now have a tool you can use to determine the correct indexing on your content.

Example Application
Axis41 recently worked with a customer whose previous implementer had created an AEM 5.x implementation, which was driven by multiple levels of indirect queries; a given component would perform a query for some node properties, use those properties to build a string that was fed again into the query engine, which would return a set of node properties…and so on, ad nauseum. When we deployed this same code to Adobe Experience Manager 6.1, in some cases it would take several minutes per component to render—bringing the front page of the site to a total of 18-20 minutes to render. By taking the queries and running them through the Explain Query tool, we were able to define a set of indexes that brought much more reasonable response times (while we rewrote the implementation on a parallel work-stream to be more directly manageable).

We did a podcast about Query Editor in which we talked about the usefulness of this tool. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Tool. Remember, these should only be used in your non-production lanes.

What is it?
From the ACS GitHub page about Query Editor: “QueryEditor is a WebUI that allows QueryBuilder queries to be written, executed and debugged in real time.”

How it works
In October 2015, Joey wrote a blog post comparing and contrasting the three most prominent query engines in Adobe Experience Manager, but he would admit: “I have never totally gotten my brain wrapped around the Query Builder syntax.” Part of that is because Joey is more geared around the systems side of the house, but I think part of it is also the fact that he has always been very comfortable with XPath.

However, as Joey pointed out on the podcast, there are several things in Adobe Experience Manager that are either easier to do with Query Builder, or—in some cases—just not possible with the other syntaxes. So, if you’re like Joey, and you occasionally struggle with Query Builder syntax—or you just want to be able to more easily interact with the repository while working on your queries—here’s a tool to help. One note we’d like to add: we have found using the “Auto-Query” feature to be pretty sluggish, unless you have very little content in the repo.

Example application
Perhaps you know the subset of node you need to work with, and—since this will be a regular process you need to run—you’re trying to find the most effective way to leverage Query Builder to select those nodes. You could use the Query Editor to fine tune your query, and validate that it gives you the desired set of nodes, before putting it into your code for deployment.

We did a podcast about the CSV Asset Importer in which we talked about the usefulness of this tool. Here is a written breakdown of that podcast for this specific ACS Adobe Experience Manager Tool. Remember, these should only be used in your non-production lanes.

What is it?
From the ACS GitHub page about CSV Asset Importer: “CSV Asset Importer is a tool that accepts a CSV file whose rows represent an Asset to import.”

How it works
When you need to do that initial import of a bunch of Assets for your development work, no one wants to sit there and upload them manually; even creating the correct JCR package structure can be a bit of a pain, especially if you want to import specific items of asset metadata. Thankfully, the ACS guys have created a great tool that allows you to define the list of assets to be imported, their on-disk location and where in the DAM they should end up, as well as their associated metadata, all in a single CSV file. Adobe Experience Manager will then do the hard work of importing the asset, applying the metadata, and executing the required workflows.

Example application
Again, like most of the other ACS AEM Tools, it pretty much just does what it says. We have used it on several projects to import a large batch of assets rather than manually uploading them. If you’re preparing to load a long list of assets into your Adobe Experience Manager instance, this is a very handy way to control the ingestion process. Please pay special attention to the “Important Considerations” mentioned in the documentation.

We have covered ACS AEM Commons and ACS AEM Tools at length. So we thought it was time for us to discuss ACS AEM Samples, the third leg of the ACS AEM suite. ACS AEM Samples is “Well commented code samples of AEM building blocks to help educate AEM developers”. It can be used as a skeleton or starting point for your implementation but it is not production ready code. “No guarantees exist around the effects of installing this package in AEM” as it hasn’t been vetted for “unobtrusiveness”. Samples is just a good place to start if you want to learn about Adobe Experience Manager, need a refresher, or need a good place to start with your implementation. In this podcast, we discuss a bit about what it is and then some use cases that allowed Joey to use it. Specifically, we talk about how he used OSGI Service, Filter Servlet, and the Query Builder.

We’ve talked before about the dissonance between Adobe Experience Manager’s Publish and Dispatcher instances, but this dissonance is not limited to content pages; another case that comes up often is when caching image renditions from DAM Assets. If you directly refer to the Asset’s rendition through the Dispatcher, you might have found a surprising result when you then tried to render the Asset node directly. Let’s break down what’s happening here…

Explanation
The Dispatcher caches content. It doesn’t do anything particularly intelligent in the caching process – it just asks the Publish node for a file – say, “en.html” – and stores whatever results are returned until they get invalidated or flushed.

Demonstrating the Problem
An easy way to put an image on a page is to write the DAM path into the src of an img element.

 or ${properties['fileReference']}

which gives

Say we have /content/dam/site/dog.jpg in the DAM. If we hit that, we see an image of a dog. The Asset Upload Workflow also makes a bunch of renditions, so if we hit /content/dam/site/dog.jpg/jcr:content/renditions/cq5dam.thumbnail.48.48.png, we see the same image rendered at a constant 48×48 pixels.

If the requests are issued in that order, we would find a file on the Dispatcher at /content/dam/site/dog.jpg which contains the full-sized image, while the latter is served correctly, but never cached.

If we request the thumbnail rendition first, we see a cached file named something like /content/dam/site/dog.jpg/_jcr_content/renditions/cq5dam.thumbnail.48.48.png. But when we request /content/dam/site/dog.jpg to see the original asset, we get a 403 response from the Dispatcher because “dog.jpg” is a directory leading to the thumbnail, rather than a file.

To make the problem even more painful, it’s not uncommon to have multiple Dispatchers in some kind of load balanced environment, and you may end up with the requests coming in using the “successful” ordering on one Dispatcher, while going in the “broken” order on another, leading to inconsistent errors depending on which Dispatcher serves a particular request.

Possible Solutions
We have found a few different ways of working around this issue; with the flexibility of AEM, there are probably even more ways, but these are kind of our “default set” of tools we reach for when we find ourselves in this situation. Having multiple solutions allows us some flexibility to pick and choose our preferred option based on other project constraints.

Solution #1: Use the Named Image Transform Servlet
If you are using ACS Commons, you can use the Named Image Transform Servlet. It will produce paths that look like /content/dam/dog.png.transform/my-transform-name/image.png, which will not create conflicting cache.

If you are not using ACS AEM Commons – why not? See our extended series on the array of useful items contained in this Adobe-sponsored, open source package.

Solution #2: Put the image in a subresource and use the image servlet on parbase (/libs/foundation/components/parbase/img.GET.java). There are two steps to do this:
1. Get the subnode in place with the dialog

By doing ./image-resource/propertyName in the name fields, we are creating a subresource at image-resource (or whatever arbitrary name we selected) as a child of our current resource, and putting propertyName in it as a property. You can also pick stuff up the same way using ${properties[‘image-resource/propertyName’]}. We have noted some difficulty leveraging this method at page creation time in AEM 6.1, where the code that handles the dialog appears to be too simplistic to obey this directive.

2. Use the subresource to render the image

which gives

${resource.path} gives us the path of the current resource, which is a particular node with its sling:resourceType equal to our component, which has an image-resource subresource.

This puts the cached file at /content/site/en/page/jcr:content/parsys/…/image-resource.img.png, which will not conflict with the DAM path. However, this does take us back to the original “dissonance” problem of having stale cache if the image is edited in the DAM and the path doesn’t change.

Solution #3: Reference the “original” rendition
Using one of the various forms of content rewriting, you can detect any attempts to directly reference the Asset node and append “/jcr:content/renditions/original” to the requested path, so that the Dispatcher consistently sees the Asset node as a directory containing “rendition” items.

At Axis41, our general preference is to lean toward the first option (namely, the ACS AEM Commons Named Image Transform); however, it’s useful to know there are other methods as well, in case you ever find yourself in need of an alternative.

If you have run into this problem and found other solutions that you think we’re overlooking, we’d love to hear from you at info@aempodcast.com.

Continuing our slew of interviews with notable engineers-from Adobe Summit 2017 in Las Vegas, I interviewed David Gonzalez (Technical Marketing Engineer at Adobe and co-project lead of ACS AEM Commons/Tools/Samples), at the end of his lab on Demystifying Search in AEM 6.3 (a topic for a later podcast). We discussed a variety of topics, stretching from how he got involved in the ACS AEM project initially, to some of the future features we might see in ACS AEM Commons. It was especially great to hear David talk about his experiences growing as a developer and the process he went through to mature in his coding practice.

One of our last interviews at Adobe Summit 2017 was with our friend Justin Edelson (current Team Lead, Engineering Response Team at Adobe). He took some time to discuss a couple of topics with Joey and I. This is part 2 of that conversation (part 1 here). This week’s podcast will focus on ACS AEM Commons. As we have discussed before, ACS AEM Commons is a great resource for any Adobe Experience Manager implementation. It saves both time and money. Of course you already know that, right? RIGHT?! In this podcast, we talk about where ACS AEM Commons is going next. The big question is how they can broaden the contributor base. They want to have a greater amount of submissions and pull requests coming from the customer and implementation partner development groups working with AEM, instead of specifically from Adobe Consulting Services. If you have ideas, then feel free to reach out to David Gonzales and Justin Edelson to share them.

Joey and I were presenting at an Adobe Experience Manager Meetup group in Chicago when we first had the chance to meet Brett Birschbach, Solutions Architect at HS2 Solutions. During that meetup, we talked about how much we liked ACS AEM Commons—Brett furthered our interest in the topic by explaining that they just had something merged in at the end of 2016. It was called Shared Component Properties. We talked it over, and he agreed to record with us. Fast forward several months and our schedules finally were able to align. Our thanks to Brett for taking the time to discuss their Shared Component Properties feature from ACS AEM Commons. Additionally, Brett talked through the process of submitting to ACS AEM Commons. Here are a couple of helpful links mentioned in the audio:

• MultiSite Manager Tips and Tricks Immerse presentation
• HS2 write-up about the Shared Component properties