Repository-Neustrukturierung für alle Lösungen in AEM 6.4

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

Alle neuen oder geänderten Workflow-Modelle müssen nach /conf/global/workflow/models migriert werden.

1. Stellen Sie die geänderten Workflow-Modelle in einer lokalen AEM 6.4-Entwicklungsinstanz bereit, sodass sie im vorherigen Speicherort vorhanden sind.
2. Bearbeiten Sie das Workflow-Modell unter Verwendung des Editors für AEM Workflow-Modelle unter „AEM > Tools > Workflow > Modelle“.
3. Migration von modifizierten, von AEM bereitgestellten Workflow-Modellen
   1. Öffnen Sie den Editor für Workflow-Modelle, ändern Sie die Browser-URL und ersetzen Sie das Pfadsegment /libs/settings/workflow/models durch /etc/workflow/models.
      • Ändern Sie beispielsweise: http://localhost:4502/editor.html/libs/settings/workflow/models/dam/update_asset.html in http://localhost:4502/editor.html/etc/workflow/models/dam/update_asset.html
4. Aktivieren Sie den Bearbeitungsmodus im Editor für Workflow-Modelle, wodurch die Definition des Workflow-Modells nach /conf/global/workflow/models kopiert wird.
5. Tippen Sie auf die Synchronisierungsschaltfläche, um die Änderungen am Laufzeit-Workflow-Modell unter /var/workflow/models zu synchronisieren.
6. Exportieren Sie sowohl das Workflow-Modell (/conf/global/workflow/models/<Workflow-Modell>?lang=de) als auch das Laufzeit-Workflow-Modell (/var/workflow/models/<Workflow-Modell>?lang=de) und integrieren Sie beide in das AEM-Projekt.
   1. Zum Beispiel, exportieren Sie:
      • /config/settings/workflow/models/dam/my_workflow_model und
      • /var/workflow/models/dam/my_workflow_model

Die Auflösung des Workflow-Modells geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/workflow/models
2. /libs/settings/workflow/models
3. /etc/workflow/models

Daher müssen alle Anpassungen zu den von AEM bereitgestellten Workflow-Modellen, die am vorherigen Speicherort bestehen bleiben, nach /conf/global/settings/workflow/models verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Modells in /libs/settings/workflow/models ersetzt.

Für die Anpassung an den neuen Speicherort ist keine Aktion erforderlich.

Bisherige Workflow-Instanzen können weiterhin am vorherigen Speicherort erhalten bleiben und neue Workflow-Instanzen werden am neuen Speicherort erstellt.

/libs/settings/workflow/launcher/config

/conf/global/settings/workflow/launcher/config

Jeder neue oder modifizierte Workflow-Starter muss nach /conf/global/workflow/launcher/config migriert werden.

1. Kopieren Sie alle neuen oder geänderten Workflow-Starter Konfigurationen vom bisherigen Speicherort an den neuen Speicherort (/conf/global).

Die Auflösung des Workflow-Starters geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/workflow/launcher
2. /libs/settings/workflow/launcher
3. /etc/workflow/launcher

Daher müssen alle Anpassungen zu von AEM bereitgestellten Workflow-Startern, die am vorherigen Speicherort bestehen bleiben, an den neuen Speicherort (/conf/global/settings/workflow/launcher) verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Starters in /libs/settings/workflow/launcher ersetzt.

/libs/workflow/scripts

/apps/workflow/scripts

Alle neuen oder geänderten Workflow-Skripte müssen an den neuen Speicherort migriert werden und referenzierte Workflow-Modelle müssen migriert werden, sodass sie den neuen Speicherort enthalten.

1. Kopieren Sie jedes neue oder modifizierte Workflow-Skript vom vorherigen Speicherort zum neuen Speicherort.
   
   • /apps/workflow/scripts sollte in SCM gepflegt werden.
2. Aktualisieren Sie alle Verweise auf die Workflow-Skripte in den Workflow-Modellen am vorherigen Speicherort, sodass sie auf die neuen Speicherorte verweisen.

Nach der Veröffentlichung von AEM 6.4 SP1 ist es möglich, die Restrukturierung bis Version 6.5 zu verschieben upgrade .

Wenn Sie auf AEM 6.4 aktualisieren möchten, bevor AEM 6.4 SP1 veröffentlicht wurde, sollte diese Neustrukturierung als Teil der Aktualisierung ausgeführt werden. Ohne das Bearbeiten und Abspeichern von Workflow-Schritten werden die Referenz-Skripte vom vorherigen Speicherort vollständig aus den Workflow-Schritten entfernt und nur die Workflow-Schritte vom neuen Speicherort sind in der Dropdown-Liste „Skriptauswahl“ verfügbar.

/libs/settings/cloudsettings

/conf/global/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

Alle neuen oder modifizierten ContextHub Konfigurationen müssen an den neuen Speicherort migriert werden und die referenzierenden AEM Sites-Seiten müssen so aktualisiert werden, dass sie den neuen Speicherort enthalten.

