¿Quién eliminó esa página en AEM as a Cloud Service?

¿Sabes quién eliminó esa página en AEM as a Cloud Service? A mí me tocó resolver este misterio en el trabajo, y me sorprendió lo poco intuitivo que resulta averiguarlo. En este artículo cuento el problema, el razonamiento que seguí y la solución paso a paso, para que la próxima vez que te pregunten "¿quién ha borrado esta página?" tengas la respuesta en cinco minutos.

El problema: AEM guarda silencio sobre las eliminaciones

AEM Sites es bastante transparente con el ciclo de vida de una página... hasta cierto punto. Desde la consola de Sites puedes ver sin problema:

• Quién creó la página (jcr:createdBy).
• Quién la modificó por última vez (cq:lastModifiedBy).
• Quién la publicó o despublicó (cq:lastReplicatedBy y las propiedades de replicación).

Pero cuando alguien la elimina... silencio. La página desaparece de la consola y con ella, aparentemente, cualquier rastro de quién ejecutó la acción.

Es cierto que no todo está perdido a nivel de contenido: puedes restaurar la página o consultar sus versiones anteriores. Eso sí, con un matiz importante:

Pero incluso cuando puedes restaurarla, en ningún lado de la interfaz aparece el responsable de la eliminación. Y a veces esa es exactamente la pregunta que te hacen: no "recupérame la página", sino "¿quién la borró y cuándo?".

El razonamiento: si se puede restaurar, tiene que estar en algún sitio

Aquí es donde entra la parte de detective. Mi razonamiento fue simple: si AEM es capaz de ofrecerte la restauración de una página eliminada, las páginas archivadas —y el registro de la acción— tienen que estar guardadas en algún lugar del repositorio JCR. La interfaz no lo enseña, pero el dato tiene que existir.

La pregunta era: ¿dónde mirar, si en AEM as a Cloud Service no tienes CRX/DE en producción?

La herramienta: Developer Console desde Cloud Manager

En AEMaaCS no puedes conectarte al repositorio de producción como lo hacías en las versiones on-premise. Pero Adobe proporciona una alternativa: la Developer Console, accesible desde Cloud Manager.

Los pasos:

1. Entra en Cloud Manager con tu usuario del entorno.
2. Localiza el entorno que te interesa — en mi caso, la instancia author de PROD, que es donde ocurren las acciones de autoría como las eliminaciones.
3. Abre la Developer Console de ese entorno.
4. Desde ahí puedes inspeccionar el repositorio de la instancia y navegar por sus rutas.

El premio: /var/audit

Navegando por el repositorio llegué a la ruta clave: /var/audit. Ahí es donde AEM guarda el registro de auditoría de las acciones sobre el contenido.

La estructura es bastante reconocible: bajo /var/audit encontrarás un árbol que replica las rutas de tus páginas, y colgando de cada ruta, nodos identificados por IDs que representan cada acción realizada sobre ella:

/var/audit
└── com.day.cq.wcm.core.page
    └── content
        └── mi-sitio
            └── es
                └── mi-pagina
                    ├── 1f3a9c72-...   ← una acción
                    ├── 8b21d5e0-...   ← otra acción
                    └── ...

Y en cada uno de esos nodos está todo lo que necesitas:

• El tipo de acción ejecutada (creación, modificación, eliminación...).
• La ruta afectada.
• Y, lo más importante: el usuario que realizó la acción ✅

Con eso, misterio resuelto: tipo de acción PageDeleted, ruta de la página, timestamp del evento y el usuario responsable. Exactamente la respuesta que nadie encontraba en la interfaz.

Detalles que conviene saber

Algunos matices que aprendí por el camino y que te pueden ahorrar tiempo:

• El audit log tiene su propio ámbito por tipo de evento. Bajo /var/audit verás ramas distintas según el componente que genera el evento (páginas de WCM, DAM, replicación...). Para eliminaciones de páginas, la rama de WCM es la que interesa.
• No es eterno. Los registros de auditoría son contenido del repositorio y están sujetos a las tareas de mantenimiento y purgado configuradas en la instancia. Si la eliminación ocurrió hace mucho, puede que el registro ya no exista — cuanto antes investigues, mejor.
• Complementa, no sustituye, a otras vías. Para acciones de replicación tienes los logs de replicación, y en AEMaaCS también puedes tirar de los logs del entorno vía Cloud Manager. Pero para responder "¿quién eliminó esta página?", /var/audit es la vía directa.

Conclusión

Lo que empezó como un misterio — una página desaparecida y ningún responsable a la vista — terminó siendo una lección sobre cómo funciona AEM por dentro: la interfaz no siempre enseña todo lo que el repositorio sabe. Si AEM puede restaurar una página eliminada, es porque guarda el rastro en algún sitio; solo hay que saber que ese sitio es /var/audit y que la Developer Console de Cloud Manager es tu puerta de entrada en AEMaaCS.

Espero que te sea útil o, al menos, que te resulte tan curioso como nos resultó a mi compañero y a mí cuando lo descubrimos 🤪