This page details Known Issues for Adobe’s AEM Forms as a Cloud Service offering. Although there are similarities with an on-prem solution, you lose a great deal of your autonomy with the Cloud Service and are much more reliant on Adobe performing administration configurations for you.

An Adobe AEM on-prem server has excellent Administrations tools and a flexible configuration model. We can create configuration files, OSGi configuration nodes, and override them with the highest level values in the Web Console Configuration tool. AEM as a Cloud Service does not come close to the same level of Administration tools that we have in the on-prem software. Notice in this screenshot that the Operations dashboard in the on-prem software (left) is missing from AEM as a Cloud Service (right).

Here are a few important tools missing from the Administration tools on AEM as a Cloud Service.

• The Operations Dashboard.
• Web Console Bundles.
• Web Console Configuration.
• The Day CQ Mail Service to configure SMTP.

Sandbox environments automatically enter hibernation mode (see illustration) when no activity is detected for more than eight hours. When this happens, users will see the Environment Hibernated message (see illustration) and we need to click Developer Console and de-hibernate the instance.

We can also see our environment in a Hiberated status in the Cloud Manager. Click the three ellipses and select De-hibernate to move the instance back to a running status. The process usually takes from 5 - 10 minutes to complete. We are not be able to access the instance until it completes.

AEM as a Cloud Service Sandbox environments do not support JDBC connections. Considering the importance of connecting forms and form data to databases this was a disappointing surprise. However, after reading Adobe's available documentation, and working with my AEM as a Cloud Service Sandbox environments, I have found this to be the case. Evidently, Adobe will custom configure something they call "Advanced networking" but my understanding is that only Adobe can configure this and it can only be done on a production instance of AEM as a Cloud Service.

If you only see the "Set up a sandbox" option (see illustration) when you create a new program, you will not be able to connect your AEM Forms with databases.

Unless and until we configure advanced networking, we must use REST and SOAP data sources that run on port 80. If we have AEM Forms Workbench REST and SOAP services running on port 8080, they will not work as data sources on AEM Forms as a Cloud Service. We will not receive any messages about this when we create the data sources. But we will receive an ERROR IN FETCHING DATASOURCE message in a Form Data Model based on one of these unsupported data sources.

The FSI-Customers Form Data Model is a popular out-of-the-box sample Form Data Model in AEM Forms. But it does not work on AEM Forms as a Cloud Service due to a missing JAR file. The Cloud instance is missing the derby-10.13.1.1.jar file that is available in the aemforms-refsite-common application in on-prem installations of AEM Forms (see illustration).

We can not install this application on AEM Forms as a Cloud Service because it is not supported at runtime.