1. Kopieren Sie alle neuen oder modifizierten ContextHub-Konfigurationen vom vorherigen Speicherort zum neuen Speicherort.
2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
3. Trennen Sie alle migrierten ContextHub-Konfigurationen von den oben aufgeführten AEM-Inhaltshierarchien.

/libs/settings/wcm/designs/cloudservices

/apps/settings/wcm/designs/cloudservices

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. .

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

/libs/settings/wcm/designs/dashboards

/apps/settings/wcm/designs/dashboards

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. .

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

/libs/settings/wcm/designs/reports

/apps/settings/wcm/designs/reports

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. .

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

/libs/settings/wcm/designs/default

/apps/settings/wcm/designs/default

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. .

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

Es ist keine Aktion erforderlich.

Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort.

Es ist keine Aktion erforderlich.

Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort.

Für die Migration von Aufgaben an den neuen Speicherort sind keine Maßnahmen erforderlich.

• Aufgaben, die am vorherigen Speicherort vorhanden sind, sind weiterhin verfügbar und funktionieren.
• Neue Aufgaben werden im neuen Speicherort erstellt.

/libs/msm

/apps/msm

1. Kopieren Sie benutzerdefinierte Konfigurationen von /etc/blueprints nach /apps/msm.
2. Remove /etc/blueprints.

/libs/cq/core/content/projects/dashboard/gadgets

/apps/cq/core/content/projects/dashboard/gadgets

Alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte müssen an den neuen Speicherort (/apps) migriert werden.

1. Kopieren Sie alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte vom vorherigen an den neuen Speicherort (/apps).
   1. Kopieren Sie keine unmodifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte, da diese bereits am neuen Speicherort (/libs) existieren.
2. Aktualisieren Sie alle AEM-Projektvorlagen, die auf den vorherigen Speicherort verweisen, sodass sie auf den neuen Speicherort verweisen.

/libs/settings/notification-templates/com.day.cq.replication

/apps/settings/notification-templates/com.day.cq.replication

Alle neuen oder modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung müssen an den neuen Speicherort (/apps) migriert werden.

1. Kopieren Sie alle neuen oder modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort an den neuen Speicherort (/apps).
2. Entfernen Sie alle migrierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort.

Die einzigen neuen unterstützten E-Mail-Vorlagen für die Replikationsbenachrichtigung sind solche, die neue Lokalisationen unterstützen.

Die Auflösung für die E-Mail-Vorlage für die Replikationsbenachrichtigung geschieht in der folgenden Reihenfolge:

1. /etc/notification/email/default/com.day.cq.replication
2. /apps/settings/notification-templates/com.day.cq.replication
3. /libs/settings/notification-templates/com.day.cq.replication

Alle Tags müssen nach /content/cq:tags migriert werden.

1. Kopieren Sie alle Tags vom vorherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie alle Tags aus dem vorherigen Speicherort.
3. Über die AEM-Web-Konsole erfolgt der Neustart des Day Communique 5 Tagging OSGi-Bundles unter https://serveradresse:serverport/system/console/bundles/com.day.cq.cq-tagging, damit AEM erkennt, dass der neue Speicherort Inhalt enthält und verwendet werden sollte.

Beim Neustart des Day Communique Tagging OSGi-Bundles wird der neue Speicherort nur als Tag-Stammverzeichnis registriert, wenn der vorherige Speicherort leer ist.

Verweise auf den vorherigen Speicherort bleiben nach der Migration an den neuen Speicherort weiterhin für alle Funktionen erhalten, die die TagManager-API von AEM für die Tag-Auflösung unterstützen.

Jeder benutzerspezifische Code, der explizit auf den Pfad /etc/tags verweist, muss aktualisiert werden auf /content/ cq :tags , oder vorzugsweise umgeschrieben, um die TagManager Java-API gemeinsam mit dieser Migration zu nutzen.

/libs/settings/cloudconfigs/translation/translationcfg

/apps/settings/cloudconfigs/translation/translationcfg

/conf/global/settings/cloudconfigs/translation/translationcfg

/conf/<tenant>/settings/cloudconfigs/translation/translationcfg

Alle neuen Cloud-basierten Übersetzungsdienste müssen an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>) migriert werden.

1. Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort an den neuen Speicherort.
   • Erstellen Sie manuell neue Konfigurationen der Cloud-basierten Übersetzungsdienste über die AEM-Benutzeroberfläche unter Tools > Cloud-Dienste > Übersetzungs-Cloud-Services.
     ODER
   • Kopieren Sie alle neuen Konfigurationen für Cloud-basierte Übersetzungsdienste vom vorherigen Speicherort an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>).
2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
   2. Hierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Experience Fragments > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
   3. Ordnerhierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Ordner > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
      
   4. Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
   5. AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.
3. Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.

Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:

1. /conf/<tenant>/settings/cloudconfigs/translations/translationcfg
2. /conf/global/settings/cloudconfigs/translations/translationcfg
3. /apps/settings/cloudconfigs/translations/translationcfg
4. /libs/settings/cloudconfigs/translations/translationcfg

Migrierte Cloud-basierte Übersetzungsdienste müssen mit AEM 6.4 kompatibel sein.

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

Alle neuen oder modifizierten Definitionen für Übersetzungssprachen erfordern eine Migration der Definitionen für Übersetzungssprachen an den neuen Speicherort (/apps).

1. Falls Ergänzungen oder Modifikationen an den Definitionen für Übersetzungssprachen vorgenommen wurden, sollten Sie alle Definitionen für Übersetzungssprachen vom vorherigen Speicherort an den neuen Speicherort (/apps) kopieren.

Die Auflösung des Pfads für Übersetzungssprachen geschieht in der folgenden Reihenfolge:

1. /etc/translation/supportedLanguages
2. /apps/settings/translation/supportedLanguage
3. /libs/settings/translation/supportedLanguages

Diese Lösung unterstützt kein Zusammenführen von Überlagerungen, der aufgelöste Pfad muss also alle unterstützten Sprachen enthalten und übernimmt nicht unterstützte Sprachen von übergeordneten Auflösungen.

/libs/settings/translation/rules/translation_rules.xml

/apps/settings/translation/rules/translation_rules.xml

/conf/global/settings/translation/rules/translation_rules.xml

Eine modifizierte XML-Datei für Übersetzungsregeln muss an den neuen Speicherort (/apps oder /conf/global) migriert werden.

1. Kopieren Sie die modifizierte XML-Datei für Übersetzungsregeln vom bisherigen Speicherort an den neuen Speicherort.

Die XML-Auflösung der Replikation der Übersetzungsregeln geschieht in der folgenden Reihenfolge:

1. /conf/global/settings/translation/rules/translation_rules.xml
2. /apps/settings/translation/rules/translation_rules.xml
3. /etc/workflow/models/translation/translation_rules.xml
4. /libs/settings/translation/rules/translation_rules.xml

/libs/settings/wcm/designs/translation/translationwidget

/apps/settings/wcm/designs/translation/translationwidget

Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.

1. Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
2. Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit allowProxy = true um.
3. Aktualisieren Sie Verweise auf den vorherigen Speicherort in der Eigenschaft cq : designPath .
4. Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungs-Codes).
5. Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. .

Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.

• Entfernen Sie keine bearbeitbaren Designs aus /etc.

/libs/settings/cloudconfigs/translation/<vendor>

/apps/settings/cloudconfigs/translation/<vendor>

/conf/global/settings/cloudconfigs/translation/<vendor>

/conf/<tenant>/settings/cloudconfigs/translation/<vendor>

Alle neuen Connector-Cloud-Services für Übersetzungsanbieter müssen an den neuen Speicherort (/conf/global,/apps oder /conf/<tenant>) migriert werden.

1. Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort an den neuen Speicherort.
   • Erstellen Sie manuell neue Konfigurationen der Connector-Cloud-Services für Übersetzungsanbieter über die AEM-Benutzeroberfläche unter Tools > Cloud-Dienste > Übersetzungs-Cloud-Services.
     ODER
   • Kopieren Sie alle neuen Konfigurationen für Connector-Cloud-Services für Übersetzungsanbieter vom vorherigen Speicherort an den neuen Speicherort (/conf/global , /apps oder /conf/<tenant>).
2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
   1. Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
   2. Hierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Experience Fragments > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
   3. Ordnerhierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Ordner > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
   4. Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
   5. AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.
3. Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.

Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:

1. /conf/<tenant>/settings/cloudconfigs/translations/<vendor>
2. /conf/global/settings/cloudconfigs/translations/<vendor>
3. /apps/settings/cloudconfigs/translations/<vendor>
4. /libs/settings/cloudconfigs/translations/<vendor>

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

Alle modifizierten E-Mail-Vorlagen für Workflow-Benachrichtigungen müssen an den neuen Speicherort (/conf/global) migriert werden.

1. Kopieren Sie alle modifizierten E-Mail-Vorlagen für die Workflow-Benachrichtigung vom bisherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie migrierte E-Mail-Vorlagen für die Workflow-Benachrichtigung vom vorherigen Speicherort.

Die Auflösung für die E-Mail-Vorlage für die Workflow-Benachrichtigung geschieht in der folgenden Reihenfolge:

1. /etc/workflow/notification
2. /conf/global/settings/workflow/notification
3. /libs/settings/workflow/notification

Bestehende Workflow-Pakete sollten vom vorherigen Speicherort an den neuen Speicherort migriert werden.

1. Entfernen Sie alle Workflow-Pakete vom vorherigen Speicherort, die durch andere Inhalte nicht referenziert werden und auch sonst nicht benötigt werden.
2. Verschieben Sie alle Workflow-Pakete an den vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden, aber am neuen Speicherort benötigt werden.
3. Belassen Sie alle Workflow-Pakete, auf die andere Inhalte verweisen, am vorherigen Speicherort.

Workflow-Pakete, die über die Miscadmin-Konsole in der klassischen Benutzeroberfläche erstellt wurden, verbleiben am vorherigen Speicherort, während alle anderen am neuen Speicherort gespeichert werden.

Die Workflow-Pakete, die entweder am vorherigen oder am neuen Speicherort gespeichert sind, können über die Miscadmin-Konsole in der klassischen Benutzeroberfläche verwaltet werden.