Migrácia inštancie služby Oracle Content Management zo staršej verzie služby Cloud Infrastructure

Príkaz "cec migrate-site" je nový, preto je potrebné nainštalovať súpravu OCE Toolkit z depozitára GIT webového klienta, aj keď ste ju už stiahli a nainštalovali v minulosti.

Ak si chcete stiahnuť a nainštalovať súpravu OCE Toolkit, postupujte podľa pokynov na stránke súpravy Sites Toolkit.

Zaregistrujte detaily pripojenia cieľového servera (server, na ktorý migrujete lokality):

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

• Hodnota <target_server_name> sa používa na identifikáciu cieľového koncového bodu, ktorý môže mať akýkoľvek názov.
• Hodnoty <target_server> a <target_port> tvoria adresu URL, ktorú používate na prístup k cieľovému serveru.
• Hodnoty <target_username> a <target_password> musia predstavovať meno používateľa a heslo osoby, ktorá vyexportuje šablóny lokalít zo zdrojového servera, aby nedošlo k problémom s povoleniami pri importovaní šablón počas migrácie.
• Hodnota "pod_ec" je typ cieľového servera a používa sa na identifikáciu typu servera, na ktorom je vytvorená inštancia.

Ak chcete migrovať lokality, postupujte takto:

1. Na zdrojovom serveri vytvorte šablóny z jednotlivých lokalít obsahujúcich položky.
2. Na zdrojovom serveri exportujte jednotlivé šablóny. Tento krok je potrebné vykonať ako používateľ, ktorého ste uviedli pri registrácii cieľového servera.
3. Na cieľovom serveri sa prihláste ako administrátor depozitára (používateľ s rolou CECRepositoryAdministrator). Potom vytvorte depozitár pre položky, ktoré sa importujú spolu so šablónou.
4. Pre každú stiahnutú šablónu spustite nasledujúci príkaz, ktorý nahradí <site_name> názvom, ktorý požadujete pre lokalitu na cieľovom serveri:

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

5. Na cieľovom serveri primerane zdieľajte migrované lokality a položky.

Po migrovaní bude lokalita využívať volania Content REST v. 1.1. Môže to spôsobiť problémy, ktoré je potrebné vyriešiť, aby lokalita mohla fungovať správne. Pozrite si nasledujúce informácie, aby ste určili, čo je potrebné urobiť:

• Ak používate súpravu ContentSDK, volania sa automaticky aktualizujú, aby používali volania Content REST v. 1.1.
• Ak rozloženia obsahu neuvádzajú podporu pre verziu 1.1, súprava ContentSDK tiež pridá do odozvy záznam "data" (v. 1.0), ktorý jednoducho bude odkazovať na záznam "fields" (v. 1.1). Šablóny tak môžu naďalej fungovať bez zmeny.
• Ak v ďalšom reťazci dopytu používate syntax „fields.type.equals=“ Content REST v. 1.0, pokúšame sa syntakticky analyzovať a upraviť ju na syntax v 1.1, no mali by ste to overiť.
• Ak uskutočňujete priame volania Content REST v. 1.0 (namiesto volaní cez súpravu ContentSDK), tieto volania zlyhajú. Bude potrebné opraviť vlastný kód a zvýšiť verziu týchto volaní.
• Podobne potrebujete, aby prípadné vlastné dopyty na obsah vytvárajúce syntax „fields.type.equals=“ v. 1.0 vytvárali syntax 'q=(type eq "..")'.
• „updateddate“ v. „updatedDate“: Tento problém údajne odstraňuje CaaS, no do doby, keď budeme mať k dispozícii kompiláciu, v ktorej rozhranie Content REST API v. 1.1 podporuje obe hodnoty, je potrebné zmeniť hodnoty „updateddate“ na hodnotu camelCase: „updatedDate“.

Po správnom spustení lokality je následne potrebné zaistiť jej súlad s viacjazyčnými lokalitami. Ak by ste vytvorili podnikovú lokalitu na externom serveri Compute, bol by potrebný predvolený jazyk a stratégia lokalizácie. Keďže vaša lokalita bola skopírovaná, nejde o viacjazyčnú lokalitu, preto je potrebné zvýšiť jej verziu na viacjazyčnú lokalitu, aby sa zaistila podpora budúcich funkcionalít.

V nasledujúcej tabuľke sú uvedené rozdiely medzi viacjazyčnými a inými lokalitami.

Skôr než zmeníte lokalitu na viacjazyčnú, je potrebné vykonať tieto kroky:

• Zvýšiť verziu všetkých komponentov rozloženia obsahu tak, aby podporovali rozhrania Content REST API v. 1.1.
• Zvýšiť verziu všetkých „ďalších reťazcov dopytu“ v zoznamoch obsahu na lokalite tak, aby bola kompatibilná s rozhraním Content REST API v. 1.1.

Ak sa potom stane, že budete mať kód vlastného komponentu, ktorý vytvára volania Content REST, je potrebné zvýšiť aj jeho verziu tak, aby jeho volania boli verzie 1.1. Je to zriedkavé, pretože väčšinu volaní vytvárajú rozloženia obsahu.

Zvýšenie verzie rozložení obsahu

Určenie podporovaných verzií rozhrania Content REST API

Rozloženia obsahu musia špecifikovať, ktorú verziu rozhrania Content REST API podporujú. Cieľom je zaistiť, aby sa vytvárali správne volania Content REST, ktoré vrátia do rozloženia očakávané dáta odozvy.

Ak neuvediete podporu žiadnej verzie, predpokladá sa, že rozloženie obsahu podporuje iba verziu 1.0.

Konzola bude uvádzať zoznam rozložení obsahu, ktoré sú stále vo verzii 1.0.

Ak chcete povoliť, aby rozloženie obsahu podporovalo ďalšie verzie, pridajte vlastnosť "contentVersion" do objektu rozloženia obsahu.

V tomto príklade je uvedené, že podporuje všetky verzie od 1.0 do 2.0 (poznámka: verzia 2.0 neexistuje, ale významné zmeny verzií môžu priniesť prelomové zmeny).

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

Postup pri zmenách odozvy vo verzii 1.1

Ako minimum bude potrebné vykonať zmenu odozvy rozhrania Content REST API z vlastnosti "data" na "fields". Najjednoduchší spôsob je pridať späť vlastnosť "data" a odkazovať na novú vlastnosť "fields".

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

Lepší postup je prejsť na používanie hodnoty "fields" verzie 1.1 vo všetkých rozloženiach obsahu. Bude to zahŕňať aktualizáciu JavaScriptu aj kódu šablóny.

Ak chcete získať plnú podporu verzie 1.1, je potrebné vykonať nasledujúce zmeny rozhrania Content REST API medzi verziami 1.0 a 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"        }    },

Zvýšenie verzie reťazca dopytu na obsah

Je možné, že vytvárate volania rozhrania Content API vo vlastnom kóde, preto je potrebné overiť celý vlastný kód, ktorý používa lokalita vytvárajúca volania rozhrania Content REST API.

• Vlastné komponenty: Skontrolujte nasledujúce komponenty:
  • Rozloženia obsahu
  • Lokálne komponenty
  • Rozloženia sekcií
  • Vzdialené komponenty
• Motívy: JavaScript: Aj keď je to menej pravdepodobné, v motíve môžete mať JavaScript, ktorý vytvára vlastné volania rozhrania Content REST API, preto je potrebné overiť aj motívy.
• Vlastnosti lokality: Ďalší reťazec dopytu: Po overení zvýšenia verzia kompletného vlastného kódu, ktorý vytvára volania rozhrania Content REST API, je tiež potrebné zvýšiť verziu vlastnosti Ďalší reťazec dopytu vo všetkých komponentoch Zoznam obsahu na všetkých stránkach vašej lokality. Aj keď sa snažíme syntakticky analyzovať a konvertovať všetky tieto položky v čase behu, je potrebné zvýšiť ich verziu, aby boli kompatibilné s volaniami Content REST v. 1.1 a mali naďalej podporu.

Konverzia lokality na viacjazyčnú lokalitu

Po skonvertovaní lokality na úplnú podporu rozhraní Content REST API v. 1.1 môžete pridať podporu pre jazyky zmenou lokality na viacjazyčnú.

Ak vyberiete lokalitu v používateľskom rozhraní správy lokalít, v ponuke obsahu uvidíte voľbu „preložiteľné“. Po výbere tejto voľby sa zobrazí dialógové okno s výzvou na výber stratégie lokalizácie a predvoleného jazyka pre lokalitu zo zoznamu požadovaných jazykov v stratégii lokalizácie. Ak neexistujú žiadne stratégie lokalizácie, nebudete tento krok môcť dokončiť. Najskôr budete musieť prejsť na obrazovky administrácie obsahu a vytvoriť stratégiu lokalizácie s aspoň jedným požadovaným jazykom.

Po dokončení tohto kroku sa vaša lokalita bude vykresľovať v predvolenom miestnom nastavení. Takisto vám to umožní prepínať na iné miestne nastavenia uvedené v stratégii lokalizácie.

Bude potrebné overiť, či sa lokalita vo vašom predvolenom miestnom nastavení vykresľuje podľa očakávaní.

Zaregistrujte detaily pripojenia pre zdrojový a cieľový server.

Zaregistrujte zdrojový server (server, z ktorého migrujete položky):

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

• Hodnota <source_server_name> sa používa na identifikáciu zdrojového koncového bodu, ktorý môže mať akýkoľvek názov.
• Hodnoty <source_server> a <source_port> tvoria adresu URL, ktorú používate na prístup k zdrojovému serveru.
• Hodnoty <source_username> a <source_password> musia predstavovať meno používateľa a heslo pre osobu, ktorá bude mať prístup k položkám na zdrojovom serveri.
• Hodnota "pod_ic" je typ zdrojového servera a používa sa na identifikáciu typu servera, na ktorom je vytvorená inštancia.

Zaregistrujte cieľový server (server, na ktorý migrujete položky):

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

• Hodnota <target_server_name> sa používa na identifikáciu cieľového koncového bodu, ktorý môže mať akýkoľvek názov.
• Hodnoty <target_server> a <target_port> tvoria adresu URL, ktorú používate na prístup k cieľovému serveru.
• Hodnoty <target_username> a <target_password> musia predstavovať meno používateľa a heslo pre osobu, ktorá bude vlastniť položky na cieľovom serveri.
• Hodnota "pod_ec" je typ cieľového servera a používa sa na identifikáciu typu servera, na ktorom je vytvorená inštancia.

Migrujte kolekciu položiek spustením nasledujúceho príkazu:

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

Položky sa vytvoria na cieľovom serveri v zadanom depozitári a budú priradené ku kolekcii a kanálu. Ak je to potrebné, kolekcia a kanál sa vytvoria automaticky. Predvolený jazyk pre všetky migrované položky bude predvolený jazyk nastavený v zadanom depozitári.