AEM Code Pitfalls cases

Statement - Code pitfalls in AEM

Solution :

• Avoid Sling Bindings in Java code

        Sling Bindings are an inappropriate way to get access to a service in 90% of cases. Instead,          you should use @Reference or @Inject annotations.

• Avoid Thread.interrupt in Java code

         Thread.interrupt is dangerous because it can close files, including Lucene files and                          persistent cache files, when called at the wrong time.

• Avoid mixing Java synchronization with ReadWriteLocks

          This can lead to a race condition in which the code will eventually deadlock.    

Coding Tips in AEM

• Use taglibs or HTL as much as possible

Including scriptlets in JSPs makes it difficult to debug issues in the code.  Additionally, by including scriptlets in JSPs, it is difficult to separate business logic from the view layer, which is a violation of the Single Responsibility Principle and the MVC design pattern.

• Write readable code

Code is written once, but read many times.  Spending some time up front to clean the code that we write will pay out dividends down the road as we and other developers need to read it later.

• Choose intention-revealing names

In the AEM code base, the following conventions are used:

• A single implementation of an interface is named Impl, i.e. ReaderImpl.
• Multiple implementations of an interface are named , i.e. JcrReader and FileSystemReader.
• Abstract base classes are named Abstract or Abstract.
• Packages are named com.adobe.product.module.  Each Maven artifact or OSGi bundle must have its own package.
• Java implementations are placed in an impl package below their API.

Ideally, names should reveal their intention.  A common code test for when names are not as clear as they should be is the presence of comments explaining what the variable or method is for:

Unclear	Clear
int d; //elapsed time in days	int elapsedTimeInDays;
//get tagged images public List getItems() {}	public List getTaggedImages() {}

• Don't repeat yourself

DRY states that the same set of code should never be duplicated.  This also applies to things like string literals.  

Code duplication opens the door for defects whenever something has to change and should be sought out and eliminated.

• Avoid naked CSS rules

CSS rules should be specific to your target element in the context of your application. 

 For example, a CSS rule applied to .content .center would be overly broad and could potentially end up impacting lots of content across your system, requiring others to override this style in the future. 

 .myapp-centertext would be a more specific rule as it is specifying centered text in the context of your application.

• Eliminate usage of deprecated APIs

When an API is deprecated, it is always better to find the new recommended approach instead of relying on the deprecated API.  This will ensure smoother upgrades in the future.

• Write localizable code

Any strings that are not being supplied by an author should be wrapped in a call to AEM’s i18n dictionary through I18n.get() in JSP/Java and CQ.I18n.get() in JavaScript.  

This implementation will return the string that was passed to it if no implementation is found, so this offers the flexibility of implementing localization after implementing the features in the primary language.

Escape resource paths for safety

While paths in the JCR should not contain spaces, the presence of them should not cause code to break. 

Jackrabbit provides a Text utility class with escape() and escapePath() methods.  For JSPs, Granite UI exposes a granite:encodeURIPath() ELfunction.

Use the XSS API and/or HTL to protect against cross-site scripting attacks

AEM provides an XSS API to easily clean parameters and ensure safety from cross-site scripting attacks.  Additionally, HTL has these protections built directly into the templating language.  An API cheat sheet is available for download at Development - Guidelines and Best Practices.

Implement appropriate logging

For Java code, AEM supports slf4j as the standard API for logging messages and should be used in conjunction with the configurations made available through the OSGi console for the sake of consistency in administration.  

Slf4j exposes five different logging levels. We recommend using the following guidelines when choosing which level to log a message at:

• ERROR: When something has broken in the code and processing cannot continue.  This will often occur as a result of an unexpected exception.  It is usually helpful to include stack traces in these scenarios.
• WARN: When something has not worked properly, but processing can continue.  This will often be the result of an exception that we expected, such as a PathNotFoundException.
• INFO: Information that would be useful when monitoring a system.  Keep in mind that this is the default and that most customers will leave this in place on their environments. Therefore, do not use it excessively.
• DEBUG: Lower level information about processing. Useful when debugging an issue with support.
• TRACE: The lowest level information, things like entering/exiting methods. This will usually only be used by developers.

In the case of JavaScript, console.log should only be used during development and all log statements should be removed before release.

Avoid cargo cult programming

Avoid copying code without understanding what it does.  When in doubt, it is always best to ask someone who has more experience with the module or API that you are not clear on.

How to enable/disable Optin or Optout Into Aggregated Usage Statistics Collection in AEM at Server level

Statement :  Opting Into Aggregated Usage Statistics Collection

Solution :

You can opt into usage statistics collection by using either the Touch UI or the Web Console.

Option 1- Opt-in by using the Touch UI

The first time you start AEM, you can opt-in by using the Touch UI as follows:

• On the AEM Navigation screen, click the Inbox (bell) icon.

• On the drop-down list, click "Enable Aggregated Usage Statistics Collection".

• On the opt-in screen, select "Allow collection of aggregated usage statistics".

• Click "Done".

Option - 2 : Opt-in by using the Web Console

You can opt-in (or opt-out) by using the Web Console as follows:

• On the AEM Navigation screen, click Tools and then Operations.

• On the Operations window, click Web Console.

• Search for "Aggregated Usage Statistics Collection".

• Click the Edit icon.

• Select the Enabled checkbox. Alternatively, you can de-select the checkbox if you want to opt-out of usage statistics collection.

• Click Save.

Note:
You can also opt-out at anytime by either using the webconsole or by not selecting the opt-in option on the AEM opt-in screen.
Opt in /Opt out Options-  information does not contain any data about your company's site visitors and will only be used to help Adobe deliver, support and improve your user experience. it will capture Adobe statistics about how you interact with AEM

How to perform Datastore Consistency Check in AEM

Statement- 

• How to find datastore consistency 
• How to fix data store inconsistencies.

Solution :


How to find datastore consistency:

• Go to this URL : http://localhost:4502/crx/explorer/config/check.jsp
• Login with username and password
• Check all the options expect fix consistency check.

• Observe the log files as below in the RUN log console, it shows consistency check is done and Zero error found.

How to fix data store inconsistencies.

• Assume if there were any repository inconsistency as per the above run, select only Fix inconsistency options else choose the all options to find inconsistencies and fix the same.
• Traversal check
• Fix inconsistencies
• Log each node
• Data store consistency check

• That's It!.

Transient workflow is not working - workflow instance is not getting initiated in AEM 6.3

Statement - Asset update workflow was converted to Transient workflow but transient workflow was not working.

Solution  :

clear the stale workflows, please follow below steps:

1. Go to system console (http://localhost:4502/system/console)

2. Stop the following bundles

• Adobe Granite Replication (com.day.cq.cq-replication)
• Apache Sling Event Support (org.apache.sling.event)

4. Open crx/de
5. Go to /etc/workflow/instances, clear everything under this folder. Yon can also move /etc/workflow/instances under /tmp and then create a new /etc/workflow/instances folder with the exact same properties of the original /etc/workflow/instances

5. Go to /var/eventing/jobs and delete all the content under it.

6. Go to /var/replication/data and Delete all the content under it.

7. Start the bundles stopped in step 2.

8. Now try running transient workflow.

That's It!

AEM author scalability key Parameters to be considered

Solution : Common approach for Application Scalability as follows:

- Vertical Scability
- Horizontal Scalability
- Data Partitioning



Bottlenecks and Priority 
1. LAN bandwidth, including WiFi
 2. Server Disk IO Individual spinning hard disks are not useful for large deployments. 
3. Server RAM Unused RAM improves Disk IO 
4. Server CPU

Note : 

• More Server Disk I/O = More performance
• More Server RAM = More Disk I/O Performance
• Vertical Scaling – More Effective than Horizontal Scaling

Refer the document from Adobe:

https://helpx.adobe.com/content/dam/help/en/experience-manager/kt/eseminars/gems/aem-author-scalability1/_jcr_content/main-pars/download_section/download-1/Experiments+in+AEM+Author+Scalability+2+7+18.pdf

AEM_Common_Security checklist for Production Server

Security checklist for AEM Production :

http://www.one-inside.com/wp-content/uploads/2015/10/CQCon_Presentation_Security-2.pdf

AEM Common_How to identify Slow running Queries.

Solution1: To identify the slow running queries.

1.       Download the Jar file of relevent Oak version of AEM server

https://files.acrobat.com/a/preview/8216d8ac-1367-4960-a200-6622d7044051

2. Execute the jar file from terminal/command prompt using below command 

java  -Xmx1024m -jar qla.jar

1.       Example for file at location "/adobe/ToolsDailyUsage/cq6/author/crx-quickstart/logs/error.log" the command is 

 java  -Xmx1024m -jar qla.jar "/adobe/ToolsDailyUsage/cq6/author/crx-quickstart/logs/error.log"

2.       The output of my instance is shown below

AEM Common_Create custom oak indexes for all frequently used search queries.

Recommendation

• Unlike Jackrabbit 2, Oak does not index content by default. Custom indexes need to be created when necessary, much like with traditional relational databases.
•  If there is no index for a specific query then the whole repository will be traversed. The query will still work but probably be very slow.
• If Oak encounters a query without an index, a WARN level log message is printed:

*WARN* Traversed 1000 nodes with filter Filter(query=select ...) consider creating an index or changing the query

• Create custom oak indexes for the all frequently used search queries.
• Create the custom indexes under the oak:index node for all search properties that you want to search
• For each custom Lucene-based index, try to set includedPaths (String[]) setting to restrict the index to only apply to certain content paths.  Then restrict applicable searches to those paths included by the index.

Solution1: To identify the slow running queries.

1.       Download the Jar file of relevent Oak version of AEM server

https://files.acrobat.com/a/preview/8216d8ac-1367-4960-a200-6622d7044051

2. Execute the jar file from terminal/command prompt using below command 

java  -Xmx1024m -jar qla.jar

1.       Example for file at location "/adobe/ToolsDailyUsage/cq6/author/crx-quickstart/logs/error.log" the command is 

 java  -Xmx1024m -jar qla.jar "/adobe/ToolsDailyUsage/cq6/author/crx-quickstart/logs/error.log"

2.       The output of my instance is shown below

Step 2: Create Custom Indexes to boost the performance of the search queries.

•      The Property Index
•      Order Index
•      Property Order Index, The Lucene Full Text Index