Show Menu
TEMAS×

The AEM as a Cloud Service SDK

El SDK de AEM como Cloud Service consta de los siguientes artefactos:
  • Jar de inicio rápido: 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 Java API Jar
  • Herramientas de Dispatcher: conjunto de herramientas que se utilizan para desarrollar con Dispatcher localmente. Objetos independientes para unix y ventanas
Además, algunos clientes que se implementaron previamente 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 Java API Jar , un conjunto adicional de interfaces que se han eliminado desde AEM 6.5
  • 6.5 Javadoc Jar desaprobado: los javadocs para el conjunto adicional de interfaces

Acceso a AEM como SDK de Cloud Service

  • Puede consultar el icono Acerca del Adobe Experience Manager de AEM Admin Console para conocer la versión de AEM que está ejecutando en producción.
  • El archivo jar de inicio rápido y las herramientas de Dispatcher 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 los que tienen AEM Managed Services o AEM como entornos 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>

La entrada de versión del SDK debe coincidir con la versión de AEM como Cloud Service. Puede ver qué versión está utilizando si inicia sesión en AEM, luego va al signo de interrogación en la esquina superior derecha de la pantalla y selecciona Acerca de Adobe Experience Manager

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 versión de mantenimiento mensual.
Es opcional actualizarla después de cualquier revisión de mantenimiento diaria. Se informará a los clientes cuando su 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 crx-quickstart carpeta a otra carpeta para protegerla
  5. Tenga en cuenta la nueva versión de AEM, que se indica en Cloud Manager (esto se utilizará para identificar la nueva versión de Jar de QuickStart para seguir descargándola)
  6. Descargue el JAR de inicio rápido 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 su aplicación de AEM
  10. Implementar la aplicación de 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 de inicio rápido de AEM, 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 ( ya sea configurando las credenciales de Cloudservices o el servicio de correo SMTP en AEM o utilizando la API de CryptoSupport en la aplicación ), las propiedades cifradas se cifrarán con una clave que se genere automáticamente en el primer inicio de un entorno de 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 en 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 agregarlo 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.