/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 mit AEM Workflow-Modell-Editor unter AEM > Tools > Workflow > Modelle.
3. Beim Migrieren von modifizierten, AEM bereitgestellten Workflow-Modellen
   1. Wenn der Workflow-Modell-Editor geöffnet ist, ändern Sie die Adresse des Browsers 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 Workflow-Modell-Editor, der die Definition des Workflow-Modells nach /conf/global/workflow/models kopiert.
5. Wählen Sie die Schaltfläche Synchronisieren , um die Änderungen mit dem Laufzeitarbeitsmodell unter /var/workflow/models zu synchronisieren.
6. Exportieren Sie beide Workflow-Modelle (/conf/global/workflow/models/<workflow-model>?lang=de) und das Laufzeitarbeitsablaufmodell (/var/workflow/models/<workflow-model>?lang=de) und in das AEM Projekt integrieren.
   1. Beispiel: export:
      • /conf/global/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 AEM bereitgestellten Workflow-Modelle, die am vorherigen Speicherort beibehalten werden, nach /conf/global/settings/workflow/models verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die AEM bereitgestellte Workflow-Modelldefinition in /libs/settings/workflow/models ersetzt.

Es ist keine Aktion erforderlich, um den neuen Speicherort anzupassen.

Historische Workflow-Instanzen können sicher im vorherigen Speicherort verbleiben 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 modifizierten Workflow-Skripte müssen an den neuen Speicherort migriert werden und die referenzierenden Workflow-Modelle müssen entsprechend dem neuen Speicherort aktualisiert werden.

1. Kopieren Sie alle neuen oder modifizierten Workflow-Skripte vom vorherigen Speicherort an den 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. Andernfalls wird beim Bearbeiten und Speichern von Workflow-Schritten, die auf Skripte am vorherigen Speicherort verweisen, der Workflow-Skript-Verweis vollständig aus dem Workflow-Schritt entfernt. In der Dropdown-Liste für die Skriptauswahl sind nur Workflow-Skripte an neuen Speicherorten 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 entsprechend dem neuen Speicherort aktualisiert werden.

1. Kopieren Sie alle neuen oder modifizierten ContextHub-Konfigurationen vom vorherigen Speicherort an den neuen Speicherort.
2. Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM Inhaltshierarchien.
   1. AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Erweiterte Registerkarte > Cloud-Konfiguration.
3. Trennen Sie alle migrierten älteren ContextHub-Konfigurationen von den oben 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. Proxy-Servlet.

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 vorherigen 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. Proxy-Servlet.

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 vorherigen 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. Proxy-Servlet.

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 vorherigen 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. Proxy-Servlet.

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.

Keine Aktion erforderlich.

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

Keine Aktion erforderlich.

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

Zum Migrieren von Aufgaben an den neuen Speicherort ist keine Aktion erforderlich.

• Aufgaben, die am vorherigen Speicherort vorhanden sind, sind weiterhin verfügbar und funktionieren.
• Neue Aufgaben werden am 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 unterstützten neuen E-Mail-Vorlagen für Replikationsbenachrichtigungen sind die Unterstützung neuer Gebietsschemata.

Die Auflösung der E-Mail-Vorlage für Replikationsbenachrichtigungen erfolgt 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 vom 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.

Wenn Sie das OSGi-Bundle Day Communique Tagging neu starten, wird der neue Speicherort nur als Tag-Stamm registriert, wenn der vorherige Speicherort leer ist.

Verweise auf den vorherigen Speicherort funktionieren auch nach der Migration zu "Neuer Speicherort"für alle Funktionen, die AEM TagManager-API für die Tag-Auflösung verwenden.

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 zusammen mit dieser Migration zu verwenden.

/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 am vorherigen Speicherort zum neuen Speicherort.
   • Erstellen Sie manuell neue Konfigurationen für Übersetzungs-Cloud Service über die AEM Authoring-Benutzeroberfläche unter Tools > Cloud Service > Übersetzungs-Cloud Service.
     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. AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Registerkarte "Erweitert"> Cloud-Konfiguration.
   2. AEM von Experience Fragment-Hierarchien über AEM Experience Fragments > Experience Fragment > Eigenschaften > Registerkarte Cloud Service > Cloud-Konfiguration.
   3. AEM Ordnerhierarchien von Experience Fragment über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte "Cloud Service"> 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 Übersetzungs-Cloud Service 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 Auflösung unterstützt keine Zusammenführungsüberlagerung. Das bedeutet, dass der aufgelöste Pfad alle unterstützten Sprachen enthalten muss und unterstützte Sprachen nicht von den Auflösungen mit höherer Reihenfolge übernimmt.

/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 vorherigen 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. Proxy-Servlet.

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 vorherigen Speicherort zum neuen Speicherort.
   • Erstellen Sie manuell die neuen Konfigurationen des Connector-Cloud Service für Übersetzungsanbieter über die AEM Authoring-Benutzeroberfläche unter Tools > Cloud Service > Übersetzungs-Cloud Service.
     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. AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Registerkarte "Erweitert"> Cloud-Konfiguration.
   2. AEM von Experience Fragment-Hierarchien über AEM Experience Fragments > Experience Fragment > Eigenschaften > Registerkarte Cloud Service > Cloud-Konfiguration.
   3. AEM Ordnerhierarchien von Experience Fragment über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte "Cloud Service"> 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 geänderten E-Mail-Vorlagen für Workflow-Benachrichtigungen vom vorherigen Speicherort an den neuen Speicherort.
2. Entfernen Sie migrierte E-Mail-Vorlagen für Workflow-Benachrichtigungen 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

Vorhandene Workflow-Pakete am vorherigen Speicherort sollten an den neuen Speicherort migriert werden.

1. Entfernen Sie alle Workflow-Pakete am vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden und ansonsten nicht erforderlich sind.
2. Verschieben Sie alle Workflow-Pakete an den vorherigen Speicherort, die nicht durch andere Inhalte referenziert, aber anderweitig am neuen Speicherort erforderlich sind.
3. Belassen Sie alle Workflow-Pakete, die durch andere Inhalte referenziert werden, am vorherigen Speicherort.

Workflow-Pakete, die über die Miscadmin Console der klassischen Benutzeroberfläche erstellt wurden, bleiben am vorherigen Speicherort erhalten, während alle anderen am neuen Speicherort beibehalten werden.

Workflow-Pakete, die entweder in den vorherigen oder niedrigeren Speicherorten gespeichert sind, können über die Miscadmin Console der klassischen Benutzeroberfläche verwaltet werden.