Configurazione di OSGi per Adobe Experience Manager as a Cloud Service

NOTA

AEM ha introdotto la possibilità di utilizzare l’interfaccia utente di Cloud Manager per configurare le variabili di ambiente standard con la versione 2021.12.0. Per ulteriori informazioni, consulta la documentazione qui.

OSGi è un elemento fondamentale nello stack tecnologico di Adobe Experience Manager (AEM). Viene utilizzato per controllare i bundle compositi di AEM e le sue configurazioni.

OSGi fornisce le primitive standardizzate che consentono di costruire applicazioni da componenti piccoli, riutilizzabili e collaborativi. Questi componenti possono essere composti in un’applicazione e distribuiti. Questo consente una facile gestione dei bundle OSGi in quanto possono essere arrestati, installati, avviati individualmente. Le interdipendenze vengono gestite automaticamente. Ogni componente OSGi è contenuto in uno dei vari bundle. Per ulteriori informazioni, consulta la sezione Specifiche OSGi.

Puoi gestire le impostazioni di configurazione per i componenti OSGi tramite file di configurazione che fanno parte di un progetto di codice AEM.

File di configurazione OSGi

Le modifiche di configurazione sono definite nei pacchetti di codice del progetto AEM (ui.apps) come file di configurazione (.cfg.json) in cartelle di configurazione specifiche della modalità di esecuzione:

/apps/example/config.<runmode>

Il formato dei file di configurazione OSGi è basato su JSON utilizzando .cfg.json definito dal progetto Apache Sling.

Le configurazioni OSGi sono destinate ai componenti OSGi tramite la loro identità persistente (PID), che per impostazione predefinita corrisponde al nome della classe Java™ del componente OSGi. Ad esempio, per fornire la configurazione OSGi per un servizio OSGi implementato da:

com.example.workflow.impl.ApprovalWorkflow.java

un file di configurazione OSGi è definito in:

/apps/example/config/com.example.workflow.impl.ApprovalWorkflow.cfg.json

che segue cfg.json Formato di configurazione OSGi.

NOTA

Versioni precedenti di file di configurazione OSGi supportati utilizzando formati di file diversi, come .cfg, .config e come XML sling:OsgiConfig definizioni delle risorse. Questi formati vengono sostituiti dal .cfg.json Formato di configurazione OSGi.

Risoluzione in modalità di esecuzione

SUGGERIMENTO

AEM 6.x supporta le modalità di esecuzione personalizzate, tuttavia AEM as a Cloud Service no. AEM supporto as a Cloud Service e set esatto di modalità di esecuzione. Qualsiasi variazione nelle configurazioni OSGi tra AEM ambienti as a Cloud Service deve essere gestita utilizzando Variabili dell'ambiente di configurazione OSGi.

Configurazioni OSGi specifiche possono essere indirizzate a istanze AEM specifiche utilizzando le modalità di esecuzione. Per utilizzare la modalità runmode, creare le cartelle di configurazione in /apps/example (dove esempio è il nome del progetto), nel formato:

/apps/example/config.<author|publish>.<dev|stage|prod>/

Tutte le configurazioni OSGi in tali cartelle vengono utilizzate se le modalità di esecuzione definite nel nome della cartella di configurazione corrispondono alle modalità di esecuzione utilizzate da AEM.

Ad esempio, se AEM utilizza le modalità di esecuzione author e dev, i nodi di configurazione in /apps/example/config.author/ e /apps/example/config.author.dev/ vengono applicati, mentre i nodi di configurazione in /apps/example/config.publish/ e /apps/example/config.author.stage/ non sono applicati.

Se sono applicabili più configurazioni per lo stesso PID, viene applicata la configurazione con il numero più alto di modalità di esecuzione corrispondenti.

La granularità di questa regola è a livello di PID. Ciò significa che non è possibile definire alcune proprietà per lo stesso PID in /apps/example/config.author/ e più specifiche in /apps/example/config.author.dev/ per lo stesso PID. La configurazione con il maggior numero di modalità di esecuzione corrispondenti sarà efficace per l'intero PID.

NOTA

A config.preview Cartella di configurazione OSGi impossibile devono essere dichiarati allo stesso modo config.publish può essere dichiarata cartella. Al contrario, il livello di anteprima eredita la propria configurazione OSGi dai valori del livello di pubblicazione.

Quando si sviluppa localmente, un parametro di avvio in modalità runmode, -r, viene utilizzato per specificare la configurazione OSGI in modalità runmode.

$ java -jar aem-sdk-quickstart-xxxx.x.xxx.xxxx-xxxx.jar -r publish,dev

Verifica delle modalità di esecuzione

AEM modalità di esecuzione as a Cloud Service sono ben definite in base al tipo di ambiente e al servizio. Consulta la sezione elenco completo delle modalità di esecuzione AEM as a Cloud Service disponibili.

I valori di configurazione OSGi specificati dalla modalità runmode possono essere verificati da:

  1. Apertura dell’ambiente AEM as a Cloud Services Console per sviluppatori
  2. Selezione dei livelli di servizio da ispezionare, utilizzando Pod menu a discesa
  3. Selezione della Stato scheda
  4. Selezione Configurazioni dal Immagine stato menu a discesa
  5. Selezione della Ottieni stato pulsante

La visualizzazione risultante visualizza tutte le configurazioni dei componenti OSGi per i livelli selezionati con i relativi valori di configurazione OSGi applicabili. Questi valori possono essere incrociati con i valori di configurazione OSGi nel codice sorgente del progetto AEM in /apps/example/osgiconfig/config.<runmode(s)>.

Per verificare che siano applicati i valori di configurazione OSGi appropriati:

  1. Nell’output Configurazione della Console per sviluppatori
  2. Individua il pid rappresentare la configurazione OSGi da verificare; questo è il nome del file di configurazione OSGi nel codice sorgente del progetto AEM.
  3. Inspect properties elenco per pid e verifica che la chiave e i valori corrispondano al file di configurazione OSGi nel codice sorgente del progetto AEM per la modalità runmode da verificare.=

Tipi di valori di configurazione OSGi

Ci sono tre varietà di valori di configurazione OSGi che possono essere utilizzati con Adobe Experience Manager as a Cloud Service.

  1. Valori in linea, che sono valori hardcoded nella configurazione OSGi e memorizzati in Git. Esempio:

    {
       "connection.timeout": 1000
    }
    
  2. Valori segreti, valori che non devono essere memorizzati in Git per motivi di sicurezza. Esempio:

    {
    "api-key": "$[secret:server-api-key]"
    }
    
  3. Valori specifici per l’ambiente, valori che variano da un ambiente di sviluppo all'altro e che pertanto non possono essere oggetto di targeting accurato in modalità di esecuzione (poiché è presente un solo dev in modalità runmode in Adobe Experience Manager as a Cloud Service). Esempio:

    {
     "url": "$[env:server-url]"
    }
    

    Tieni presente che un singolo file di configurazione OSGi può utilizzare qualsiasi combinazione di questi tipi di valori di configurazione in combinazione. Esempio:

    {
    "connection.timeout": 1000,
    "api-key": "$[secret:server-api-key]",
    "url": "$[env:server-url]"
    }
    

Come scegliere il tipo di valore di configurazione OSGi appropriato

Il caso comune per OSGi utilizza valori di configurazione OSGi in linea. Le configurazioni specifiche per l’ambiente vengono utilizzate solo per casi d’uso specifici in cui un valore differisce tra gli ambienti di sviluppo.

Le configurazioni specifiche per l’ambiente estendono le configurazioni OSGi tradizionali e definite statisticamente che contengono valori in linea, consentendo di gestire i valori di configurazione OSGi esternamente tramite l’API di Cloud Manager. È importante capire quando utilizzare l’approccio comune e tradizionale di definire i valori in linea e memorizzarli in Git, anziché astrarre i valori in configurazioni specifiche per l’ambiente.

Le seguenti linee guida riguardano quando utilizzare configurazioni non segrete e specifiche per l’ambiente:

Quando utilizzare i valori di configurazione in linea

I valori delle configurazioni in linea sono considerati l’approccio standard e devono essere utilizzati quando possibile. Le configurazioni in linea forniscono i vantaggi di:

  • Vengono mantenuti, con governance e cronologia delle versioni in Git
  • I valori sono implicitamente associati alle distribuzioni del codice
  • Non richiedono ulteriori considerazioni sulla distribuzione o sul coordinamento

Quando definisci un valore di configurazione OSGi, inizia con i valori in linea e seleziona solo le configurazioni segrete o specifiche per l’ambiente, se necessario per il caso d’uso.

Quando utilizzare valori di configurazione specifici dell’ambiente non segreti

Utilizza solo configurazioni specifiche per l’ambiente ($[env:ENV_VAR_NAME]) per i valori di configurazione non segreti quando i valori variano per il livello di anteprima o variano tra gli ambienti di sviluppo. Questo include le istanze di sviluppo locali e tutti gli ambienti di sviluppo Adobe Experience Manager as a Cloud Service. A parte l’impostazione di valori univoci per il livello di anteprima, evita di utilizzare configurazioni non segrete specifiche per l’ambiente per gli ambienti Adobe Experience Manager as a Cloud Service Stage o Production.

  • Utilizza solo configurazioni non segrete specifiche per l’ambiente per i valori di configurazione che differiscono tra il livello di pubblicazione e di anteprima o per i valori che differiscono tra gli ambienti di sviluppo, incluse le istanze di sviluppo locali.
  • Oltre allo scenario in cui il livello di anteprima deve variare dal livello di pubblicazione, utilizza i valori inline standard nelle configurazioni OSGi per i valori non segreti Stage e Produzione. In relazione, si sconsiglia di utilizzare configurazioni specifiche per l'ambiente per facilitare l'esecuzione di modifiche di configurazione in fase di runtime agli ambienti di stage e produzione; queste modifiche devono essere introdotte tramite la gestione del codice sorgente.

Quando utilizzare valori di configurazione specifici dell’ambiente segreto

Adobe Experience Manager as a Cloud Service richiede l’utilizzo di configurazioni specifiche per l’ambiente ($[secret:SECRET_VAR_NAME]) per qualsiasi valore di configurazione OSGi segreto, ad esempio password, chiavi API private o qualsiasi altro valore che non può essere memorizzato in Git per motivi di sicurezza.

Utilizza configurazioni specifiche per l’ambiente segreto per memorizzare il valore per i segreti su tutti gli ambienti Adobe Experience Manager as a Cloud Service, inclusi Stage e Produzione.

Creazione di configurazioni OSGi

Esistono due modi per creare configurazioni OSGi, come descritto di seguito. L’approccio precedente viene generalmente utilizzato per configurare componenti OSGi personalizzati che hanno proprietà e valori OSGi ben noti dallo sviluppatore e quest’ultimo per i componenti OSGi forniti da AEM.

Scrittura delle configurazioni OSGi

I file di configurazione OSGi formattati JSON possono essere scritti manualmente direttamente nel progetto AEM. Questo è spesso il modo più rapido per creare configurazioni OSGi per componenti OSGi ben noti, e in particolare per componenti OSGi personalizzati che sono stati progettati e sviluppati dallo stesso sviluppatore che definisce le configurazioni. Questo approccio può anche essere utilizzato per copiare/incollare e aggiornare le configurazioni per lo stesso componente OSGi in varie cartelle in modalità runmode.

  1. Nell’IDE, apri la ui.apps , individua o crea la cartella di configurazione (/apps/.../config.<runmode>) che esegue il targeting delle modalità di esecuzione della nuova configurazione OSGi
  2. In questa cartella di configurazione, crea un nuovo <PID>.cfg.json file. Il PID è l’identità persistente del componente OSGi. In genere è il nome della classe completa dell’implementazione del componente OSGi. Esempio:
    /apps/.../config/com.example.workflow.impl.ApprovalWorkflow.cfg.json
    I nomi dei file di fabbrica della configurazione OSGi utilizzano il <factoryPID>-<name>.cfg.json convenzione di denominazione
  3. Apri il nuovo .cfg.json e definire le combinazioni chiave/valore per le coppie di proprietà e valori OSGi, seguendo la Formato di configurazione JSON OSGi.
  4. Salva le modifiche apportate al nuovo .cfg.json file
  5. Aggiungi e esegui il commit del nuovo file di configurazione OSGi su Git

Generazione di configurazioni OSGi tramite l’SDK Quickstart AEM

La console Web AEM di Jar dell’SDK AEM Quickstart può essere utilizzata per configurare i componenti OSGi ed esportare le configurazioni OSGi come JSON. Questo è utile per configurare componenti OSGi forniti da AEM le cui proprietà OSGi e i relativi formati di valore potrebbero non essere ben compresi dallo sviluppatore che definisce le configurazioni OSGi nel progetto AEM.

NOTA

L’interfaccia utente di configurazione della console Web AEM scrive .cfg.json file nel repository. Tieni presente questo aspetto per evitare potenziali comportamenti inaspettati durante lo sviluppo locale, quando le configurazioni OSGi AEM definite dal progetto possono differire dalle configurazioni generate.

  1. Accedi alla console Web AEM di Jar dell'SDK AEM Quickstart come utente amministratore
  2. Passa a OSGi > Configurazione
  3. Per configurare, individua il componente OSGi e tocca il relativo titolo da modificare
    Configurazione OSGi
  4. Modifica i valori delle proprietà di configurazione OSGi tramite l’interfaccia utente Web in base alle esigenze
  5. Registra il PID (Persistent Identity) in un luogo sicuro. Viene utilizzato in seguito per generare la configurazione OSGi JSON
  6. Tocca Salva
  7. Passa a OSGi > Stampante di configurazione del programma di installazione OSGi
  8. Incolla nel PID copiato al passaggio 5, assicurati che il formato di serializzazione sia impostato su "OSGi Configurator JSON"
  9. Tocca Stampa
  10. La configurazione OSGi in formato JSON verrà visualizzata nella sezione Proprietà di configurazione serializzate .
    Stampante di configurazione del programma di installazione OSGi
  11. Nell’IDE, apri la ui.apps , individua o crea la cartella di configurazione (/apps/.../config.<runmode>), che esegue il targeting delle modalità di esecuzione necessarie per la nuova configurazione OSGi.
  12. In questa cartella di configurazione, crea un nuovo <PID>.cfg.json file. Il PID è lo stesso valore del passaggio 5.
  13. Incolla le proprietà di configurazione serializzata dal passaggio 10 nel .cfg.json file.
  14. Salva le modifiche apportate al nuovo .cfg.json file.
  15. Aggiungi e conferma il tuo nuovo file di configurazione OSGi a Git.

Formati delle proprietà di configurazione OSGi

Valori in linea

I valori in linea vengono formattati come coppie nome-valore standard, seguendo la sintassi JSON standard. Esempio:

{
   "my_var1": "val",
   "my_var2": [ "abc", "def" ],
   "my_var3": 500
}

Valori di configurazione specifici per l’ambiente

La configurazione OSGi deve assegnare un segnaposto per la variabile che deve essere definita per ambiente:

use $[env:ENV_VAR_NAME]

I clienti devono utilizzare questa tecnica solo per le proprietà di configurazione OSGi correlate al loro codice personalizzato; non deve essere utilizzato per sostituire la configurazione OSGi definita da Adobe.

NOTA

I segnaposto non possono essere utilizzati in dichiarazioni repoinit.

Valori di configurazione segreti

La configurazione OSGi deve assegnare un segnaposto per il segreto che deve essere definito per ambiente:

use $[secret:SECRET_VAR_NAME]

Denominazione delle variabili

Quanto segue si applica sia ai valori di configurazione specifici dell’ambiente che a quelli segreti.

I nomi delle variabili devono seguire le regole seguenti:

  • Lunghezza minima: 2
  • Lunghezza massima: 100
  • Deve corrispondere a regex: [a-zA-Z_][a-zA-Z_0-9]*

I valori per le variabili non devono superare i 2048 caratteri.

ATTENZIONE

Esistono regole relative all'utilizzo di alcuni prefissi per i nomi delle variabili:

  1. Nomi di variabile con prefisso INTERNAL_, ADOBE_oppure CONST_ sono riservati dall'Adobe. Tutte le variabili impostate dal cliente che iniziano con questi prefissi verranno ignorate.

  2. I clienti non devono fare riferimento a variabili con prefisso INTERNAL_ o ADOBE_ o.

  3. Variabili di ambiente con il prefisso AEM_ sono definiti dal prodotto come API pubblica da utilizzare e impostare dai clienti.
    Mentre i clienti possono utilizzare e impostare le variabili di ambiente che iniziano con il prefisso . AEM_ non devono definire le proprie variabili con questo prefisso.

Valori predefiniti

Quanto segue si applica sia ai valori di configurazione specifici dell’ambiente che a quelli segreti.

Se non viene impostato alcun valore per ambiente, in fase di runtime il segnaposto non viene sostituito e viene lasciato in posizione poiché non si è verificata alcuna interpolazione. Per evitare questo problema, è possibile fornire un valore predefinito come parte del segnaposto con la seguente sintassi:

$[env:ENV_VAR_NAME;default=<value>]

Se viene fornito un valore predefinito, il segnaposto viene sostituito con il valore per ambiente, se fornito, o con il valore predefinito fornito.

Sviluppo locale

Quanto segue si applica sia ai valori di configurazione specifici dell’ambiente che a quelli segreti.

Le variabili possono essere definite nell’ambiente locale in modo che vengano raccolte dall’AEM locale in fase di runtime. Ad esempio, su Linux®:

export ENV_VAR_NAME=my_value

Si consiglia di scrivere un semplice script bash che imposti le variabili di ambiente utilizzate nelle configurazioni ed eseguirle prima di avviare AEM. Strumenti simili https://direnv.net/ contribuire a semplificare questo approccio. A seconda del tipo di valori, possono essere sottoposti a Check-In nella gestione del codice sorgente, se possono essere condivisi tra tutti.

I valori per i segreti vengono letti dai file. Pertanto, per ogni segnaposto che utilizza un segreto, deve essere creato un file di testo contenente il valore segreto.

Ad esempio se $[secret:server_password] viene utilizzato un file di testo denominato server_password deve essere creato. Tutti questi file segreti devono essere archiviati nella stessa directory e nella proprietà framework org.apache.felix.configadmin.plugin.interpolation.secretsdir deve essere configurato con quella directory locale.

Configurazione autore e pubblicazione

Se una proprietà OSGi richiede valori diversi per autore e pubblicazione:

  • Separato config.author e config.publish Le cartelle OSGi devono essere utilizzate, come descritto in Sezione Risoluzione in modalità di esecuzione.
  • Esistono due opzioni per creare nomi di variabili indipendenti che devono essere utilizzati:
    • la prima opzione, consigliata: in tutte le cartelle OSGi (come config.author e config.publish) dichiarata per definire valori diversi, usa lo stesso nome di variabile. Esempio

      $[env:ENV_VAR_NAME;default=<value>], dove il valore predefinito corrisponde al valore predefinito per quel livello (authoring o pubblicazione). Quando si imposta la variabile di ambiente tramite API di Cloud Manager o tramite un client, distinguere tra i livelli utilizzando il parametro "service" come descritto in questo Documentazione di riferimento API. Il parametro "service" associa il valore della variabile al livello OSGi appropriato. Può essere "autore" o "pubblicazione" o "anteprima".

    • la seconda opzione, ovvero dichiarare variabili distinte utilizzando un prefisso come author_<samevariablename> e publish_<samevariablename>

Esempi di configurazione

Negli esempi seguenti, si supponga che siano presenti tre ambienti di sviluppo, oltre agli ambienti stage e prod.

Esempio 1

L'intento è il valore della proprietà OSGi my_var1 essere lo stesso per stage e prod, ma differire per ciascuno dei tre ambienti di sviluppo.

Cartella Contenuto di myfile.cfg.json
config
{ "my_var1": "val", "my_var2": "abc", "my_var3": 500 }
config.dev
{ "my_var1" : "$[env:my_var1]" "my_var2": "abc", "my_var3": 500 }

Esempio 2

L'intento è il valore della proprietà OSGi my_var1 per diversi ambienti di stage, prod e per ciascuno dei tre ambienti di sviluppo. È pertanto necessario chiamare l’API di Cloud Manager per impostare il valore per my_var1 per ogni dev env.

Cartella Contenuto di myfile.cfg.json
config.stage
{ "my_var1": "val1", "my_var2": "abc", "my_var3": 500 }
config.prod
{ "my_var1": "val2", "my_var2": "abc", "my_var3": 500 }
config.dev
{ "my_var1" : "$[env:my_var1]" "my_var2": "abc", "my_var3": 500 }

Esempio 3

L'intento è il valore della proprietà OSGi my_var1 essere lo stesso per gli ambienti stage, produzione e solo per uno degli ambienti di sviluppo, ma differire per gli altri due ambienti di sviluppo. In questo caso, l’API di Cloud Manager deve essere chiamata per impostare il valore di my_var1 per ciascuno degli ambienti di sviluppo, anche per l’ambiente di sviluppo che deve avere lo stesso valore di stage e produzione. Non erediterà il valore impostato nella cartella config.

Cartella Contenuto di myfile.cfg.json
config
{ "my_var1": "val1", "my_var2": "abc", "my_var3": 500 }
config.dev
{ "my_var1" : "$[env:my_var1]" "my_var2": "abc", "my_var3": 500 }

Un altro modo per farlo sarebbe quello di impostare un valore predefinito per il token di sostituzione nella cartella config.dev in modo che sia lo stesso valore di nel config cartella.

Cartella Contenuto di myfile.cfg.json
config
{ "my_var1": "val1", "my_var2": "abc", "my_var3": 500 }
config.dev
{ "my_var1": "$[env:my_var1;default=val1]" "my_var2": "abc", "my_var3": 500 }

Formato API di Cloud Manager per l’impostazione delle proprietà

Vedi questa pagina informazioni sulla configurazione dell’API.

NOTA

Assicurati che l’API di Cloud Manager utilizzata abbia assegnato il ruolo "Deployment Manager - Cloud Service". Altri ruoli non sono in grado di eseguire tutti i comandi sottostanti.

Impostazione dei valori tramite API

Una chiamata all'API distribuisce le nuove variabili e i nuovi valori in un ambiente Cloud, simile a una tipica pipeline di distribuzione del codice cliente. I servizi di authoring e pubblicazione verranno riavviati e faranno riferimento ai nuovi valori, in genere impiegando alcuni minuti.

PATCH /program/{programId}/environment/{environmentId}/variables
]
        {
                "name" : "MY_VAR1",
                "value" : "plaintext value",
                "type" : "string"  <---default
        },
        {
                "name" : "MY_VAR2",
                "value" : "<secret value>",
                "type" : "secretString"
        }
]
NOTA

Le variabili predefinite non sono impostate tramite API, ma nella proprietà OSGi stessa.

Vedi questa pagina per ulteriori informazioni.

Ottenimento dei valori tramite API

GET /program/{programId}/environment/{environmentId}/variables

Vedi questa pagina per ulteriori informazioni.

Eliminazione di valori tramite API

PATCH /program/{programId}/environment/{environmentId}/variables

Per eliminare una variabile, includerla con un valore vuoto.

Vedi questa pagina per ulteriori informazioni.

Ottenimento dei valori tramite la riga di comando

$ aio cloudmanager:list-environment-variables ENVIRONMENT_ID
Name     Type         Value
MY_VAR1  string       plaintext value
MY_VAR2  secretString ****

Impostazione dei valori tramite la riga di comando

$ aio cloudmanager:set-environment-variables ENVIRONMENT_ID --variable MY_VAR1 "plaintext value" --secret MY_VAR2 "some secret value"

Eliminazione dei valori tramite la riga di comando

$ aio cloudmanager:set-environment-variables ENVIRONMENT_ID --delete MY_VAR1 MY_VAR2
NOTA

Vedi questa pagina per ulteriori informazioni su come configurare i valori utilizzando il plug-in Cloud Manager, ad Adobe I/O CLI.

Numero di variabili

È possibile dichiarare fino a 200 variabili per ambiente.

Considerazioni sulla distribuzione per valori di configurazione segreti e specifici per l’ambiente

Poiché i valori di configurazione segreti e specifici per l’ambiente non rientrano in Git e non fanno quindi parte dei meccanismi formali di implementazione di Adobe Experience Manager as a Cloud Service, il cliente deve gestire, gestire e integrare nel processo di distribuzione di Adobe Experience Manager as a Cloud Service.

Come accennato in precedenza, la chiamata dell’API distribuisce le nuove variabili e i nuovi valori agli ambienti Cloud, in modo simile a una tipica pipeline di distribuzione del codice cliente. I servizi di authoring e pubblicazione verranno riavviati e faranno riferimento ai nuovi valori, in genere impiegando alcuni minuti. Tieni presente che i gate e i test di qualità eseguiti da Cloud Manager durante una distribuzione regolare del codice non vengono eseguiti durante questo processo.

In genere, i clienti chiamano l’API per impostare le variabili di ambiente prima di distribuire il codice che si basa su di esse in Cloud Manager. In alcune situazioni, potrebbe essere utile modificare una variabile esistente dopo che il codice è già stato distribuito.

NOTA

L’API potrebbe non riuscire quando è in uso una pipeline, un aggiornamento AEM o un’implementazione cliente, a seconda della parte della pipeline da fine a fine che viene eseguita in quel momento. La risposta di errore indicherà che la richiesta non è riuscita, anche se non indicherà il motivo specifico.

In alcuni casi, la distribuzione del codice cliente pianificato si basa su variabili esistenti per disporre di nuovi valori, il che non sarebbe appropriato per il codice corrente. Se si tratta di un problema, si raccomanda di apportare modifiche variabili in modo additivo. A questo scopo, crea nuovi nomi di variabili invece di semplicemente modificare il valore di vecchie variabili, il cui codice così vecchio non fa mai riferimento al nuovo valore. Quindi, quando il nuovo rilascio del cliente appare stabile, si può scegliere di rimuovere i valori precedenti.

Allo stesso modo, poiché ai valori di una variabile non viene applicata una versione, un rollback del codice potrebbe causare un riferimento a valori più recenti che causano problemi. Anche in questo caso sarebbe utile la strategia per la variabile additiva precedentemente menzionata.

Questa strategia di variabile additiva è utile anche per gli scenari di disaster recovery in cui, se si desidera ridistribuire il codice da diversi giorni, i nomi e i valori delle variabili a cui fa riferimento rimarranno intatti. Questo si basa su una strategia in cui un cliente attende alcuni giorni prima di rimuovere le variabili meno recenti, altrimenti il codice meno recente non disporrebbe di variabili appropriate a cui fare riferimento.

In questa pagina