Das AEM as a Cloud Service-SDK aem-as-a-cloud-service-sdk

Das AEM as a Cloud Service-SDK besteht aus den folgenden Artefakten:

Darüber hinaus werden manche Kundinnen und Kunden, die zuvor AEM 6.5 oder frühere Versionen bereitgestellt haben, die unten stehenden Artefakte verwenden. Wenn die lokale Kompilierung mit der Quickstart-JAR nicht funktioniert und Sie vermuten, dass dies auf die Entfernung von Schnittstellen aus AEM zurückzuführen ist, das als Cloud-Service bereitgestellt wird, wenden Sie sich an den Kunden-Support. Sie können feststellen, ob Sie Zugang benötigen. Dies erfordert Änderungen im Backend.

Erstellen für das SDK building-for-the-sdk

Das AEM as a Cloud Service-SDK wird zum Erstellen und Bereitstellen von benutzerdefiniertem Code verwendet. Siehe die Dokumentation zum AEM-Projektarchetyp. Im Allgemeinen werden die folgenden Schritte ausgeführt:

Cloud Manager führt dieselben Schritte bei der Bereitstellung in Cloud-Umgebungen aus. Die lokale Durchführung von Builds ermöglicht eine lokale Entwicklung und Prüfung. Entwicklerinnen und Entwickler können Code- oder Strukturprobleme effizient erkennen, bevor sie in die Versionskontrolle übernommen werden. Dadurch werden Verzögerungen verhindert, die durch das Auslösen von Cloud Manager-Bereitstellungen verursacht werden, die länger dauern können.

Zugriff auf das AEM as a Cloud Service-SDK accessing-the-aem-as-a-cloud-service-sdk

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

Aktualisieren eines lokalen Projekts mit einer neuen SDK-Version refreshing-a-local-project-with-a-new-skd-version

Wann sollte das lokale Projekt mit einem neuen SDK aktualisiert werden?

Adobe empfiehlt die Aktualisierung nach einer monatlichen Wartungsversion.

Es ist optional, nach jeder täglichen Wartungsversion zu aktualisieren. Kundinnen und Kunden werden darüber informiert, wenn ihre Produktionsinstanz erfolgreich auf eine neue AEM-Version aktualisiert wurde. Bei den täglichen Wartungsversionen ist nicht zu erwarten, dass sich das neue SDK erheblich verändert hat (wenn überhaupt). Adobe empfiehlt dennoch, die lokale AEM-Entwicklungsumgebung gelegentlich mit dem neuesten SDK zu aktualisieren und benutzerspezifische Programme neu zu erstellen und zu testen. Die monatliche Wartungsversion umfasst in der Regel wirkungsvollere Änderungen, sodass Entwicklerinnen und Entwickler umgehend aktualisieren, neu erstellen und testen sollten.

So aktualisieren Sie ein lokales Projekt mit einer neuen SDK-Version:

Wenn es Inhalte gibt, die mit jeder neuen AEM-Schnellstartversion installiert werden sollen, fügen Sie sie in einem Inhaltspaket und der Quell-Code-Verwaltung des Projekts hinzu. Installieren Sie sie dann jedes Mal.

Adobe empfiehlt, das SDK häufig zu aktualisieren, z. B. alle zwei Wochen. Entsorgen Sie außerdem täglich den ganzen lokalen Status, um in der Anwendung nicht versehentlich von Stateful-Daten abzuhängen.

Wenn Sie CryptoSupport für Cloud-Services, die SMTP-Mail-Konfiguration oder die CryptoSupport-API verwenden, werden verschlüsselte Eigenschaften mit einem Schlüssel gesichert. Weitere Informationen finden Sie in der Dokumentation zur CryptoSupport-API. Dieser Schlüssel wird beim ersten Start einer AEM-Umgebung automatisch generiert. Während die Cloud-Implementierung dafür sorgt, dass der umgebungsspezifische CryptoKey automatisch wiederverwendet wird, muss der CryptoKey in die lokale Entwicklungsumgebung injiziert werden.

Standardmäßig ist AEM so konfiguriert, dass die Schlüsseldaten im Datenordner eines Ordners gespeichert werden. Im Sinne einer einfacheren Wiederverwendung in der Entwicklung kann der AEM-Prozess beim ersten Start mit „-Dcom.adobe.granite.crypto.file.disable=true“ initialisiert werden. Dieser Vorgang erzeugt die Verschlüsselungsdaten bei „/etc/key“.

So verwenden Sie Inhaltspakete wieder, die die verschlüsselten Werte enthalten: