El AEM como un SDK de Cloud Service

El SDK de AEM como Cloud Service consta de los siguientes artefactos:

• Jar de inicio rápido: el tiempo de ejecución de AEM utilizado para el desarrollo local
• Java API Jar : la dependencia Java Jar/Maven que expone todas las API de Java permitidas que se pueden usar para desarrollarse contra AEM como Cloud Service. Anteriormente denominado Uberjar
• Javadoc Jar - Los javadocs para la API de Java Jar
• Herramientas de despachante: conjunto de herramientas utilizadas para desarrollar con Dispatcher localmente. Objetos independientes para unix y ventanas

Además, algunos clientes que se implementaron anteriormente con AEM 6.5 o versiones anteriores utilizarán los artefactos siguientes. Si la compilación local no funciona con el tarro de inicio rápido y sospecha que se debe a interfaces que se han eliminado de AEM implementadas como Cloud Service, póngase en contacto con el servicio de asistencia al cliente para determinar si necesita acceso. Esto requerirá cambios en el servidor.

• 6.5 Jar de API de Java obsoleto: un conjunto adicional de interfaces que se han eliminado desde AEM 6.5
• 6.5 Javadoc Jar desaprobado: el Javadocs para el conjunto adicional de interfaces

Generación para el SDK

El SDK de AEM como Cloud Service se utiliza para generar e implementar código personalizado. Para obtener más información, consulte la documentación del arquetipo del proyecto de AEM. En un nivel superior, se realizan los siguientes pasos:

• Compile código. Como se espera, se compila el código fuente, generando los paquetes de contenido resultantes
• Crear artefactos. Los artefactos se crean durante este proceso
• Analizar paquetes. Los paquetes se analizan mediante el complemento del analizador de Maven, que busca problemas en el proyecto de Maven, como la falta de dependencias
• Implementar artefactos. Los artefactos se implementan en el servidor local.

Cloud Manager ejecuta los mismos pasos al implementar en Entornos de nube. La realización de compilaciones localmente permite el desarrollo local y la realización de pruebas para que los desarrolladores puedan detectar de forma eficaz problemas estructurales o de código antes de comprometerse con el control de código fuente y activar las implementaciones de Cloud Manager, que pueden tardar más.

Acceso al AEM como SDK de Cloud Service

• Puede consultar el icono del Admin Console de AEM Acerca de Adobe Experience Manager para averiguar la versión de AEM que está ejecutando en producción.
• El archivo jar y Dispatcher Tools de inicio rápido se pueden descargar como archivo zip desde el Portal de distribución de software. Tenga en cuenta que el acceso a los listados de SDK está limitado a aquellos con AEM Managed Services o AEM como entornos de Cloud Service.
• El Jar de la API de Java y Javadoc Jar se pueden descargar mediante herramientas muevas, ya sea con la línea de comandos o con su IDE preferido.
• Las páginas de proyecto principales deben hacer referencia al siguiente paquete de Jar de API. Esta dependencia también se debe hacer referencia a ella en cualquier página de subpaquete.

<dependency>
  <groupId>com.adobe.aem</groupId>
  <artifactId>aem-sdk-api</artifactId>
  <version>2019.11.3006.20191108T223635Z-191201</version>
  <scope>provided</scope>
</dependency>

Actualización de un proyecto local con una nueva versión del SDK

¿Cuándo se recomienda actualizar el proyecto local con un nuevo SDK?

Se recomienda actualizarla al menos después de una revisión de mantenimiento mensual.

Es opcional actualizarla después de cualquier revisión de mantenimiento diaria. Se informará a los clientes cuando la instancia de producción se haya actualizado correctamente a una nueva versión de AEM. Para las versiones de mantenimiento diarias, no se espera que el nuevo SDK haya cambiado significativamente, si es que ha cambiado. Sin embargo, se recomienda actualizar ocasionalmente el entorno de desarrollador de AEM local con el SDK más reciente y, a continuación, volver a compilar y probar la aplicación personalizada. La versión de mantenimiento mensual generalmente incluye cambios más impactantes y, por lo tanto, los desarrolladores deben actualizar, reconstruir y probar inmediatamente.

A continuación se muestra el procedimiento recomendado para actualizar un entorno local:

1. Asegúrese de que cualquier contenido útil esté comprometido con el proyecto en el control de código fuente o disponible en un paquete de contenido mutable para su posterior importación
2. El contenido de la prueba de desarrollo local debe almacenarse por separado para que no se implemente como parte de la compilación del flujo de Cloud Manager. Esto se debe a que sólo se debe usar para el desarrollo local
3. Detener el inicio rápido que se está ejecutando
4. Mover la carpeta crx-quickstart a otra carpeta para protegerla
5. Tenga en cuenta la nueva versión de AEM, que se indica en Cloud Manager (se utilizará para identificar la nueva versión de Jar de QuickStart para descargar más adelante)
6. Descargue el JAR de QuickStart cuya versión coincida con la versión de AEM de producción desde el portal de distribución de software
7. Cree una nueva carpeta y coloque la nueva barra de inicio rápido dentro
8. Inicio el nuevo inicio rápido con los modos de ejecución deseados (ya sea cambiando el nombre del archivo o pasando los modos de ejecución a través de -r).
   • Asegúrese de que no quede nada del inicio rápido anterior en la carpeta.
9. Cree la aplicación AEM
10. Implementar la aplicación AEM en AEM local mediante PackageManager
11. Instale los paquetes de contenido mutable necesarios para las pruebas de entorno locales mediante PackageManager
12. Continúe con el desarrollo e implemente los cambios según sea necesario

Si hay contenido que debe instalarse con cada nueva versión AEM de inicio rápido, inclúyalo en un paquete de contenido y en el control de código fuente del proyecto. A continuación, instálela cada vez.

La recomendación es actualizar el SDK con frecuencia (por ejemplo, cada dos semanas) y disponer de un estado local completo todos los días para no depender accidentalmente de los datos de estado de la aplicación.

En caso de que dependa de CryptoSupport (configurando las credenciales de Cloudservices o del servicio de correo SMTP en AEM o utilizando la API CryptoSupport en su aplicación), las propiedades cifradas se cifrarán con una clave que se genere automáticamente en el primer inicio de un entorno AEM. Aunque la configuración de nube se encarga de reutilizar automáticamente la clave CryptoKey específica del entorno, es necesario inyectar la clave criptográfica en el entorno de desarrollo local.

De forma predeterminada, AEM está configurado para almacenar los datos clave dentro de la carpeta de datos de una carpeta, pero para facilitar su reutilización en el desarrollo, el proceso de AEM se puede inicializar al iniciar por primera vez con "-Dcom.adobe.granite.crypto.file.disable=true". Esto generará los datos de cifrado en "/etc/key".

Para poder reutilizar paquetes de contenido que contengan los valores cifrados, debe seguir estos pasos:

• Cuando inicialmente inicio el archivo local quickstart.jar, asegúrese de agregar el parámetro siguiente: "-Dcom.adobe.granite.crypto.file.disable=true". Se recomienda, pero es opcional, agregarla siempre.
• La primera vez que inició una instancia, cree un paquete que contenga un filtro para la raíz "/etc/key". Esto mantendrá el secreto para que se reutilice en todos los entornos para los que se desea que se reutilicen
• Exporte cualquier contenido mutable que contenga secretos o busque los valores cifrados mediante /crx/de para agregarlos al paquete que se reutilizará en todas las instalaciones
• Siempre que gire una instancia nueva (ya sea para reemplazarla con una nueva versión o cuando varios entornos de desarrollo deben compartir las credenciales para la prueba), instale el paquete producido en los pasos 2 y 3 para poder reutilizar el contenido sin necesidad de volver a configurarlo manualmente. Esto se debe a que ahora la criptoclave está sincronizada.