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.