Dopo il Aggiornamento sul posto per finalizzare l’aggiornamento, devono essere eseguite le seguenti attività. Si presume che l’AEM sia stato avviato con il file jar 6.5 e che la base di codice aggiornata sia stata distribuita.
upgrade.log
In passato, il controllo dello stato di post-aggiornamento dell’istanza richiedeva un’attenta ispezione di vari file di registro, parti dell’archivio e il modulo di avvio. La generazione di un rapporto post-aggiornamento può aiutare a rilevare gli aggiornamenti difettosi prima della pubblicazione.
Lo scopo principale di questa funzione è ridurre la necessità di interpretazione manuale o logica di analisi complessa su più endpoint necessari per qualificare il successo di un aggiornamento. La soluzione fornisce informazioni inequivocabili che consentono ai sistemi di automazione esterni di reagire in caso di esito positivo o negativo di un aggiornamento.
In particolare, garantisce che:
Per risolvere questo problema, sono state apportate modifiche alla modalità di generazione dei registri in upgrade.log
file.
Di seguito è riportato un report di esempio che non mostra errori durante l’aggiornamento:
Di seguito è riportato un report di esempio che mostra un bundle non installato durante il processo di aggiornamento:
error.log
Il file error.log deve essere esaminato attentamente durante e dopo l’avvio dell’AEM utilizzando la versione target jar. Eventuali avvertenze o errori devono essere esaminati. In generale, è consigliabile cercare i problemi all’inizio del registro. Gli errori che si verificano più avanti nel registro possono in realtà essere effetti collaterali di una causa principale che viene richiamata all’inizio del file. Se si verificano errori e avvisi ripetuti, vedi di seguito per Analisi dei problemi relativi all’aggiornamento.
Passa alla console OSGi /system/console/bundles
e per vedere se eventuali bundle non vengono avviati. Se uno o più bundle sono in stato di installazione, consulta error.log
per determinare il problema principale.
In seguito all’aggiornamento, dovresti notare che la versione Oak è stata aggiornata a 1.10.2.. Per verificare la versione Oak, passa alla console OSGi e osserva la versione associata ai bundle Oak: Oak Core, Oak Commons, Oak Segment Tar.
Durante l’aggiornamento, AEM tenta di eseguire il backup delle personalizzazioni e di memorizzarle sotto /var/upgrade/PreUpgradeBackup/<time-stamp-of-upgrade>
. Per visualizzare questa cartella in CRXDE Lite, potrebbe essere necessario abilita temporaneamente CRXDE Lite.
La cartella con il timestamp deve avere una proprietà denominata mergeStatus
con un valore di COMPLETED
. Il to-process la cartella deve essere vuota e la sovrascritto node indica quali nodi sono stati sovrascritti durante l’aggiornamento. Il contenuto sotto il nodo degli avanzi indica il contenuto che non è stato possibile unire in modo sicuro durante l’aggiornamento. Se l’implementazione dipende da uno qualsiasi dei nodi secondari (e non già installati dal pacchetto di codice aggiornato), deve essere unita manualmente.
Disattiva CRXDE Lite seguendo questo esercizio se si trova in un ambiente di stage o produzione.
Eseguire una convalida iniziale su diverse pagine dell’AEM. Se si aggiorna un ambiente di authoring, aprire la pagina Start e la pagina di benvenuto ( /aem/start.html
, /libs/cq/core/content/welcome.html
). In entrambi gli ambienti Author e Publish, apri alcune pagine di applicazioni e verifica che vengano riprodotte correttamente. In caso di problemi, consultare il error.log
per la risoluzione dei problemi.
Se sono stati rilasciati, applicare i Service Pack AEM 6.5 pertinenti.
Diverse funzioni dell’AEM richiedono passaggi aggiuntivi dopo l’aggiornamento. Un elenco completo di queste funzioni e dei passaggi necessari per migrarle all'AEM 6.5 è disponibile sul sito Aggiornamento del codice e delle personalizzazioni pagina.
Se utilizzi un archivio dati file, accertati che l’attività Raccolta oggetti inattivi dell’archivio dati sia abilitata e aggiunta all’elenco Manutenzione settimanale. Le istruzioni sono descritte qui.
Questa operazione non è consigliata per le installazioni dell’archivio dati personalizzato S3 o quando si utilizza un archivio dati condiviso.
Se utilizzi MongoMK o il nuovo formato di segmento TarMK, accertati che l’attività Pulizia revisioni sia abilitata e aggiunta all’elenco Manutenzione giornaliera. Istruzioni descritte qui.
Esegui piano di test dettagliato in base a come definito Aggiornamento del codice e delle personalizzazioni sotto Procedura di prova sezione.
Dopo aver aggiornato e convalidato completamente l’ambiente di pubblicazione, abilita gli agenti di replica nell’ambiente di authoring. Verifica che gli agenti siano in grado di connettersi alle rispettive istanze Publish. Vedere U Procedura di aggiornamento per ulteriori dettagli sull’ordine degli eventi.
A questo punto è possibile abilitare tutti i processi pianificati come parte della base di codice.
Questa sezione descrive alcuni scenari di problemi che si potrebbero verificare durante la procedura di aggiornamento a AEM 6.3.
Questi scenari dovrebbero aiutare a individuare la causa principale dei problemi relativi all’aggiornamento e dovrebbero aiutare a identificare i problemi specifici del progetto o del prodotto.
La migrazione dei dati da CRX2 a Oak dovrebbe essere fattibile per qualsiasi scenario a partire da Istanze di origine basate su CQ 5.4. Accertati di seguire esattamente le istruzioni di aggiornamento riportate in questo documento, che includono la preparazione del repository.xml
, accertandosi che non venga avviato alcun autenticatore personalizzato tramite JAAS e che l’istanza sia stata controllata per individuare incoerenze prima di avviare la migrazione.
Se la migrazione non riesce ancora, puoi capire qual è la causa principale esaminando il upgrade.log
. Se il problema non è ancora noto, segnalalo all’Assistenza clienti.
Prima di iniziare i passaggi di preparazione, assicurati di eseguire il sorgente eseguendolo prima con il comando Java™ -jar aem-quickstart.jar. Questo è necessario per assicurarsi che il file quickstart.properties sia generato correttamente. Se manca, l’aggiornamento non funzionerà. In alternativa, è possibile verificare se il file è presente cercando in crx-quickstart/conf
nella cartella di installazione dell’istanza di origine. Inoltre, quando si avvia AEM per avviare l’aggiornamento, questo deve essere eseguito con il comando Java™ -jar aem-quickstart.jar. L’avvio da uno script di avvio non avvia AEM in modalità di aggiornamento.
Nel caso in cui i pacchetti non vengano installati durante l’aggiornamento, i bundle in essi contenuti non verranno aggiornati. Questa categoria di problemi è causata da una configurazione errata dell’archivio dati. Vengono inoltre visualizzati come ERRORE e AVVERTI messaggi in error.log. Poiché nella maggior parte di questi casi l’accesso predefinito potrebbe non funzionare, puoi utilizzare CRXDE direttamente per verificare e individuare i problemi di configurazione.
Se sono presenti bundle che non si avviano, verifica la presenza di eventuali dipendenze non soddisfatte.
Nel caso in cui il problema sia presente ma si basi su un’installazione non riuscita del pacchetto che ha portato a un mancato aggiornamento dei bundle, questi verranno considerati incompatibili per la nuova versione. Per ulteriori informazioni su come risolvere il problema, consulta Impossibile aggiornare pacchetti e bundle sopra.
Si consiglia inoltre di confrontare l’elenco dei bundle di una nuova istanza AEM 6.5 con quello aggiornato per rilevare i bundle che non sono stati aggiornati. Questo fornirà un ambito più vicino di cosa cercare nel error.log
.
Se i bundle personalizzati non passano allo stato attivo, è probabile che ci sia codice che non importa l’API di modifica. Questo nella maggior parte dei casi porterà a dipendenze non soddisfatte.
L’API rimossa deve essere contrassegnata come obsoleta in una delle versioni precedenti. Le istruzioni su una migrazione diretta del codice sono disponibili in questo avviso di elementi obsoleti. Adobe mira al controllo delle versioni semantiche, ove possibile, in modo che le versioni possano indicare modifiche che causano interruzioni.
È inoltre consigliabile verificare se la modifica che ha causato il problema è necessaria e, in caso contrario, ripristinarla. Controlla anche se l’aumento di versione dell’esportazione del pacchetto è stato aumentato più del necessario, seguendo un rigoroso controllo delle versioni semantiche.
Se alcune funzionalità dell’interfaccia utente non funzionano correttamente dopo l’aggiornamento, è necessario innanzitutto verificare la presenza di sovrapposizioni personalizzate dell’interfaccia. Alcune strutture potrebbero essere state modificate e la sovrapposizione potrebbe richiedere un aggiornamento o risultare obsoleta.
Quindi, controlla eventuali errori JavaScript che possono essere tracciati fino alle estensioni aggiunte personalizzate collegate alle librerie client. Lo stesso vale per i CSS personalizzati che potrebbero causare problemi al layout dell’AEM.
Infine, verifica la presenza di errori di configurazione che JavaScript potrebbe non essere in grado di risolvere. Questo accade in genere con le estensioni disattivate in modo improprio.
In genere, le cause principali di questi problemi sono le stesse dei bundle non avviati o dei pacchetti non installati, con l’unica differenza che i problemi iniziano a verificarsi quando si utilizzano i componenti per la prima volta.
Il modo per trattare il codice personalizzato errato è quello di eseguire prima i test di fumo per identificare la causa. Una volta trovato, guarda i consigli in questo [link] sezione dell'articolo per i modi di fissarli.
/apps
e /libs
sono gestiti correttamente dall’aggiornamento, ma le modifiche in /etc
potrebbe essere necessario ripristinare manualmente da /var/upgrade/PreUpgradeBackup
dopo l'upgrade. Verificare la presenza di eventuali contenuti da unire manualmente in questa posizione.
Nella maggior parte delle situazioni, i registri devono essere consultati per gli errori per individuare la causa di un problema. Tuttavia, con gli aggiornamenti, è anche necessario monitorare i problemi di dipendenza in quanto i vecchi bundle potrebbero non essere aggiornati correttamente.
Il modo migliore per farlo è quello di eliminare error.log rimuovendo tutti i messaggi che si prevede non siano correlati al problema che stai affrontando. Puoi eseguire questa operazione tramite uno strumento come grep, utilizzando:
grep -v UnrelatedErrorString
Alcuni messaggi di errore potrebbero non essere immediatamente esplicativi. In questo caso, anche esaminare il contesto in cui si verificano può essere utile per capire dove è stato creato l’errore. È possibile separare l’errore utilizzando:
grep -B
per aggiungere righe prima dell’errore;oppure
grep -A
per aggiungere righe dopo.In alcuni casi è possibile trovare anche messaggi WARN in quanto possono esserci casi validi che portano a questo stato e l’applicazione non è sempre in grado di decidere se si tratta di un errore effettivo. Assicurati di consultare anche questi messaggi.
Se hai già esaminato i consigli in questa pagina e riscontri ancora problemi, contatta l’Assistenza Adobe. Per fornire quante più informazioni possibili al tecnico del supporto che lavora al tuo caso, assicurati di includere il file upgrade.log dal tuo aggiornamento.