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.
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.