Sie sehen sich Hilfeinhalte der folgenden Version an:

Beim Planen einer Aktualisierung sollten folgende Bereiche der Implementierung untersucht und berücksichtigt werden.

Überblick

  1. Musterdetektor – Führen Sie den Musterdetektor aus, wie in der Aktualisierungsplanung und detailliert auf dieser Seite beschrieben, um einen Musterdetektorbericht zu erhalten, der weitere Informationen über Bereiche enthält, in denen zusätzlich zu den nicht verfügbaren APIs/Bundles in der Zielversion von AEM Probleme behoben werden müssen. Der Musterdetektorbericht liefert Hinweise auf alle Inkompatibilitäten in Ihrem Code. Wenn keine vorhanden sind, ist Ihre Bereitstellung bereits mit 6.4 kompatibel. Sie können für die Verwendung der 6.4-Funktionen neuen Code entwickeln. Aus Kompatibilitätsgründen ist dies jedoch nicht erforderlich. Wenn Inkompatibilitäten gemeldet werden, können Sie entweder a) das Ausführen im Kompatibilitätsmodus auswählen und Ihre Bereitstellung für neue 6.4-Funktionen oder die Kompatibilität zurückstellen oder b) nach der Aktualisierung neuen Code entwickeln und mit Schritt 2 fortfahren. Weitere Einzelheiten finden Sie im Beitrag zur Abwärtskompatibilität in AEM 6.4.


  2. Entwickeln einer Codebasis für 6.4 – Erstellen Sie eine dedizierte Verzweigung oder ein dediziertes Repository für die Codebasis der Zielversion. Nutzen Sie bei der Kompatibilitätsprüfung die vor der Aktualisierung erfassten Daten, um die Codebereiche zu planen, die aktualisiert werden sollen.
  3. Kompilieren mit 6.4 UberJar –Aktualisieren Sie die POM-Dateien der Codebasis, sodass diese auf 6.4 UberJar verweisen, und kompilieren Sie dann den Code.
  4. Aktualisieren von AEM-Anpassungen – Alle Anpassungen und Erweiterungen von AEM müssen aktualisiert/validiert werden, um in 6.4 zu funktionieren, und zur 6.4-Codebasis hinzugefügt werden. Dies beinhaltet UI-Suchformulare, Asset-Anpassungen und alle Komponenten, die „/mnt/overlay“ verwenden.
  5. Bereitstellung in der Umgebung von 6.4 – Eine neue Instanz von AEM 6.4 (Autor und Veröffentlichung) muss in einer Entwicklungs-/QA-Umgebung bereitgestellt werden. Stellen Sie die aktualisierte Codebasis und ein repräsentatives Inhaltsbeispiel (aus der aktuellen Produktion) bereit.
  6. QA-Validierung und Fehlerkorrektur – Die Anwendung muss auf der Autoren- und der Veröffentlichungsinstanz von 6.4 mit QA validiert werden. Korrigieren Sie die gefundenen Fehler und speichern Sie die Korrektur in der Codebasis von 6.4. Wiederholen Sie den Entwicklungszyklus, falls erforderlich, bis alle Fehler korrigiert sind.

Bevor Sie mit der Aktualisierung beginnen, benötigen Sie eine stabile Anwendungscodebasis, die sorgfältig gegen die Zielversion von AEM getestet wurde. Basierend auf den im Rahmen der Tests gemachten Beobachtungen kann möglicherweise der benutzerdefinierte Code optimiert werden. Dazu können die Umgestaltung des Codes zum Durchsuchen des Repositorys, die benutzerdefinierte Indizierung für optimierte Suchabfragen, die Verwendung von unsortierten Knoten in JCR und andere Optimierungen gehören.

AEM 6.4 bietet Ihnen die Option, Ihre Codebasis und Ihre Anpassungen für die Zusammenarbeit mit der neuen AEM-Version zu aktualisieren. Außerdem hilft Ihnen AEM 6.4, Ihre Anpassungen mit der Abwärtskompatibilitätsfunktion effizienter zu verwalten, was auf dieser Seite beschrieben wird.

Wie oben bereits erwähnt und im folgenden Diagramm dargestellt, hilft Ihnen das Ausführen des Musterdetektors im ersten Schritt, die gesamte Komplexität der Aktualisierung zu beurteilen und zu entscheiden, ob Sie den Kompatibilitätsmodus nutzen oder Ihre Anpassungen aktualisieren möchten, um alle neuen Funktionen von AEM 6.4 zu verwenden. Weitere Einzelheiten finden Sie auf der Seite Abwärtskompatibilität in AEM 6.4.

Aktualisieren der Codebasis

Erstellen einer dedizierten Verzweigung für 6.4-Code in der Versionskontrolle

Es empfiehlt sich, den Code und die Konfigurationen für die AEM-Implementierung in einer Versionskontrolle zu verwalten. Erstellen Sie eine dedizierte Verzweigung in der Versionskontrolle, um Änderungen an der Codebasis in der AEM-Zielversion zu verwalten. Iterative Tests der Codebasis für die Zielversion von AEM und anschließende Fehlerkorrekturen können in dieser Verzweigung verwaltet werden.

Aktualisieren der UberJar-Version von AEM

AEM-UberJar beinhaltet alle AEM-APIs als einzelne Abhängigkeiten in der Datei pom.xml des Maven-Projekts. Als beste Vorgehensweise empfiehlt es sich immer, UberJar als einzige Abhängigkeit anstelle von individuellen AEM-API-Abhängigkeiten zu verwenden. Bei der Aktualisierung der Codebasis sollte die UberJar-Version so geändert werden, dass sie auf die Zielversion von AEM verweist. Falls das Projekt mit einer Version von AEM entwickelt wurde, für die UberJar noch nicht verfügbar war, müssen alle individuellen AEM-API-Abhängigkeiten entfernt und durch eine einzige UberJar-Abhängigkeit für die Zielversion von AEM ersetzt werden. Kompilieren Sie dann die Codebasis erneut gegen die neue Version von UberJar. Alle veralteten APIs und Methoden müssen aktualisiert werden, um mit der Zielversion von AEM kompatibel zu sein.

<dependency>
    <groupId>com.adobe.aem</groupId>
    <artifactId>uber-jar</artifactId>
    <version>6.4.0</version>
    <classifier>apis</classifier>
    <scope>provided</scope>
</dependency>

Einstellen der Verwendung des administrativen Ressourcen-Resolver

Die Verwendung einer administrativen Session über SlingRepository.loginAdministrative() and ResourceResolverFactory.getAdministrativeResourceResolver() war bei Codebasen vor AEM 6.0 gängig. Diese Methode ist jedoch aus Sicherheitsgründen veraltet, da die Zugriffsstufe zu weit gefasst ist. In künftigen Versionen von Sling ist diese Methode nicht mehr enthalten. Es wird dringend empfohlen, stattdessen „Dienstbenutzer“ für den Code zu verwenden. Weitere Informationen zu Dienstbenutzern und dazu, wie Sie die Verwendung von administrativen Sessions einstellen, finden Sie hier.

Abfragen und Oak-Indizes

Abfragen in der Codebasis müssen im Rahmen der Aktualisierung sorgfältig getestet werden. Für Kunden, die von Jackrabbit 2 (ältere Versionen als AEM 6.0) aus eine Aktualisierung durchführen, ist dies besonders wichtig, da Inhalt von Oak nicht automatisch indiziert wird und möglicherweise benutzerdefinierte Indizes erstellt werden müssen. Falls Sie von einer AEM 6.x-Version aus eine Aktualisierung durchführen, haben sich die vorkonfigurierten Oak-Indexdefinitionen möglicherweise geändert, was sich auf vorhandene Abfragen auswirken kann.

Es sind mehrere Tools zum Analysieren und Überprüfen der Abfrageleistung verfügbar:

Klassisches UI-Authoring

Das klassische UI-Authoring ist in AEM 6.4 weiterhin verfügbar, ist jedoch veraltet. Weitere Informationen finden Sie hier. Falls die Anwendung derzeit in einer Umgebung mit klassischem UI-Authoring ausgeführt wird, wird empfohlen, auf AEM 6.4 zu aktualisieren und die klassische Benutzeroberfläche weiterhin zu verwenden. Die Migration zur Touch-optimierten Benutzeroberfläche kann als separates Projekt geplant und in mehreren Entwicklungszyklen abgeschlossen werden. Um die klassische Benutzeroberfläche in AEM 6.4 zu verwenden, sind mehrere OSGi-Konfigurationen erforderlich, die in der Codebasis gespeichert werden müssen. Einzelheiten zur Konfiguration finden Sie hier.  

Ausrichten auf die 6.4-Repository-Struktur

Um Aktualisierungen zu vereinfachen und um sicherzustellen, dass Konfigurationen nicht beim Aktualisieren überschrieben werden, wurde das Repository in 6.4 neu strukturiert, damit Inhalte und Konfiguration voneinander getrennt sind.
 

Aus diesem Grund müssen einige Einstellungen verschoben werden, damit sie sich nicht mehr wie bisher unter /etc befinden. Eine vollständige Aufstellung aller fraglichen Punkte zur Repository-Neustrukturierung, die bei der Aktualisierung auf AEM 6.4 überprüft und berücksichtigt werden müssen, finden Sie unter Repository-Neustrukturierung in AEM 6.4

AEM-Anpassungen

Alle Anpassungen der AEM-Authoring-Umgebung in der Quellversion von AEM müssen identifiziert werden. Sobald die Anpassungen identifiziert sind, wird empfohlen, diese in der Versionskontrolle oder als minimale Sicherungskopie als Teil eines Inhaltspakets zu speichern. Vor einer Produktionsaktualisierung müssen alle Anpassungen in einer QA- oder Staging-Umgebung bereitgestellt und validiert werden, die auf der Zielversion von AEM ausgeführt wird.  

Allgemeine Hinweise zu Überlagerungen

Es ist üblich, vorkonfigurierte AEM-Funktionen durch Überlagerung von Knoten und/oder Dateien unter /libs mit zusätzlichen Knoten unter /apps zu erweitern. Diese Überlagerungen sollten in der Versionskontrolle nachverfolgt und für die Zielversion von AEM getestet werden. Falls eine Datei (z. B. JS, JSP, HTL) überlagert wird, wird empfohlen, einen Kommentar mit Informationen zu speichern, welche Funktionalität erweitert wurde. Dies erleichtert Regressionstests auf der Zielversion von AEM. Weitere allgemeine Informationen zu Überlagerungen finden Sie hier. Anweisungen für spezifische AEM-Überlagerungen finden Sie unten.

Benutzerdefinierte Suchfacetten müssen nach der Aktualisierung teilweise manuell angepasst werden, damit sie ordnungsgemäß funktionieren. Weitere Einzelheiten finden Sie unter Aktualisieren von benutzerdefinierten Suchformularen.

Assets-UI-Anpassungen

Hinweis:

Dieses Verfahren ist nur für Aktualisierungen von Versionen vor AEM 6.2 erforderlich. 

Instanzen mit benutzerdefinierten bereitgestellten Assets müssen für die Aktualisierung vorbereitet werden. Damit soll sichergestellt werden, dass alle benutzerdefinierten Inhalte mit der neuen Knotenstruktur von AEM 6.4 kompatibel sind.

Sie können die Assets-UI-Anpassungen wie folgt vorbereiten:

  1. Öffnen Sie auf der zu aktualisierenden Instanz CRXDE Lite, indem Sie zu http://server:port/crx/de/index.jsp
    wechseln.

  2. Navigieren Sie zum folgenden Knoten:

    • /apps/dam/content
  3. Benennen Sie den Inhaltsknoten in content_backup um. Hierzu können Sie mit der rechten Maustaste auf den Explorer-Bereich links im Fenster klicken und Umbenennen auswählen.

  4. Wenn der Knoten umbenannt wurde, erstellen Sie unter /apps/dam den neuen Knoten content und legen Sie für den Knotentyp sling:Folder fest.

  5. Verschieben Sie alle untergeordneten Knoten von content_backup in den neu erstellten Knoten „content“. Hierzu können Sie mit der rechten Maustaste auf die einzelnen untergeordneten Knoten im Explorer-Bereich klicken und Verschieben auswählen.

  6. Löschen Sie den Knoten content_backup.

  7. Die aktualisierten Knoten unter /apps/dam mit dem richtigen Knotentyp sling:Folder sollten idealerweise in der Versionskontrolle gespeichert und mit der Codebasis oder als minimale Sicherungskopie eines Inhaltspakets bereitgestellt werden.

Generieren von Asset-IDs für vorhandene Assets

Um Asset-IDs für vorhandene Assets zu generieren, aktualisieren Sie diese, wenn Sie die AEM-Instanz auf AEM 6.4 aktualisieren. Dies ist erforderlich, um die Funktion Assets Insights zu aktivieren. Weitere Einzelheiten finden Sie unter Hinzufügen von Einbettungscode.

Um Assets zu aktualisieren, konfigurieren Sie das Paket „Associate Asset IDs“ in der JMX-Konsole. Je nach Anzahl der Assets im Repository kann das Ausführen von migrateAllAssets lange dauern. Internen Tests zufolge liegt der Schätzwert für TarMK bei einem Durchsatz von 125000 Assets pro Stunde.

1487758945977

Falls Sie Asset-IDs für eine Untermenge Ihrer gesamten Assets benötigen, verwenden Sie die API migrateAssetsAtPath.

Verwenden Sie für alle anderen Zwecke die API migrateAllAssets().

InDesign-Skript-Anpassungen

Adobe empfiehlt, benutzerdefinierte Skripte unter /apps/settings/dam/indesign/scripts abzulegen. Weitere Informationen zu InDesign-Skript-Anpassungen finden Sie hier.

Wiederherstellen von ContextHub-Konfigurationen

Aktualisierungen wirken sich auf ContextHub-Konfigurationen aus. Anweisungen, wie Sie vorhandene ContextHub-Konfigurationen wiederherstellen, finden Sie hier.  

Workflow-Anpassungen

Vorkonfigurierte Workflows werden häufig angepasst, um Funktionen hinzuzufügen oder nicht erforderliche Funktionen zu löschen. Der Workflow „DAM-Update-Asset“ ist ein typischer Workflow, der häufig angepasst wird. Erstellen Sie eine Sicherungskopie aller für eine angepasste Implementierung erforderlichen Workflows und speichern Sie diese in der Versionskontrolle, da sie möglicherweise bei einer Aktualisierung überschrieben werden.  

Bearbeitbare Vorlagen

Hinweis:

Dieses Verfahren ist nur für Site-Aktualisierungen, bei denen bearbeitbare Vorlagen aus AEM 6.2 verwendet werden, erforderlich.

Die Struktur bearbeitbarer Vorlagen in AEM 6.2 wurde in Version 6.3 geändert. Wenn Sie ein Upgrade von 6.2 oder älter durchführen und wenn Sie Site-Inhalt mit bearbeitbaren Vorlagen erstellt haben, müssen Sie das Responsive Nodes Clean Up-Tool verwenden. Das Tool muss nach einer Aktualisierung ausgeführt werden, um Inhalt zu bereinigen. Es muss auf der Autoren- und der Veröffentlichungsschicht ausgeführt werden.

Änderungen der CUG-Implementierung

Die Implementierung geschlossener Benutzergruppen (Closed User Groups, CUG) wurde weitgehend geändert, um die Leistungs- und Skalierbarkeitsbeschränkungen früherer AEM-Versionen zu beheben. Die vorherige Version von CUG ist in 6.3 nicht mehr enthalten. Die neue Implementierung wird nur in der Touch-optimierten Benutzeroberfläche unterstützt. Wenn Sie ein Upgrade von 6.2 oder früher durchführen, finden Sie hier eine Anleitung für das Migrieren zur neuen CUG-Implementierung.  

Testverfahren

Zum Testen von Aktualisierungen sollte ein umfassender Testplan erstellt werden. Das Testen der aktualisierten Codebasis und Anwendung muss zuerst in Umgebungen auf niedrigerer Ebene erfolgen. Alle Fehler müssen iterativ korrigiert werden, bis die Codebasis stabil ist. Aktualisieren Sie erst dann Umgebungen auf höherer Ebene.

Testen des Aktualisierungsverfahrens

Testen Sie das hier beschriebene Aktualisierungsverfahren in Entwicklungs- und QA-Umgebungen, wie im benutzerdefinierten Runbook dokumentiert (siehe Planung der Aktualisierung). Das Aktualisierungsverfahren muss wiederholt werden, bis alle Schritte im Aktualisierungs-Runbook dokumentiert sind und das Aktualisierungsverfahren reibungslos läuft.

Testbereiche der Implementierung

Im Folgenden sind wichtige Bereiche einer AEM-Implementierung genannt, die vom Testplan abgedeckt sein müssen, sobald die Umgebung aktualisiert und die aktualisierte Codebasis bereitgestellt wurde.

Funktioneller Testbereich Beschreibung
Veröffentlichte Websites Testen von AEM-Implementierung und zugehörigem Code auf der Veröffentlichungsschicht
durch den Dispatcher. Muss Kriterien für Seitenaktualisierungen und
Cache-Invalidierungen enthalten.
Authoring Testen von AEM-Implementierung und zugehörigem Code auf der Autorenschicht. Dabei sollten Seiten, Komponenten-Authoring und Dialoge berücksichtigt werden.
Integrationen mit Marketing Cloud-Lösungen Validieren von Integrationen mit Analyseprodukten wie Analytics, DTM und Target.
Integrationen mit Drittanbietersystemen Drittanbieter-Integrationen müssen auf der Autoren- und Veröffentlichungsschicht validiert werden.
Authentifizierung, Sicherheit und Berechtigungen Alle Authentifizierungsmechanismen wie LDAP/SAML müssen validiert werden.
Berechtigungen und Gruppen müssen auf der Autoren- und der Veröffentlichungsschicht
getestet werden.
Abfragen Benutzerdefinierte Indizes und Abfragen müssen zusammen mit der Abfrageleistung getestet werden.
UI-Anpassungen Alle Erweiterungen und Anpassungen der AEM-Benutzeroberfläche in der Autorenumgebung.
Workflows Benutzerdefinierte und/oder vorkonfigurierte Workflows und Funktionen.
Leistungstests Lasttests müssen auf der Autoren- und Veröffentlichungsschicht erfolgen und echte Szenarien simulieren.

Dokumentieren von Testplänen und Ergebnissen

Erstellen Sie einen Testplan, der die oben genannten Testbereiche der Implementierung abdeckt. In vielen Fällen ist es sinnvoll, den Testplan nach Aufgabenlisten für Autoren- und Veröffentlichungsumgebungen zu trennen. Dieser Testplan muss auf Entwicklungs-, QA- und Staging-Umgebung ausgeführt werden, bevor Produktionsumgebungen aktualisiert werden. Erfassen Sie die Testergebnisse und Leistungsmetriken aus Umgebungen niedrigerer Ebenen als Referenzwerte für die Aktualisierung der Staging- und Produktionsumgebungen.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie