Eseguire la migrazione di un'istanza di Oracle Content Management da un'infrastruttura cloud precedente

Il comando "cec migrate-site" è nuovo, pertanto sarà necessario installare OCE Toolkit dal repository GIT del client Web anche se è stato scaricato e installato in precedenza.

Per scaricare e installare OCE Toolkit, attenersi alle istruzioni fornite nella pagina Sites Toolkit.

Registrare i dettagli di connessione per il server di destinazione, ovvero il server verso il quale si esegue la migrazione dei siti:

> cec register-server <target_server_name>
          -e http://<target_server>:<target_port>
          -u <target_username> -p <target_password>
          -t pod_ec

• <target_server_name> viene utilizzato per identificare l'endpoint di destinazione e può essere qualsiasi nome di propria scelta.
• <target_server> e <target_port> formano l'URL usato per accedere al server di destinazione.
• <target_username> e <target_password> devono essere il nome utente e la password della persona che esporterà i modelli di sito dal server di origine in modo che non si verifichino problemi di autorizzazione quando i modelli vengono importati durante la migrazione.
• Il valore "pod_ec" è il tipo di server di destinazione usato per identificare il tipo di server su cui viene creata l'istanza.

Per eseguire la migrazione dei siti, effettuare le operazioni riportate di seguito.

1. Nel server di origine creare i modelli da ogni sito che include gli asset.
2. Nel server di origine esportare ogni modello. Assicurarsi di eseguire queste operazioni come l'utente al quale è stato fatto riferimento durante la registrazione del server di destinazione.
3. Nel server di destinazione collegarsi come amministratore del repository (utente con il ruolo CECRepositoryAdministrator). Quindi creare un repository per gli asset che verranno importati con il modello.
4. Per ogni modello scaricato, eseguire il comando seguente, sostituendo <site_name> con il nome di cui si desidera disponga il sito nel server di destinazione:

   > cec migrate-site <site_name> --template <template_path_and_name> 
   --destination <registered_target_server_name> --repository <repository_name>

5. Nel server di destinazione condividere in modo appropriato i siti e gli asset di cui è stata effettuata la migrazione.

Dopo la migrazione, il sito verrà eseguito con le chiamate Content REST versione 1.1. Ciò potrebbe causare problemi che devono essere risolti per consentire la corretta esecuzione del sito. Le istruzioni fornite di seguito consentono di determinare le azioni da eseguire.

• Se si utilizza ContentSDK, le chiamate verranno aggiornate in modo automatico per l'utilizzo delle chiamate Content REST versione 1.1.
• Se i layout di contenuto non indicano il supporto della versione 1.1, ContentSDK aggiungerà nella risposta la voce "data" (versione 1.0), che punterà semplicemente alla voce "fields" (versione 1.1) in modo che i modelli possano continuare a funzionare senza modifica.
• Se si utilizza la sintassi Content REST versione 1.0 "fields.type.equals=" nella query di stringa aggiuntiva, si tenterà di analizzarla e modificarla in modo che diventi una sintassi versione 1.1, ma l'utente dovrà convalidare tale modifica.
• Le eventuali chiamate Content REST versione 1.0 effettuate direttamente, anziché mediante ContentSDK, non riusciranno. Sarà quindi necessario correggere il codice personalizzato ed eseguire l'upgrade delle chiamate.
• Allo stesso modo è necessario che la sintassi versione 1.0 "fields.type.equals=" diventi la sintassi 'q=(type eq "..")' per le query di contenuto personalizzate.
• "updateddate" rispetto a "updatedDate": è prevista una correzione CaaS, ma finché non sarà disponibile una build EC in cui l'interfaccia API Content REST versione 1.1 API supporti entrambi i valori, sarà necessario modificare i valori "updateddate" in modo che diventino valori camelCase: "updatedDate".

Dopo aver verificato che viene eseguito in modo corretto, è necessario rendere il sito conforme alle specifiche MLS. Se si è creato un sito enterprise in un server di calcolo esterno, saranno necessari una lingua predefinita e un criterio di localizzazione. Poiché è stato copiato, il sito non è un sito MLS, pertanto è necessario eseguirne l'upgrade a sito MLS per garantire il supporto delle funzionalità future.

Nella tabella riportata di seguito vengono evidenziate le differenze tra i siti MLS e i siti non MLS.

Prima di convertire il sito in sito MLS è necessario effettuare le operazioni seguenti:

• upgrade di tutti componenti del layout di contenuto per supportare le API REST di contenuto versione 1.1
• upgrade di tutte le "stringhe query aggiuntive" nelle liste di contenuti del sito in modo che siano compatibili con l'interfaccia API REST di contenuto versione 1.1

Inoltre, se si dispone di codice di componenti personalizzati che effettua chiamate REST di contenuto, sarà necessario eseguirne l'upgrade per effettuare chiamate della versione 1.1. Non si tratta di una condizione comune in quanto la maggior parte delle chiamate di contenuto viene effettuata dai layout di contenuto.

Upgrade dei layout di contenuto

Specifica delle versioni delle API REST di contenuto supportate

È necessario che i layout di contenuto specifichino la versione delle API REST di contenuto che supportano. In questo modo si garantisce che venga effettuata la chiamata REST di contenuto appropriata per restituire i dati di risposta previsti al layout.

Se non si specifica alcun supporto di versione, si suppone che il layout di contenuto supporti solo la versione 1.0.

I layout di contenuto che supportano ancora la versione 1.0 vengono elencati nella console.

Per fare in modo che il layout di contenuto supporti altre versioni, aggiungere la proprietà "contentVersion" all'oggetto layout di contenuto.

In questo esempio, viene indicato che supporta tutte le versioni tra la 1.0 e la 2.0 non inclusa (nota: la versione 2.0 non esiste, ma le modifiche della versione principale potrebbero introdurre modifiche pericolose).

// Content Layout
          definition.ContentLayout.prototype = {    // Specify the versions of
          the Content REST API that are supported by the this Content Layout.    // The value for contentVersion follows Semantic Versioning
          syntax.    // This allows applications that use the
          content layout to pass the data through in the expected format.    contentVersion: ">=1.0.0
          <2.0.0",     // Main rendering function:    // - Updates the data to handle any required additional requests and
          support both v1.0 and v1.1 Content REST APIs    // - Expand the Mustache template with the updated data
            // - Appends the expanded template HTML to the
          parentObj DOM element    render: function (parentObj)
          {

Gestione delle modifiche della risposta versione 1.1

Il minimo che si dovrà fare è gestire la modifica della risposta dell'interfaccia API REST di contenuto da "data" a "fields". Il metodo più semplice per ottenere questo risultato consiste nel reintrodurre la proprietà "data" e nel puntare alla nuova proprietà "fields".

render: function (parentObj)
          {    ...    if(!content.data) {        content.data =
          content.fields;    }

Un'opzione migliore consiste nel modificare il codice per utilizzare il valore "fields" della versione 1.1 in tutti i layout di contenuto. Ciò comporta l'aggiornamento del codice JavaScript e del codice del modello.

Per supportare completamente la versione 1.1, sarà necessario gestire le modifiche dell'interfaccia API REST di contenuto riportate di seguito tra la versione 1.0 e la versione 1.1.

"items": [{    "type": "Starter-Blog-Author",    "name": "Alex Read",    "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63",    "fields":
          {        "starter-blog-author_bio": "Alex's bio",        "starter-blog-author_name": "Alex Read"        }    },

"items": [{    "type": "Starter-Blog-Author",    "name": "Alex Read",    "id": "COREB62DBAB5CEDA4915A9C9F6050E554F63",    "data":
          {        "starter-blog-author_bio": "Alex's bio",        "starter-blog-author_name": "Alex Read"        }    },

Upgrade della stringa di query del contenuto

È possibile che si effettuino chiamate dell'interfaccia API di contenuto nel codice personalizzato, pertanto è necessario convalidare l'insieme del codice personalizzato utilizzato dal sito per le chiamate dell'interfaccia API REST di contenuto.

• Componenti personalizzati: verificare i componenti riportati di seguito.
  • Layout di contenuto
  • Componenti locali
  • Layout sezione
  • Componenti remoti
• Temi - JavaScript: sebbene sia meno probabile, il tema potrebbe contenere JavaScript che effettua chiamate dell'API REST di contenuto, pertanto sarà necessario convalidare anche questo codice.
• Proprietà del sito - Stringa query aggiuntiva: dopo aver verificato di aver eseguito l'upgrade di tutto il codice personalizzato che effettua le chiamate dell'interfaccia API REST di contenuto, sarà necessario eseguire anche l'upgrade delle istanze di "Stringa query aggiuntiva" in tutti i componenti "Lista di contenuti" di tutte le pagine del sito. Anche se si tenterà di analizzarle e convertirle in runtime, è necessario eseguirne l'upgrade in modo che siano compatibili con le chiamate REST di contenuto versione 1.1 per garantire la continuità del supporto.

Conversione di un sito non MLS in sito MLS

Dopo aver convertito il sito per il supporto completo delle interfacce API REST di contenuto versione 1.1, sarà possibile aggiungere il supporto per le lingue impostando il sito come sito MLS.

Se si seleziona il sito nell'interfaccia utente di gestione dei siti, si vedrà l'opzione del menu di contenuto "traducibile". La selezione di questa opzione comporta la visualizzazione di una finestra di dialogo in cui viene richiesto di scegliere un criterio di localizzazione e una lingua predefinita per il sito dalla lista delle lingue richieste nel criterio di localizzazione. Se non esistono criteri di localizzazione, non sarà possibile completare questo passo e sarà in primo luogo necessario accedere alle schermate di amministrazione del contenuto e creare un criterio di localizzazione con almeno una lingua richiesta.

Dopo aver completato questo passo, il sito verrà visualizzato con le impostazioni nazionali predefinite. Consente inoltre di passare ad altre impostazioni nazionali specificate nei criteri di localizzazione.

Sarà necessario verificare che il rendering del sito venga eseguito come previsto nelle impostazioni nazionali predefinite.

Registrare i dettagli di connessione per i server di origine e di destinazione.

Registrare il server di origine (il server da cui si esegue la migrazione degli asset):

> cec register-server <source_server_name>
          -e http://<source_server>:<source_port>
          -u <source_username> -p <source_password>
          -t pod_ic

• <source_server_name> viene utilizzato per identificare l'endpoint di origine e può essere qualsiasi nome di propria scelta.
• <source_server> e <source_port> formano l'URL usato per accedere al server di origine.
• <source_username> e <source_password> devono essere il nome utente e la password della persona che può accedere agli asset nel server di origine.
• Il valore "pod_ic" è il tipo di server di origine usato per identificare il tipo di server su cui viene creata l'istanza.

Registrare il server di destinazione (il server verso il quale si esegue la migrazione degli asset):

> cec-install % cec register-server <target_server_name>
          -e http://<source_server>:<source_port>
          -u <target_username> -p <target_password>
          -t pod_ec

• <target_server_name> viene utilizzato per identificare l'endpoint di destinazione e può essere qualsiasi nome di propria scelta.
• <target_server> e <target_port> formano l'URL usato per accedere al server di destinazione.
• <target_username> e <target_password> devono essere il nome utente e la password della persona proprietaria degli asset nel server di destinazione.
• Il valore "pod_ec" è il tipo di server di destinazione usato per identificare il tipo di server su cui viene creata l'istanza.

Eseguire la migrazione di una raccolta di asset utilizzando il comando seguente:

> cec migrate-content <source_collection_name> --server  <source_server_name>
      --destination <target_server_name> --repository <target_repository_name> --collection  <target_collection_name> --channel
    <target_channel_name>

Gli asset verranno creati nel server di destinazione nel repository specificato e verranno associati alla raccolta e al canale. Se necessario, la raccolta e il canale verranno creati in modo automatico. La lingua predefinita per tutti gli asset di cui è stata eseguita la migrazione sarà la lingua predefinita impostata nel repository specificato.