AEM as a Cloud Service – Part 1

Some of the Benefits of moving to AEMaaCS

• As per Adobe documentation, AEM as a Cloud Service provides a continuous delivery pipeline for the AEM codebase using CI/CD pipeline. It provides automatic updates with zero downtime. This gives an advantage of keeping you on the most recent version.

• It will deliver content quickly and efficiently, by using a built-in Content Delivery Network (CDN).

• It also uses automated tests to scan for common vulnerabilities.

How to update code for AEMaaCS deprecated features?

• OSGi bundles and settings must be repository-based:- In AEMaaCS Felix Console access is not available, so no configuration can be done using system/console. So configuration must be a part of the codebase for AEMaaCS. These configurations will be auto-deployed when the codebase is build. 

• Custom runmodes are not allowed:- In earlier AEM versions, we can have multiple runmodes as per our need but in AEMaaCS custom run modes can’t be created. In AEMaaCS, There are runmodes that are provided out-of-the-box for AEM Cloud Service.
  These are-
  dev, stage, prod. 

So if your current code has some other configs as well then please remove these configs. 

• Removal of Replication Agents:- In AEMaaCS, content is published using Sling Content Distribution. The replication agents used in previous versions of AEM will no longer be used. If existing code has some custom transport handler for syncing content to some third party server for ex, if you are syncing content on an external search server then this custom transport handler code will not work. Here you need to write the EventHandler. 

• Removal of Classic UI:- The Classic UI is no longer available in AEMaaCS. If your code has some classic UI components then it is mandatory to change these components into touch UI components. Adobe provide Dialog conversion Tool for converting classic UI dialog to touch UI dialog, but it will not work for any custom logic written in the classic dialog. 

Moving to AEM as Cloud Service

The very first step in moving to AEMasCS is to check your existing code whether it is compatible to be used in AEMasCS or if it needs some refactoring. For this you have to check your current AEM codebase whether it is compatible. For this, you can do by running the Best Practices Analyzer on your current AEM version.

What is a Best Practices Analyser(BPA)?

This tool generates a report that identifies areas which need to be refactored. The BPA generates report with the help of Pattern Detector.

The BPA report consist the following :

• The existing functionality that needs to be changed.
• Repository items that must be moved to a supported location
• Classic dialogs and components that must be changed to touch UI.
• OSGI configuration issues
• AEM 6.x features that are not supported on AEMaaCS.

Important Things for Using BPA

1. BPA can only be run by the admin user or a user in the administrators group.

2. BPA is supported on AEM instances with version 6.1 and above.

3. As per Adobe documentation, BPA can run on any environment, but it is preferred to run on a Stage environment on author instance.

How to run BPA?

1. Go to AEM Home → Tools→  Operations →  Best Practices Analyzer.

2. Click on Generate Report to execute the Best Practices Analyzer.

3. 3. Generated BPA report gives the findings on the basis of the importance level as shown below. These are INFO, ADVISORY, MAJOR, CRITICAL.

4. You can download the report in a CSV format by clicking on Export to CSV with a default name result.csv, as shown in the figure above. You can click on Refresh Report to regenerate the report by clearing its cache.

We can also get the report in csv, json and tsv format by the given url below.
URL :- http://<host>/apps/best-practices-analyzer/analysis/report.<format>

@Reference