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 Schnellstart-JAR-Datei nicht funktioniert und Sie vermuten, dass sie auf das Entfernen von Benutzeroberflächen aus der von AEM bereitgestellten as a Cloud Service zurückzuführen ist, 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. Entwickler können Code- oder Strukturprobleme effizient identifizieren, bevor sie sich zur Quell-Code-Verwaltung verpflichten. Dadurch werden Verzögerungen verhindert, die durch das Auslösen von Cloud Manager-Bereitstellungen verursacht werden. Dies kann länger dauern.

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 jedoch, die lokale AEM-Entwicklungsumgebung gelegentlich mit der neuesten SDK zu aktualisieren und dann das benutzerdefinierte Programm 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, die SDK häufig zu aktualisieren, z. B. alle zwei Wochen. Entsorgen Sie außerdem den vollständigen lokalen Status täglich, damit Sie sich nicht versehentlich auf statusbehaftete Daten in der Anwendung verlassen müssen.

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. Um die Wiederverwendung bei der Entwicklung zu vereinfachen, kann der AEM-Prozess jedoch beim ersten Starten mit "-Dcom.adobe.granite.crypto.file.disable=true" initialisiert werden. Dieser Prozess generiert die Verschlüsselungsdaten bei "/etc/key".

Wiederverwenden von Inhaltspaketen, die die verschlüsselten Werte enthalten: