Show Menu
ARGOMENTI×

Linee guida per lo sviluppo per AEM as a Cloud Service

Il codice in esecuzione in AEM come servizio cloud deve essere consapevole del fatto che è sempre in esecuzione in un cluster. Ciò significa che è sempre in esecuzione più di un'istanza. Il codice deve essere resiliente, in particolare perché un'istanza potrebbe essere arrestata in qualsiasi momento.
Durante l'aggiornamento di AEM come servizio cloud, saranno presenti istanze con codice vecchio e nuovo in esecuzione in parallelo. Pertanto, il vecchio codice non deve essere in conflitto con il contenuto creato dal nuovo codice e il nuovo codice deve essere in grado di gestire il contenuto precedente.
Se è necessario identificare il master nel cluster, Apache Sling Discovery API può essere utilizzata per rilevarlo.

Stato in memoria

Lo stato non deve essere mantenuto in memoria ma mantenuto nella directory archivio. In caso contrario, questo stato potrebbe andare perso se un'istanza viene arrestata.

Stato del file system

Il file system dell'istanza non deve essere utilizzato in AEM come servizio cloud. Il disco è effimero e verrà smaltito quando le istanze vengono riciclate. L'uso limitato del filesystem per l'archiviazione temporanea in relazione all'elaborazione di singole richieste è possibile, ma non dovrebbe essere abusato per i file enormi. Questo perché potrebbe avere un impatto negativo sulla quota di utilizzo delle risorse ed essere eseguito nei limiti del disco.
Ad esempio, se l’utilizzo del file system non è supportato, il livello Pubblica deve garantire che tutti i dati da mantenere vengano inviati a un servizio esterno per l’archiviazione a lungo termine.

Osservazione

Analogamente, con tutto ciò che sta accadendo in modo asincrono come agire su eventi di osservazione, non può essere garantito che sia eseguito localmente e quindi deve essere utilizzato con cura. Ciò è vero sia per gli eventi JCR che per gli eventi delle risorse Sling. Nel momento in cui si verifica una modifica, l’istanza può essere chiusa e sostituita da un’altra istanza. Altre istanze della topologia attive in quel momento saranno in grado di reagire a tale evento. In questo caso, tuttavia, non si tratterà di un evento locale e potrebbe addirittura non esserci un leader attivo in caso di elezioni di leader in corso al momento dell'emissione dell'evento.

Attività in background e processi con esecuzione prolungata

Il codice eseguito come attività in background deve presupporre che l'istanza in cui è in esecuzione possa essere ridotta in qualsiasi momento. Pertanto, il codice deve essere resiliente e la maggior parte delle importazioni deve essere ripristinabile. Ciò significa che se il codice viene rieseguito, non dovrebbe ricominciare dall'inizio ma piuttosto avvicinarsi a quello che ha lasciato. Anche se questo non è un nuovo requisito per questo tipo di codice, in AEM come servizio cloud è più probabile che si verifichi una rimozione dell'istanza.
Per ridurre al minimo i problemi, è necessario evitare i lavori a lungo termine, se possibile, che dovrebbero essere ripresi al minimo. Per eseguire tali processi, utilizzate Processi Sling, che dispongono di una garanzia almeno una volta e quindi se vengono interrotti, verranno rieseguiti il prima possibile. Ma probabilmente non dovrebbero ricominciare dall'inizio. Per la pianificazione di tali processi, è consigliabile utilizzare il pianificatore Sling Jobs , in quanto questa è di nuovo l’esecuzione almeno una volta.
L'Utilità di pianificazione Sling Commons non deve essere utilizzata per la pianificazione, perché non è possibile garantire l'esecuzione. È molto più probabile che venga pianificato.
Allo stesso modo, con tutto ciò che sta accadendo in modo asincrono, come agire su eventi di osservazione, (che si tratti di eventi JCR o di eventi di risorse Sling), non può essere garantito di essere eseguito e quindi deve essere utilizzato con attenzione. Questo è già vero per le distribuzioni AEM al momento.

Connessioni HTTP in uscita

È vivamente consigliato che qualsiasi connessione HTTP in uscita imposti timeout ragionevoli di connessione e lettura. Per il codice che non applica questi timeout, le istanze AEM in esecuzione su AEM come servizio cloud applicheranno un timeout globale. Questi valori di timeout sono 10 secondi per le chiamate di connessione e 60 secondi per le chiamate di lettura per le connessioni utilizzate dalle seguenti librerie Java popolari:
Adobe consiglia di utilizzare la libreria Apache HttpComponents Client 4.x fornita per effettuare connessioni HTTP.
Le alternative che funzionano, ma che possono richiedere di fornire la dipendenza sono:

Nessuna personalizzazione interfaccia classica

AEM come servizio Cloud supporta solo l'interfaccia touch per il codice cliente di terze parti. L’interfaccia classica non è disponibile per la personalizzazione.

Evitare i binari nativi

Il codice non sarà in grado di scaricare i file binari in fase di esecuzione né di modificarli. Ad esempio, non sarà in grado di decomprimere jar o tar i file.

Nessun binario in streaming tramite AEM come servizio cloud

I file binari devono essere accessibili tramite la rete CDN, che servirà i file binari al di fuori dei servizi AEM di base.
Ad esempio, non utilizzate asset.getOriginal().getStream() , il che attiva il download di un binario sul disco temporaneo del servizio AEM.

Nessun agente di replica inversa

La replica inversa da Pubblica a Autore non è supportata in AEM come servizio cloud. Se tale strategia è necessaria, potete utilizzare uno store di persistenza esterno condiviso tra le farm di istanze Pubblica e potenzialmente il cluster Autore.

È possibile che sia necessario portare gli agenti di replica successivi

Il contenuto viene replicato da Autore a Pubblica tramite un meccanismo secondario di pubblicazione. Gli agenti di replica personalizzati non sono supportati.

Monitoraggio e debug

Registri

Per lo sviluppo locale, le voci di registro sono scritte in file locali nella /crx-quickstart/logs cartella.
Negli ambienti Cloud, gli sviluppatori possono scaricare i registri tramite Cloud Manager o utilizzare uno strumento della riga di comando per localizzare i registri.
Impostazione del livello di registro
Per modificare i livelli di registro per gli ambienti Cloud, la configurazione Sling Logging OSGI deve essere modificata, seguita da una ridistribuzione completa. Poiché non è istantaneo, essere cauti nell'attivare log verbosi in ambienti di produzione che ricevono molto traffico. In futuro, è possibile che ci saranno meccanismi per cambiare più rapidamente il livello di registro.
Per eseguire le modifiche di configurazione elencate di seguito, è necessario crearle in un ambiente di sviluppo locale e quindi inviarle a un’istanza AEM come servizio cloud. Per ulteriori informazioni su come eseguire questa operazione, consulta Implementazione in AEM come servizio cloud.
Attivazione del livello di registro DEBUG
Il livello di registro predefinito è INFO, ovvero i messaggi DEBUG non vengono registrati. Per attivare il livello di registro DEBUG, impostare la variabile
/libs/sling/config/org.apache.sling.commons.log.LogManager/org.apache.sling.commons.log.level
da eseguire il debug. Non lasciare il registro a livello di registro DEBUG più a lungo del necessario, in quanto genera molti registri. Una riga nel file di debug in genere inizia con DEBUG, quindi fornisce il livello di registro, l'azione del programma di installazione e il messaggio di registro. Ad esempio:
DEBUG 3 WebApp Panel: WebApp successfully deployed
I livelli di registro sono i seguenti:
0
Errore irreversibile
L'azione non è riuscita e il programma di installazione non può proseguire.
1
Errore
L'azione non è riuscita. L'installazione continua, ma una parte di CRX non è stata installata correttamente e non funzionerà.
2
Avvertenza
L'azione è riuscita ma ha incontrato dei problemi. CRX può funzionare o meno correttamente.
3
Informazioni
L'azione è riuscita.

Cassetti di thread

Le discariche di thread negli ambienti Cloud vengono raccolte in modo continuativo, ma al momento non possono essere scaricate in modo autonomo. Nel frattempo, contattate il supporto di AEM se sono necessari dei thread dumps per il debug di un problema, specificando la finestra temporale esatta.

Console di sistema CRX/DE Lite

Sviluppo locale

Per lo sviluppo locale, gli sviluppatori possono accedere completamente a CRXDE Lite ( /crx/de ) e alla console Web di AEM ( /system/console ).
Sullo sviluppo locale (tramite l'avvio rapido per il cloud) /apps e /libs può essere scritto direttamente, il che è diverso dagli ambienti Cloud in cui tali cartelle di livello superiore sono immutabili.

AEM as a Cloud Service Development tools

I clienti possono accedere a CRXDE lite nell'ambiente di sviluppo, ma non sullo stage o sulla produzione. L'archivio immutabile ( /libs , /apps ) non può essere scritto in fase di esecuzione, pertanto il tentativo di eseguire tale operazione potrebbe causare errori.
Una serie di strumenti per il debug di AEM come ambienti per sviluppatori di servizi cloud sono disponibili in Developer Console per gli ambienti di sviluppo, fase e produzione. Per determinare l’URL, regolate gli URL del servizio Autore o Pubblica nel modo seguente:
https://dev-console/-<namespace>.<cluster>.dev.adobeaemcloud.com
Come scelta rapida, il seguente comando CLI di Cloud Manager può essere utilizzato per avviare la console dello sviluppatore in base a un parametro di ambiente descritto di seguito:
aio cloudmanager:open-developer-console <ENVIRONMENTID> --programId <PROGRAMID>
Per ulteriori informazioni, consulta questa pagina .
Gli sviluppatori possono generare informazioni sullo stato e risolvere diverse risorse.
Come illustrato di seguito, le informazioni sullo stato disponibili includono lo stato di bundle, componenti, configurazioni OSGI, indici di quercia, servizi OSGI e processi Sling.
Come illustrato di seguito, gli sviluppatori possono risolvere dipendenze e servlet del pacchetto:
Utile anche per il debug, la console Sviluppatore dispone di un collegamento allo strumento Spiega query:
Per i programmi regolari, l'accesso alla Developer Console è definito da "Cloud Manager - ruolo sviluppatore" nell'Admin Console, mentre per i programmi sandbox, Developer Console è disponibile per qualsiasi utente con un profilo di prodotto che dia loro accesso ad AEM come servizio cloud. Per ulteriori informazioni sulla configurazione delle autorizzazioni per l'utente, consulta la Documentazione di Cloud Manager.

Servizio di gestione e produzione AEM

I clienti non avranno accesso agli strumenti di sviluppo per gli ambienti di produzione e di staging.

Monitoraggio delle prestazioni

Adobe controlla le prestazioni delle applicazioni e adotta misure per risolvere eventuali situazioni di deterioramento. Al momento, le metriche dell'applicazione non possono essere osservate.