Migraţi o instanţă Oracle Content Management de la infrastructura cloud moştenită

Comanda "cec migrate-site" este nouă, ceea ce înseamnă că va trebui să instalaţi OCE Toolkit din repository-ul git webclient, chiar dacă l-aţi descărcat şi instalat anterior.

Urmaţi instrucţiunile din pagina sites toolkit pentru a descărca şi instala OCE Toolkit.

Înregistraţi detaliile de conectare pentru serverul destinaţie (serverul către care migraţi site-urile):

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

• <target_server_name> se utilizează pentru identificarea punctului final destinaţie şi îi puteţi atribui orice nume doriţi.
• <target_server> şi <target_port> alcătuiesc adresa URL pe care o utilizaţi pentru a accesa serverul destinaţie.
• <target_username> şi <target_password> trebuie să reprezinte numele de utilizator şi parola pentru persoana care va exporta şabloanele site-ului din serverul sursă, astfel încât să nu apară probleme privind permisiunile atunci când şabloanele sunt importate pe parcursul migrării.
• Valoarea "pod_ec" reprezintă tipul serverului destinaţie şi se utilizează pentru identificarea tipului de server pe baza căruia este construită instanţa.

Pentru a migra site-uri, parcurgeţi paşii următori:

1. Pe serverul sursă, creaţi şabloane din fiecare site care conţine resurse.
2. Pe serverul sursă, exportaţi fiecare şablon. Asiguraţi-vă că parcurgeţi acest pas ca utilizator indicat atunci când aţi înregistrat serverul de destinaţie.
3. Pe serverul ţintă, conectaţi-vă ca administrator de repository (utilizator cu rolul CECRepositoryAdministrator). Apoi crea un repository pentru resursele care vor fi importate cu şablonul.
4. Pentru fiecare şablon descărcat, rulaţi următoarea comandă, înlocuind <site_name> cu numele pe care doriţi să-l aibă site-ul pe serverul destinaţie:

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

5. Pe serverul destinaţie, partajaţi site-urile şi resursele migrate în mod corespunzător.

După ce aţi migrat site-ul, acesta va rula utilizând apelări Content REST v1.1. Acest lucru poate genera unele probleme care trebuie rezolvate înainte ca site-ul să poată rula corect. Pentru a stabili ce aveţi de făcut, observaţi următoarele:

• Dacă utilizaţi ContentSDK, apelările dvs. vor fi actualizate automat pentru a utiliza apelări Content REST v1.1.
• Dacă machetele de conţinut nu transmit că acceptă v1.1, ContentSDK va adăuga, de asemenea, intrarea "data" (v1.0) în răspuns, care va indica pur şi simplu către intrarea "fields" (v1.1), astfel încât şabloanele să funcţioneze în continuare fără nicio modificare.
• Dacă utilizaţi sintaxa Content REST v1.0 "fields.type.equals=" în şirul de interogare suplimentar, noi încercăm să-l interpretăm şi să-l modificăm pentru a respecta sintaxa v1.1, dar ar trebui ca dvs. să validaţi acest lucru.
• Dacă efectuaţi apelări directe Content REST v1.0 (în loc de cele efectuate prin ContentSDK), acestea vor eşua. Va trebui să remediaţi codul personalizat şi să upgradaţi aceste apelări.
• Similar, trebuie ca interogările de conţinut personalizate care creează sintaxa v1.0 "fields.type.equals=" să aibă sintaxa 'q=(type eq "..")'.
• "updateddate" vs. "updatedDate": Acest lucru ar trebui să fie remediat de CaaS, însă, până la obţinerea unei versiuni interne EC în care API-ul Content REST v1.1 va accepta ambele valori, trebuie să modificaţi valorile "updateddate" astfel încât să aibă valoarea camelCase: "updatedDate".

După ce aţi creat site-ul şi acesta funcţionează corect, trebuie să îl configuraţi astfel încât să fie conform cu normele pentru site-urile multilingve. Dacă doriţi să creaţi un site al companiei pe un server de calcul extern, acesta va avea nevoie de o limbă prestabilită şi de o politică de localizare. Deoarece site-ul dvs. a fost copiat ca atare, acesta nu este conform cu normele pentru site-uri multilingve, deci va trebui să îl upgradaţi la un astfel de site pentru a vă asigura că acesta va accepta adăugarea ulterioară de funcţionalităţi.

Următorul tabel arată diferenţele dintre site-urile web neconforme cu normele pentru site-uri multilingve şi cele conforme.

Înainte de a putea transforma site-ul într-unul conform cu normele pentru site-uri multilingve, trebuie să faceţi următoarele:

• Upgradaţi toate componentele machetelor de conţinut astfel încât să accepte API-urile REST Content v1.1
• Upgradaţi toate "şirurile de interogare suplimentare" din listele de conţinut ale site-ului astfel încât să fie compatibile cu API-ul REST Content v1.1

Apoi, dacă aveţi cod de componente personalizate care efectuează apeluri către API-ul REST Content, trebuie să upgradaţi şi acest cod astfel încât să efectueze apeluri v1.1. Această situaţie este puţin uzuală, deoarece majoritatea apelurilor către conţinut sunt efectuate din machetele de conţinut.

Upgradarea machetelor de conţinut

Specificarea versiunilor compatibile ale API-ului REST Content

Machetele de conţinut trebuie să specifice versiunea API-ului REST Content cu care sunt compatibile. Acest lucru este necesar pentru a se asigura că se efectuează un apel corespunzător către API-ul REST Content, în vederea returnării în machetă a datelor de răspuns aşteptate.

Dacă nu specificaţi informaţii privind compatibilitatea cu anumite versiuni, se va considera că macheta de conţinut este compatibilă doar cu versiunea v1.0.

Consola va lista machetele de conţinut care încă utilizează versiunea v1.0.

Pentru a permite machetei de conţinut să accepte alte versiuni, adăugaţi proprietatea "contentVersion" la obiectul machetei de conţinut.

În acest exemplu, macheta indică faptul că este compatibilă cu toate versiunile între v1.0 şi 2.0 (Notă: versiunea 2.0 nu există, însă schimbările majore de versiuni pot introduce modificări )

// 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)
          {

Tratarea schimbărilor de răspunsuri din versiunea v1.1

Pentru aceasta, tot ce trebuie să faceţi este să trataţi modificarea răspunsului API-ului REST Content de la "data" la "fields". Pentru acest lucru, cel mai simplu este să adăugaţi proprietatea "data" şi să indicaţi către noua proprietate "fields"

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

O opţiune mai bună este să schimbaţi configuraţia pentru a utiliza valoarea "fields" din versiunea v1.1 în toate machetele dvs. de conţinut. Acest lucru implică actualizarea atât a codului JavaScript, cât şi a codului şablonului.

Pentru a accepta pe deplin versiunea v1.1, va trebui să trataţi următoarele modificări ale API-ului REST Content de la versiunea v1.0 la versiunea v1.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"        }    },

Upgradarea şirului de interogare pentru conţinut

Este posibil să efectuaţi apeluri către API-ul Content în orice porţiune a codului personalizat, aşa că trebuie să validaţi întregul cod personalizat utilizat de site-ul dvs. care efectuează apeluri către API-ul REST Content.

• Componente personalizate: Verificaţi următoarele componente:
  • Machete de conţinut
  • Componente locale
  • Machete de secţiuni
  • Componente la distanţă
• Teme: JavaScript: Deşi este mai puţin probabil, este posibil ca în tema dvs. să existe elemente JavaScript care efectuează apeluri către API-ul REST Content, deci vor trebui validate şi aceste elemente.
• Proprietăţi site: Şir de interogare suplimentar: După ce aţi validat faptul că aţi upgradat întregul cod personalizat care efectuează apeluri către API-ul REST Content, trebuie să upgradaţi şi "Şirul de interogare suplimentar" din cadrul componentelor "Listă de conţinut" de pe paginile site-ului dvs. Încercăm să analizăm şi să convertim aceste apeluri la runtime, însă pentru a se asigura compatibilitatea permanentă, acestea ar trebui upgradate pentru a fi compatibile cu API-urile REST Content v1.1.

Convertirea unui site care nu este conform cu normele pentru site-uri multilingve într-unul conform

După ce aţi convertit site-ul pentru a fi compatibil pe deplin cu API-urile REST Content v1.1, puteţi adăuga suport pentru versiuni lingvistice prin convertirea site-ului într-un site conform cu normele pentru site-uri multilingve.

Dacă selectaţi site-ul dorit în interfaţa de administrare, veţi vedea o opţiune de meniu pentru conţinutul "traductibil". Dacă selectaţi această opţiune, se va afişa un dialog în care vi se solicită să selectaţi o politică de localizare şi o limbă prestabilită pentru site din lista de limbi necesare din politica de localizare. Dacă nu există nicio politică de localizare, nu veţi putea finaliza acest pas şi va trebui să accesaţi mai întâi ecranele de administrare a conţinutului şi să creaţi o politică de localizare care să conţină cel puţin o limbă necesară.

După finalizarea acestui pas, site-ul dvs. va fi randat în varianta locală prestabilită. De asemenea, veţi putea să comutaţi la alte variante locale specificate în politica de localizare.

Va trebui să validaţi faptul că site-ul este randat conform aşteptărilor, în varianta locală prestabilită.

Înregistraţi detaliile de conectare pentru serverele sursă şi destinaţie.

Înregistraţi serverul sursă (serverul de pe care migraţi resursele):

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

• <source_server_name> se utilizează pentru identificarea punctului final sursă şi îi puteţi atribui orice nume doriţi.
• <source_server> şi <source_port> alcătuiesc adresa URL pe care o utilizaţi pentru a accesa serverul sursă.
• <source_username> şi <source_password> trebuie să reprezinte numele de utilizator şi parola pentru persoana care poate accesa resursele de pe serverul sursă.
• Valoarea "pod_ic" reprezintă tipul serverului sursă şi se utilizează pentru identificarea tipului de server pe baza căruia este construită instanţa.

Înregistraţi serverul destinaţie (serverul pe care migraţi resursele):

> 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> se utilizează pentru identificarea punctului final destinaţie şi îi puteţi atribui orice nume doriţi.
• <target_server> şi <target_port> alcătuiesc adresa URL pe care o utilizaţi pentru a accesa serverul destinaţie.
• <target_username> şi <target_password> trebuie să reprezinte numele de utilizator şi parola pentru persoana care va deţine resursele de pe serverul destinaţie.
• Valoarea "pod_ec" reprezintă tipul serverului destinaţie şi se utilizează pentru identificarea tipului de server pe baza căruia este construită instanţa.

Migraţi o colecţie de resurse utilizând următoarea comandă:

> 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>

Resursele vor fi create pe serverul destinaţie în repository-ul specificat şi vor fi asociate cu colecţia şi cu canalul. Dacă este necesar, colecţia şi canalul vor fi create automat. Limba prestabilită pentru toate resursele migrate va fi limba prestabilită care este setată în repository-ul specificat.