Debugging AEM as a Cloud Service with the Developer Console
AEM as a Cloud Service provides a Developer Console for each environment that exposes various details of the running AEM service that are helpful in debugging.
Each AEM as a Cloud Service environment has it's own Developer Console.
Developer Console access
To access and use the Developer Console the following permissions must be given to the developer's Adobe ID via Adobe's Admin Console .
- Ensure the Adobe Org that has effected Cloud Manger and AEM as a Cloud Service products is active in the Adobe Org switcher.
- The developer must be a member of the Cloud Manager Product's Developer - Cloud Service Product Profile.
- If this membership does not exist, the developer will not be able to log in to Developer Console.
- The developer must be a member of the AEM Author and Publish service's AEM Administrators Product Profile.
- If this membership does not exist, the status dumps will timeout with a 401 Unauthorized error.
Troubleshooting Developer Console access
AEM as a Cloud Service Author and Publish services are comprised of multiple instances respectively in order to handle traffic variability and rolling updates without downtime. These instances are referred to as Pods. Pod selection in Developer Console defines the scope of data that will exposed via the other controls.
- A pod is a discrete instance that is part of an AEM Service (Author or Publish)
- Pods are transient, meaning AEM as a Cloud Service creates and destroys them as need
- Only pods that are part of the associated AEM as a Cloud Service environment, are listed that environment's Developer Console's Pod switcher.
- At the bottom of the Pod switcher, convenience options allow for selecting Pods by service type:
- All Authors
- All Publishers
- All Instances
Status provides options for outputting specific AEM runtime state in text or JSON output. The Developer Console provides similar information as the AEM SDK's local quickstart's OSGi Web console, with the marked difference that Developer Console is read-only.
Bundles lists all OSGi bundles in AEM. This functionality is similar to AEM SDK's local quickstart's OSGi Bundles at /system/console/bundles .
Bundles help in debugging by:
- Listing all OSGi bundles deployed to AEM as a Service
- Listing each OSGi bundle's state; including if they are active or not
- Providing details into unresolved dependencies that cause OSGi bundles from becoming active
Components lists all the OSGi components in AEM. This functionality is similar to AEM SDK's local quickstart's OSGi Components at /system/console/components .
Components help in debugging by:
- Listing all OSGi components deployed to AEM as a Cloud Service
- Providing each OSGi component's state; including if they are active or unsatisfied
- Providing details into unsatisfied service references may cause OSGi components from becoming active
- Listing OSGi properties and their values bound to the OSGi component
Configurations lists all the OSGi component's configurations (OSGi properties and values). This functionality is similar to AEM SDK's local quickstart's OSGi Configuration Manager at /system/console/configMgr .
Configurations help in debugging by:
- Listing OSGi properties and their values by OSGi component
- Locating and identifying misconfigured properties
Oak Indexes provide a dump of the nodes defined beneath /oak:index . Keep in mind this does not show merged indexes, which occurs when an AEM index is modified.
Oak Indexes help in debugging by:
- Listing all Oak Index definitions providing insights into how search queries are executed in AEM. Keep in mind, that modified to AEM indexes are not reflected here. This view is only helpful for indexes that are solely provided by AEM, or solely provided by the custom code.
Components lists all the OSGi services. This functionality is similar to AEM SDK's local quickstart's OSGi Services at /system/console/services .
OSGi Services help in debugging by:
- Listing all OSGi services in AEM, along with its providing OSGi bundle, and all OSGi bundles that consume it
Sling Jobs lists all the Sling Jobs queues. This functionality is similar to AEM SDK's local quickstart's Jobs at /system/console/slingevent .
Sling Jobs help in debugging by:
- Listing of Sling Job queues and their configurations
- Providing insights into the number of active, queued and processed Sling jobs, which is helpful for debugging issues with Workflow, Transient Workflow and other work performed by Sling Jobs in AEM.
Java Packages allows checking if a Java package, and version, are available for use in AEM as a Cloud Service. This functionality is the same as AEM SDK's local quickstart's Dependency Finder at /system/console/depfinder .
Java Packages is used to trouble shoot Bundles not be starting because of unresolved imports, or unresolved classes in scripts (HTL, JSP, etc). If Java Packages reports no bundles export a Java package (or the version does not match that imported by an OSGi bundle):
- Ensure your project's AEM API maven dependency's version matches the environment's AEM Release version (and if possible, update everything to the latest).
- If extra Maven dependencies are used in the Maven project
- Determine if an alternative API provided by the AEM SDK API dependency can be used instead.
- If the extra dependency is required, ensure it's provide as an OSGi bundle (rather than a plain Jar) and it is embedded in your project's code package, ( ui.apps ), similar to how the core OSGi Bundle is embedded in the ui.apps package.
Servlets is used to provide insight as to how AEM resolves a URL to a Java servlet or script (HTL, JSP) that ultimately handles the request. This functionality is the same as AEM SDK's local quickstart's Sling Servlet Resolver at /system/console/servletresolver .
Servlets helps in debugging determining:
- How a URL is decomposed into its addressable parts (resource, selector, extension).
- What servlet or script a URL resolves to, helping identify mal-formed URLs or mis-registered servlets/scripts.
Queries help provide insights into what and how search queries are executed on AEM. This functionality is the same as AEM SDK's local quickstart's Tools > Query Performance console.
Queries only works when a specific pod is selected, as it opens that pod's Query Performance web console, requiring the developer to have access to log into the AEM service.
Queries helps in debugging by:
- Explaining how queries are interpreted, analyzed and executed by Oak. This is very important when tracking why a query is slow, and understanding how it can be sped up.
- Listing the most popular queries running in AEM, with the ability to Explain them.
- Listing the slowest queries running in AEM, with the ability to Explain them.