Ristrutturazione dell’archivio comune in AEM 6.5 common-repository-restructuring-in-aem

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

Qualsiasi modello di flusso di lavoro nuovo o modificato deve essere migrato a /conf/global/workflow/models.

1. Distribuire i modelli di flusso di lavoro modificati in un'istanza di sviluppo AEM 6.5 locale, in modo che esistano nel percorso precedente.

2. Modifica il modello di flusso di lavoro utilizzando l’Editor modello di flusso di lavoro dell’AEM in AEM > Strumenti > Flusso di lavoro > Modelli.

3. Durante la migrazione dei modelli di flusso di lavoro AEM modificati

   1. Con l’Editor modello flusso di lavoro aperto, modifica l’URL dell’indirizzo del browser e sostituisci il segmento di percorso /libs/settings/workflow/models con /etc/workflow/models.
      • Ad esempio, modifica: 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. Abilita la modalità Modifica nell’Editor modello flusso di lavoro, che copierà la definizione del modello flusso di lavoro in /conf/global/workflow/models.

5. Seleziona il pulsante Sync per sincronizzare le modifiche apportate al modello di flusso di lavoro di runtime in /var/workflow/models.

6. Esporta sia il modello di flusso di lavoro (https://experienceleague.adobe.com/conf/global/workflow/models/<modello-flusso%20di%20lavoro>?lang=it) che il modello di flusso di lavoro di runtime (https://experienceleague.adobe.com/var/workflow/models/<modello-flusso%20di%20lavoro>?lang=it) e integrali nel progetto AEM.

   1. Ad esempio, esportare:

      • /conf/global/settings/workflow/models/dam/my_workflow_model
        e
      • /var/workflow/models/dam/my_workflow_model

La risoluzione del modello di flusso di lavoro viene eseguita nell'ordine seguente:

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

Pertanto, tutte le personalizzazioni dei modelli di flusso di lavoro forniti dall’AEM che persistono nella posizione Precedente devono essere spostate in /conf/global/settings/workflow/models se devono essere mantenute, altrimenti saranno sostituite dalla definizione del modello di flusso di lavoro fornita dall’AEM in /libs/settings/workflow/models.

Non è richiesta alcuna azione per l’allineamento con la nuova posizione.

Le istanze storiche dei flussi di lavoro possono continuare a risiedere nella posizione precedente senza problemi e verranno create nuove istanze dei flussi di lavoro nella nuova posizione.

Qualsiasi riferimento esplicito al percorso in Anche il codice custom nel percorso precedente deve tenere conto del nuovo percorso. Si consiglia di eseguire il refactoring di questo codice per utilizzare le API del flusso di lavoro AEM.

/libs/settings/workflow/launcher/config

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

Qualsiasi modulo di avvio flusso di lavoro nuovo o modificato deve essere migrato a /conf/global/workflow/launcher/config.

1. Copiare le configurazioni del modulo di avvio del flusso di lavoro nuove o modificate dal percorso precedente al nuovo percorso (/conf/global).

La risoluzione dell'utilità di avvio del flusso di lavoro viene eseguita nell'ordine seguente:

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

Di conseguenza, le personalizzazioni di Workflow Launcher fornite dall'AEM e persistenti nel percorso precedente devono essere spostate nel nuovo percorso (/conf/global/settings/workflow/launcher) se devono essere mantenute, altrimenti saranno sostituite dalla definizione di Workflow Launcher fornita dall'AEM in /libs/settings/workflow/launcher.

/libs/workflow/scripts

/apps/workflow/scripts

Qualsiasi script di flusso di lavoro nuovo o modificato deve essere migrato alla nuova posizione e i modelli di flusso di lavoro di riferimento devono essere aggiornati per riflettere la nuova posizione.

1. Copiare gli script di flusso di lavoro nuovi o modificati dal percorso precedente al nuovo percorso.
   • /apps/workflow/scripts devono essere mantenute nell’SCM.
2. Aggiornare eventuali riferimenti agli script del flusso di lavoro nella posizione precedente in Modelli flusso di lavoro per puntare alle nuove posizioni.

L'AEM 6.4 SP1, quando sarà pubblicato, consente di posticipare la ristrutturazione al 6.5 upgrade .

Se si effettua l’aggiornamento al AEM 6.4 prima del rilascio del AEM 6.4 SP1, tale ristrutturazione dovrebbe essere effettuata nell’ambito del progetto di aggiornamento. In caso contrario, la modifica e il salvataggio dei passaggi del flusso di lavoro che fanno riferimento a script nel percorso precedente rimuoveranno completamente il riferimento allo script del flusso di lavoro dal passaggio del flusso di lavoro e solo gli script del flusso di lavoro nei nuovi percorsi saranno disponibili nel menu a discesa per la selezione degli script.

/libs/settings/cloudsettings

/conf/global/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

Tutte le configurazioni ContextHub nuove o modificate devono essere migrate nella nuova posizione e le pagine AEM Sites di riferimento devono essere aggiornate per riflettere la nuova posizione.

1. Copia tutte le configurazioni ContextHub nuove o modificate dalla posizione precedente alla nuova posizione.
2. Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.
   1. Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
3. Dissocia tutte le configurazioni ContextHub legacy migrate dalle gerarchie di contenuti AEM sopra indicate.

N/D

/libs/settings/wcm/designs/cloudservices

/apps/settings/wcm/designs/cloudservices

Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.

1. Copiare le progettazioni dal percorso precedente al nuovo percorso (/apps).
2. Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con allowProxy = true.
3. Aggiorna i riferimenti alla posizione precedente in cq : Proprietà designPath .
4. Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
5. Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy

Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.

• Non spostare design modificabili da /etc.

N/D

/libs/settings/wcm/designs/dashboards

/apps/settings/wcm/designs/dashboards

Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.

1. Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
2. Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con allowProxy = true.
3. Aggiornare i riferimenti alla posizione precedente in cq : Proprietà designPath .
4. Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
5. Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy

Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.

• Non spostare design modificabili da /etc.

N/D

/libs/settings/wcm/designs/reports

/apps/settings/wcm/designs/reports

Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.

1. Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
2. Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con allowProxy = true.
3. Aggiornare i riferimenti alla posizione precedente in cq : Proprietà designPath .
4. Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
5. Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy

Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.

• Non spostare design modificabili da /etc.

N/D

/libs/settings/wcm/designs/default

/apps/settings/wcm/designs/default

Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.

1. Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
2. Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con allowProxy = true.
3. Aggiornare i riferimenti alla posizione precedente in cq : Proprietà designPath .
4. Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
5. Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy

Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.

• Non spostare design modificabili da /etc.

N/D

Non è richiesta alcuna azione.

La posizione precedente pubblica funge da endpoint proxy per la nuova posizione privata.

N/D

Non è richiesta alcuna azione.

La posizione precedente pubblica funge da endpoint proxy per la nuova posizione privata.

N/D

Utilizza l'attività di manutenzione della rimozione Posta in arrivo per rimuovere le vecchie attività dal percorso precedente in base alle esigenze.

Non è richiesta alcuna azione per eseguire la migrazione delle attività nella nuova posizione.

• Le attività presenti nel percorso precedente continuano a essere disponibili e a funzionare.
• Le nuove attività vengono create nella nuova posizione.

/libs/msm

/apps/msm

1. Copia configurazioni personalizzate da /etc/blueprints a /apps/msm.
2. Rimuovi /etc/blueprints.

N/D

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

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

Qualsiasi configurazione di gadget del dashboard per progetti AEM nuova o modificata deve essere migrata nella nuova posizione (/apps).

1. Copiare le configurazioni del gadget del dashboard progetti AEM nuove o modificate dalla posizione precedente alla nuova posizione (/apps).
   1. Non copiare le configurazioni del gadget del dashboard dei progetti AEM non modificate, in quanto queste sono ora presenti nella nuova posizione (/libs).
2. Aggiornare eventuali modelli di progetti AEM che fanno riferimento alla Posizione precedente in modo che puntino alla nuova posizione appropriata.

Se viene applicato il pacchetto di compatibilità AEM 6.4, sarà necessario eseguire le attività di allineamento dell’archivio al momento della rimozione del pacchetto di compatibilità.

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

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

Qualsiasi modello di posta elettronica di notifica replica nuovo o modificato deve essere migrato nel nuovo percorso (/apps)

1. Copiare i modelli di posta elettronica per le notifiche di replica nuovi o modificati dalla posizione precedente nella nuova posizione (/apps).
2. Rimuovere eventuali modelli di posta elettronica di notifica replica migrati dal percorso precedente.

Gli unici nuovi modelli di posta elettronica per le notifiche di replica supportati sono quelli che supportano le nuove impostazioni internazionali.

La risoluzione del modello di posta elettronica per le notifiche di replica viene eseguita nell'ordine seguente:

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

Tutti i tag devono essere migrati a /content/cq:tags.

1. Copia tutti i tag dalla posizione precedente alla nuova posizione.
2. Rimuovi tutti i tag dalla posizione precedente.
3. Tramite la console Web AEM, riavviare il bundle OSGi Day Communique 5 Tagging all'indirizzo https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging affinché l'AEM riconosca che la nuova posizione contiene dei contenuti e deve essere utilizzata.

Il riavvio del bundle OSGi di assegnazione tag Day Communique registrerà la nuova posizione come radice del tag solo se la posizione precedente è vuota.

I riferimenti alla posizione precedente continueranno a funzionare dopo la migrazione alla nuova posizione per tutte le funzionalità che utilizzano l’API TagManager dell’AEM per la risoluzione dei tag.

Qualsiasi codice personalizzato che fa riferimento in modo esplicito al percorso

/etc/tags

deve essere aggiornato a /content/

cq

:tags

, o preferibilmente riscritto per utilizzare l'API Java TagManager, insieme a questa migrazione.

/libs/settings/cloudconfigs/translation/translationcfg

/apps/settings/cloudconfigs/translation/translationcfg

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

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

Qualsiasi nuovo Cloud Service di traduzione deve essere migrato nel nuovo percorso (/apps, /conf/global o /conf/<tenant>).

1. Migra le configurazioni esistenti nella posizione precedente alla nuova posizione.

   • Ricrea manualmente nuove configurazioni dei Cloud Service di traduzione tramite l'interfaccia utente di creazione AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
     O
   • Copiare le nuove configurazioni dei Cloud Service di traduzione dal percorso precedente al nuovo percorso (/apps, /conf/global o /conf/<tenant>).

2. Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.

   1. Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
   2. Gerarchie di frammenti esperienza AEM tramite Frammenti esperienza AEM > Frammento esperienza > Proprietà > Scheda Cloud Service > Configurazione cloud.
   3. Gerarchie di cartelle di frammenti esperienza AEM tramite Frammenti esperienza AEM > Cartella > Proprietà > Scheda Cloud Service > Configurazione cloud.
   4. Gerarchie di cartelle AEM Assets tramite AEM Assets > Cartella > Proprietà cartella > Scheda Cloud Service > Configurazione.
   5. Progetti AEM tramite Progetti AEM > Progetto > Proprietà progetto > Scheda Avanzate > Configurazione cloud.

3. Dissocia eventuali Cloud Service di traduzione legacy migrati dalle gerarchie di contenuto AEM sopra indicate.

La risoluzione dei Cloud Service di traduzione viene eseguita nell'ordine seguente:

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

I Cloud Service di traduzione migrati devono essere compatibili con AEM 6.4.

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

Qualsiasi definizione di lingua di traduzione nuova o modificata richiede la migrazione di tutte le definizioni di lingua di traduzione nella nuova posizione (/apps).

1. Se sono state apportate aggiunte o modifiche alle definizioni della lingua di traduzione, copiare tutte le definizioni della lingua di traduzione dalla posizione precedente alla nuova posizione (/apps).

La risoluzione del percorso della lingua di traduzione viene eseguita nell'ordine seguente:

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

Questa risoluzione non supporta una sovrapposizione di unione, il che significa che il percorso risolto deve contenere tutte le lingue supportate e non erediterà le lingue supportate da risoluzioni di ordine superiore.

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

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

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

Un file XML delle regole di traduzione modificato deve essere migrato nel nuovo percorso (/apps o /conf/global).

1. Copiare il file XML delle regole di traduzione modificato dalla posizione precedente nella nuova posizione.

La risoluzione XML delle regole di traduzione della replica viene eseguita nell'ordine seguente:

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

Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.

1. Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
2. Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con allowProxy = true.
3. Aggiornare i riferimenti alla posizione precedente in cq : Proprietà designPath .
4. Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
5. Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy

Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.

• Non spostare design modificabili da /etc.

N/D

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

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

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

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

Qualsiasi nuovo Cloud Service di connettori di traduzione fornitore deve essere migrato nella nuova posizione (/apps, /conf/global o /conf/<tenant>).

1. Migra le configurazioni esistenti nella posizione precedente alla nuova posizione.

   • Crea manualmente configurazioni di Cloud Service di connettori di traduzione fornitori netti tramite l'interfaccia utente di creazione dell'AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
     O
   • Copiare le configurazioni dei nuovi Cloud Service di connettori di traduzione fornitori dalla posizione precedente alla nuova posizione (/apps, /conf/global o /conf/<tenant>).

2. Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.

   1. Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
   2. Gerarchie di frammenti esperienza AEM tramite Frammenti esperienza AEM > Frammento esperienza > Proprietà > Scheda Cloud Service > Configurazione cloud.
   3. Gerarchie di cartelle di frammenti esperienza AEM tramite Frammenti esperienza AEM > Cartella > Proprietà > Scheda Cloud Service > Configurazione cloud.
   4. Gerarchie di cartelle AEM Assets tramite AEM Assets > Cartella > Proprietà cartella > Scheda Cloud Service > Configurazione.
   5. Progetti AEM tramite Progetti AEM > Progetto > Proprietà progetto > Scheda Avanzate > Configurazione cloud.

3. Dissocia eventuali Cloud Service di traduzione legacy migrati dalle gerarchie di contenuto AEM sopra indicate.

La risoluzione dei Cloud Service di traduzione viene eseguita nell'ordine seguente:

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

È necessario eseguire la migrazione di tutti i modelli e-mail di notifica flusso di lavoro modificati nel nuovo percorso (/conf/global).

1. Copiare nella nuova posizione tutti i modelli di e-mail di notifica del flusso di lavoro modificati dalla posizione precedente.
2. Rimuovi i modelli e-mail di notifica flusso di lavoro migrati dalla posizione precedente.

La risoluzione del modello e-mail di notifica flusso di lavoro viene eseguita nell'ordine seguente:

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

I pacchetti di flusso di lavoro esistenti nella posizione precedente devono essere migrati nella nuova posizione.

1. Rimuovi eventuali pacchetti flusso di lavoro nella posizione precedente che non sono referenziati da altri contenuti e che non sono altrimenti necessari.
2. Sposta tutti i pacchetti flusso di lavoro nella posizione precedente che non sono referenziati da altri contenuti ma che sono comunque necessari nella nuova posizione.
3. Lascia nella posizione precedente tutti i pacchetti del flusso di lavoro a cui fanno riferimento altri contenuti.

I pacchetti del flusso di lavoro creati tramite la console Miscadmin dell’interfaccia classica vengono mantenuti nella posizione precedente, mentre tutti gli altri vengono mantenuti nella nuova posizione.

I pacchetti del flusso di lavoro memorizzati nelle posizioni precedenti o precedenti possono essere gestiti tramite la console Gestione errori dell’interfaccia classica.