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

/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.5-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 nach 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

Alle neuen oder modifizierten Workflow-Starter müssen in /conf/global/workflow/launcher/config.

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 von AEM bereitgestellten Workflow-Starter, die am vorherigen Speicherort beibehalten werden, an den neuen Speicherort (/conf/global/settings/workflow/launcher Wenn sie beibehalten werden sollen, werden sie andernfalls durch die AEM bereitgestellte Workflow-Starter-Definition in /libs/settings/workflow/launcher.

/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 beibehalten werden.
2. Aktualisieren Sie alle Verweise auf die Workflow-Skripte in den Workflow-Modellen am vorherigen Speicherort, sodass sie auf die neuen Speicherorte verweisen.

AEM 6.4 SP1 macht es nach der Veröffentlichung so, dass diese Umstrukturierung auf 6.5 verschoben werden kann 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 die Verweise auf den vorherigen Speicherort im cq : designPath -Eigenschaft.
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 Implementierungscodes).
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 die Verweise auf den vorherigen Speicherort im cq : designPath -Eigenschaft.
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 Implementierungscodes).
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 die Verweise auf den vorherigen Speicherort im cq : designPath -Eigenschaft.
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 Implementierungscodes).
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 die Verweise auf den vorherigen Speicherort im cq : designPath -Eigenschaft.
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 Implementierungscodes).
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 aus /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 AEM Dashboard-Gadget-Konfigurationen für Projekte müssen an den neuen Speicherort (/apps).

1. Kopieren Sie alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte vom vorherigen an den neuen Speicherort (/apps).
   1. Kopieren Sie nicht AEM Dashboard-Gadget-Konfigurationen für Projekte , da diese jetzt am neuen Speicherort (/libs).
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 Replikationsbenachrichtigungen müssen an den neuen Speicherort (/apps)

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 in /content/cq:tags.

1. Kopieren Sie alle Tags vom vorherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie alle Tags aus dem vorherigen Speicherort.
3. Starten Sie über die AEM Web-Konsole das Day Communique 5 Tagging-OSGi-Bundle neu unter https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging , damit AEM erkennen kann, dass der neue Speicherort Inhalte 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 verweist /etc/tags 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 Übersetzungs-Cloud Services müssen an den neuen Speicherort (/apps, /conf/global oder /conf/<tenant>).

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 Übersetzungs-Cloud Services vom vorherigen Speicherort an den neuen Speicherort (/apps, /conf/global 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. AEM Assets-Ordnerhierarchien über AEM Assets > Ordner > Ordnereigenschaften > Registerkarte "Cloud Services"> Konfiguration.
   5. AEM über AEM Projekte > Projekt > Projekteigenschaften > Registerkarte 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. Wenn Ergänzungen oder Änderungen an den Definitionen für Übersetzungssprachen vorgenommen wurden, kopieren Sie alle Definitionen für Übersetzungssprachen vom vorherigen Speicherort an den neuen Speicherort (/apps).

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 geänderte XML-Datei für Übersetzungsregeln muss an den neuen Speicherort (/appsoder /conf/global).

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 die Verweise auf den vorherigen Speicherort im cq : designPath -Eigenschaft.
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 Implementierungscodes).
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 migriert werden (/apps, /conf/global oder /conf/<tenant>).

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 der Connector-Cloud Services für Übersetzungsanbieter vom vorherigen Speicherort an den neuen Speicherort (/apps, /conf/global 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. AEM Assets-Ordnerhierarchien über AEM Assets > Ordner > Ordnereigenschaften > Registerkarte "Cloud Services"> Konfiguration.
   5. AEM über AEM Projekte > Projekt > Projekteigenschaften > Registerkarte 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 geänderten E-Mail-Vorlagen für Workflow-Benachrichtigungen müssen an den neuen Speicherort (/conf/global).

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.