Adobe Experience Manager (AEM) is installed with default settings for all parameters which allow it to run “out of the box.” However, you can configure AEM for your own specific requirements.
There are many aspects of AEM that can be configured:
- Some are commonly configured for every project installation and must be reviewed to confirm whether or not they are applicable to your project.
- Further configurations may be common though not imperative; related to features, or system performance and stability.
- Others are only required for certain optional features of AEM (these are documented together with the appropriate feature).
Depending on the specific configuration these changes can be made by using either the:
- Adobe CQ Web Console
This is a standard location for configuring OSGi bundles and services.
See Configuring OSGi for further details and recommended practices. - Repository
A sub-set of OSGi configurations are available in the repository. This ensures that copying, or replicating, repository contents recreates identical configurations. You can also add your own configurations, dependent on run-mode, to the repository.
See OSGi Configuration in the Repository and in particular Adding a New Configuration to the Repository for further details. - File system
A few configuration files reside within the file system. - AEM WCM
Various aspects can be configured within AEM WCM itself, many using the Tools console; for example, replication agents.
Note: When working with Adobe Experience Manager, there are several methods of managing the configuration settings for OSGi services (console or repository nodes).
See Configuring OSGi for full details.
Note: Configuring AEM is straightforward, but you must be aware that:
Certain changes can have a major impact on the application(s). For this reason, ensure you have the necessary experience and knowledge before you start to configure AEM and make only the changes that you know are required. Any changes made via the OSGi console are immediately applied to the running system (no restart is required).
Primary Configuration Considerations
This list details the primary areas that are commonly configured for every new project. Not all are needed, but the list must be read and reviewed to see what is applicable to your project.
The list gives a short overview of each configuration aspect, together with links to the pages that provide full details.
Security Checklist
Several key configuration issues are listed in the Security Checklist. Please ensure that you read this and take any action necessary for your installation.
Configuring the Default UI – Touch-Optimized or Classic
There are two UIs available for use in AEM:
- The Touch-optimized UI
- The Classic UI
You can configure the UI you require using Root Mapping.
IPv4 and IPv6
All elements of AEM (e.g. the repository, the Dispatcher, etc) can be installed in both IPv4 and IPv6 networks.
Operation is seamless as no special configuration is required, when needed you can simply specify an IP address using the format that is appropriate to your network type.
This means that when an IP address needs to be specified you can select (as required) from:
- an IPv6 address
for example http://[ab12::34c5:6d7:8e90:1234]:4502 - an IPv4 address
for example http://123.1.1.4:4502 - a server name
for example, http://www.yourserver.com:4502 - the default case of localhost will be interpreted for both IPv4 and IPv6 network installations
for example, http://localhost:4502
Version Purging
In a standard installation, AEM creates a new version of a page or node whenever you activate a page (after updating the content). You can also create additional versions on request using the Versioning tab of the sidekick. All these versions are stored in the repository and can be restored if required.
These versions are never purged, so the repository size will grow over time and therefore need to be managed.
See Version Purging for full details, in particular, Version Manager for details of how to configure AEM to purge older versions when a new version is created.
Logging
AEM offers you the possibility to configure:
- global parameters for the central logging service
- request data logging; a specialized logging configuration for request information
- specific settings for the individual services; for example, an individual log file and format for the log messages
See Logging for full details.
Run Modes
Run modes allow you to tune your AEM instance for a specific purpose; for example author or publish, test, development or intranet, etc.
This is done by defining collections of configuration parameters for each run mode. A basic set of configuration parameters is applied for all run modes, you can then tune additional sets to the purpose of your specific environment. These are then applied as required.
All configuration settings are stored in the one repository and activated by setting the Run Mode.
See Run Modes for full details.
Single Sign-On
Single Sign-On (SSO) allows a user to access multiple systems after providing authentication credentials (such as a user name and password) once. A separate system (known as the trusted authenticator) performs the authentication and provides Experience Manager with the user credentials. Experience Manager checks and enforces the access permissions for the user (i.e. determines which resources the user is allowed to access).
See Single Sign-On for further details.
Resource Mapping
Resource mapping is used to define redirects, vanity URLs, and virtual hosts for AEM.
For example, you can use these mappings to:
- Prefix all requests with /content so that the internal structure is hidden from the visitors to your website.
- Define a redirect so that all requests to the /content/en/gateway page of your website are redirected to http://gbiv.com/.
See Resource Mapping for further details.
Replication, Reverse Replication and Replication Agents
Replication agents are central to AEM as the mechanism used to:
- Publish (activate) content from an author to a publish environment.
- Explicitly flush content from the Dispatcher cache.
- Return user input (for example, form input) from the publish environment to the author's environment (under control of the author environment).
For further details see Replication.
OSGi Configuration Settings
OSGi is a fundamental element in the technology stack of AEM. It is used to control the composite bundles of AEM and its configuration.
See OSGi configuration settings for a list of the various bundles that are relevant to project implementation (listed according to bundle). Not all the listed settings need adjusting, some are mentioned to help you understand how AEM operates.
When working with AEM there are several methods of managing the configuration settings for such services; see Configuring OSGi for more details and the recommended practices.
Configuring LDAP
LDAP authentication is required to authenticate users stored in a (central) LDAP directory such as Active Directory. This helps reduce the effort required to manage user accounts.
LDAP authentication occurs at the repository level, so it is handled directly by the repository. For further details, see Configuring LDAP with AEM.
For user management within AEM (including assignment of access rights) see User Administration and Security.
Configuring the Dispatcher
The dispatcher is Adobe’s caching and/or load balancing tool. Using the Dispatcher also helps to protect your AEM server from attack. Therefore, you can increase the security of your AEM instance by using the Dispatcher in conjunction with an enterprise-class web server.
See Dispatcher for full details, in particular Configuring the Dispatcher for further configuration details.
Configuring AEM LiveCycle Connector
With the release of the AEM Doc Services and AEM Doc Security, we now have the capability to invoke the LiveCycle doc services to render an XFA form, convert a document to PDF, and policy protects a document. Please read AEM LiveCycle Connector for more details.
Job Offloading and Topology Administration
Offloading distributes processing tasks among Experience Manager instances in a topology. With offloading, you can use specific Experience Manager instances for performing specific types of processing. Specialized processing enables you to maximize the usage of available server resources.
Topologies are loosely-coupled Experience Manager clusters that are participating in offloading. A cluster consists of one or more Experience Manager server instances (a single instance is considered as a cluster).
For more information on how to view or modify topology membership, consult the Administering Topologies section.
Configuring the Welcome Console
The Welcome console of the classic UI provides a list of links to the various consoles and functionality within AEM.
It is possible to configure the links that are visible, see Configuring the Welcome Console for further details.
Configuring for Performance
Performance is key to your project. Certain aspects of AEM (and/or the underlying repository) can be configured to optimize performance.
See Configuring for Performance for further details.
Scaling
Scaling a CQ installation correctly depends greatly on the details of your particular use case. A detailed discussion of solution patterns for various situations can be found in Scaling CQ.
Shared Data Store
The repository data store is used to offload the storage of large binaries from the repository proper to a separate area so that multiple instances of the same binary (an image, for example) within the repository tree are stored only once.
This “store-once, reference-many-times” feature can be extended to serve not just a single repository tree but entirely separate repositories, by configuring the data store of each to refer to the same shared file system location.
Such a data store can be shared between different nodes in the same cluster, different publish and/or author instances in the same installation, or even entirely separate instances in different installations.
For more information, see Configuring Data Stores and Node Stores.
Further Configuration Considerations
Enabling HTTP over SSL
You can enable HTTP over SSL to employ more secure connections to your servers. See Enabling HTTP over SSL for further details.
AEM Portals and Portlets
A portal is a web application that provides personalization, single sign-on, content integration from different sources, and hosts the presentation layer of information systems. The portlet component also lets you embed a portlet on the page. To access content provided by CQ5 WCM, the portal server can be fitted with the CQ5 Portal Director Portlet. You can do this by installing, configuring, and adding the portlet to the portal page.
See Portal and Portlets for further details, in particular Using CQ as a Portal and Installing, Configuring, and Using CQ in a Portlet.
Expiration of Static Objects
Static objects (for example, icons) do not change. Therefore the system should be configured so that they do not expire (for a reasonable period of time) and so reduce unnecessary traffic.
See the Expiration of Static Objects for further details.
Open Files in the Java Process
Each java process may access files – this requires system resources. For this reason, an upper limit is defined as to how many files each process is allowed to access concurrently. If this is exceeded an exception error can occur.
If the AEM process exceeds this maximum, then the message “too many open files” will be seen in error.log.
To avoid such exceptions you need to:
- Check how many open files your AEM process is using.
How you make this check will depend on the platform your instance is running on. Utilities such as lsof (Unix) or Process Explorer (Windows) can be used.
This value should be monitored during development and testing to:- confirm that files are being closed as required
- to determine the maximum value needed (under various circumstances)
- Set the maximum allowed.
The new value should cater to both the current needs and any future peaks, so it is advisable to double the current needs.
By default, serverctl configures CQ_MAX_OPEN_FILES to 8192; this should be sufficient for most scenarios.
Configuring the Rich Text Editor
The Rich Text Editor (RTE) provides authors with a wide range of functionality for editing their textual content; providing them with icons, selection boxes, and menus for a WYSIWYG experience.
See Configuring the Rich Text Editor for further details.
Configuring Undo for Page Editing
There are several properties that control the behavior of the undo and redo commands for editing pages. These can be configured, see Configuring Undo for Page Editing for further details.
Configuring the Video Component
The Video component allows you to place a predefined, out-of-the-box video element on your page.
For proper transcoding to occur, your administrator must Install FFmpeg separately. They can also Configure your Video Profiles for use with html5 elements.
Configuring and Customizing Reports
To help you monitor and analyze the state of your instance, CQ provides a selection of default reports, which can be configured for your individual requirements:
See the Basics of Report Customization for further details.
Configuring Email Notification
CQ sends email notifications to users who:
- Have subscribed to page events, for example, modification or replication.
- Have subscribed to forum events.
- Have to perform a step in a workflow.
See Configuring Email Notification for further details.
Enabling Page Impressions
Page impressions are displayed in the Impressions column of the classic UI siteadmin console. To enable the capture of page impressions you need to configure:
- On the publish instance:
- On the author instance:
No comments:
Post a Comment
If you have any doubts or questions, please let us know.