Migrere en Oracle Content Management-forekomst fra en eldre Cloud-infrastruktur

Kommandoen cec migrate-site er ny, så du må installere OCE-verktøysettet fra Web-klientens git-register selv om du tidligere har lastet det ned og installerte det.

Følg retningslinjene på siden Sites Toolkit når du skal laste ned og installere OCE-verktøysettet.

Registrer tilkoblingsdetaljene for måltjeneren (tjeneren du migrerer områdene til):

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

• <target_server_name> brukes for å identifisere målsluttpunktet, og kan være hvilket som helst navn.
• <target_server> og <target_port> inngår i URL-adressen du bruker for å få tilgang til måltjeneren.
• <target_username> og <target_password> må være brukernavnet og passordet for personen som skal eksportere områdemalene fra kildetjeneren, slik at det ikke oppstår tillatelsesproblemer når malene blir importert under migreringen.
• Verdien "pod_ec" viser til måltjenertypen, og brukes for å angi hvilken type tjener forekomsten er bygd på.

Utfør følgende trinn når du skal migrere områdene:

1. På kildetjeneren kan du opprette maler fra hvert område som inneholder aktiva.
2. På kildetjeneren kan du eksportere hver mal. Forsikre deg om at du utfører dette trinnet som brukeren du refererte til da du registrerte måltjeneren.
3. Logg på som registeradministrator (en bruker med rollen CECRepositoryAdministrator) på måltjeneren. Det neste du gjør, er å opprette et register for aktivaene som skal importeres med malen.
4. Kjør følgende kommando for hver nedlastet mal. Erstatt <site_name> med navnet du vil at området skal ha på måltjeneren:

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

5. På måltjeneren deler du de migrerte områdene og aktivaene på riktig måte.

Når du har migrert området, kjører det med Content REST v1.1-kall. Det kan forårsake problemer som må løses før området kjører på riktig måte. Finn ut hva du skal gjøre ved å se på følgende:

• Hvis du bruker ContentSDK, blir kallene dine automatisk oppdatert til å bruke v1.1 Content REST-kall.
• Hvis innholdsoppsettene ikke sier at de støtter v1.1, legger ContentSDK også til data-oppføringen (v1.0) i svaret, noe som ganske enkelt peker på fields-oppføringen (v1.1), så malene kan fortsette å arbeide uten endring.
• Hvis du bruker v1.0 Content REST-syntaksen fields.type.equals= i den ekstra spørringsstrengen, prøver vi ikke å analysere og endre dette til v1.1-syntaks, men du må validere dette.
• Hvis du utfører noen direkte (i stedet for via ContentSDK) Content REST v1.0-kall, vil de mislykkes. Du må rette den egendefinerte koden og oppgradere disse kallene.
• På samme måte trenger du hvilke som helst egendefinerte innholdsspørringer som gjør fields.type.equals= v1.0-syntaks om til q=(type eq "..")-syntaks.
• updateddate kontra updatedDate: Dette skal være rettet av CaaS, men inntil vi får en EC-bygging der Content REST v1.1-API-et støtter begge verdier, må du endre alle updateddate-verdier til camelCase: updatedDate-verdien.

Når området kjører på riktig måte, kan du gjøre området MLS-kompatibelt. Hvis du skal opprette et foretaksområde for ekstern beregning på en tjener, trenger du et standardspråk og retningslinjer for lokalisering. Siden området er kopiert, er det et ikke-MLS-område, så du må oppgradere det til et MLS-område slik at du sikrer støtte for fremtidig funksjonalitet.

Følgende tabell viser forskjellene mellom MLS- og ikke-MLS-områder.

Før du kan gjøre området til et MLS-område, må du gjøre følgende:

• Oppgrader alle innholdsoppsettkomponenter slik at de støtter Content REST API-er v1.1
• Oppgrader alle ekstra spørringsstrenger i innholdslistene i området slik at de blir kompatible med Content REST API v1.1

Deretter, hvis du har en hvilken som helst egendefinert komponentkode som utfører Content REST-kall, må du også oppgradere disse til å utføre v1.1-kall. Dette er uvanlig siden de fleste innholdskall gjøres fra innholdsoppsett.

Oppgradere innholdsoppsett

Angi støttede versjoner av Content REST-API-et

Innholdsoppsett må angi hvilken versjon av Content REST-API-et de støtter. Det gjøres for å sikre at det blir utført riktige Content REST-kall for å returnere de forventede svardataene til oppsettet.

Hvis du ikke angir noen versjonsstøtte, antas det at innholdsoppsettet bare støtter v1.0.

Konsollen viser innholdsoppsettene som fremdeles er på v1.0.

Hvis du vil at innholdsoppsettet skal støtte andre versjoner, legger du til egenskapen contentVersion i innholdsoppsettsobjektet.

I dette eksemplet sies det at det støtter alle versjoner mellom v1.0 og mindre enn 2.0 (Merknad: 2.0 finnes ikke, men viktige versjonsendringer kan introdusere store endringer)

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

Håndtere svarendringer i v1.1

Du må i det minste være i stand til å håndtere endringer av Content REST-API-et fra data til fields. Den enkleste måten å gjøre dette på, er å legge til egenskapen data på nytt, og peke på den nye fields-egenskapen

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

Et bedre valg er å bruke fields-verdien for v1.1 i alle innholdsoppsettene. Dette omfatter å oppdatere både JavaScript- og malkoden.

Hvis du vil ha fullstendig støtte av v1.1, må du være i stand til å håndtere følgende endringer av Content REST-API-et mellom v1.0 og 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"        }    },

Oppgradere innholdsspørringsstrengen

Du kan sende API-kall til innholdet til en hvilken som helst egendefinert kode slik at du må validere alle de egendefinerte kodene som brukes av området, som sender innholdskall til REST-API-et.

• Egendefinerte komponenter: Kontroller følgende komponenter:
  • Innholdsoppsett
  • Lokale komponenter
  • Deloppsett
  • Eksterne komponenter
• Temaer: JavaScript: Selv om det er mindre sannsynlig, kan du ha JavaScript i temaet som sender egendefinerte innholdskall til REST-APIet slik at de også blir validert.
• Områdeegenskaper: Ekstra spørrestreng: Når du har validert at du har oppgradert all egendefinert kode som utgjør innholdskallene til REST-API-et, bør du også oppgradere den ekstra spørrestrengen i alle innholdslistekomponenter på alle sider i området. Mens vi prøver å analysere og konvertere disse under kjøring, må de oppgraderes slit at de blir kompatible REST-innholdskall v1.1, slik at de fortsatt blir støttet.

Konvertere et ikke-MLS-område til MLS

Når du har konvertert området slik at det får fullstendig støtte for v1.1 av REST-API-er for innhold, kan du legge til støtte for språk ved å endre til et MLS-område.

Hvis du velger området i brukergrensesnittet for områdebehandling, ser du valget Kan oversettes på innholdsmenyen. Hvis du velger dette, vises en dialogboks som ber deg velge en lokaliseringsretningslinje og et standardspråk for området fra listen over nødvendige språk i lokaliseringsretningslinjen. Hvis det ikke finnes noen lokaliseringsretningslinje, kan du ikke fullføre dette trinnet, og du må først gå til skjermbildene for innholdsadministrasjon og opprette en lokaliseringsretningslinje med minst ett nødvendig språk.

Når du har fullført dette trinnet, gjengis området med standard regionale innstillinger. Du kan også bytte til andre regionale innstillinger som er angitt i lokaliseringsretningslinjene.

Du må validere at området gjengis som forventet i standard regionale innstillinger.

Registrer tilkoblingsdetaljene for kilde- og måltjenerne.

Registrer kildetjeneren (tjeneren du migrerer aktiva fra):

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

• <source_server_name> brukes for å identifisere kildesluttpunktet, og kan være hvilket som helst navn.
• <source_server> og <source_port> inngår i URL-adressen du bruker for å få tilgang til kildetjeneren.
• <source_username> og <source_password> må være brukernavnet og passordet til personen som kan få tilgang til aktivaene på kildetjeneren.
• Verdien "pod_ic" viser til kildetjenertypen, og brukes for å angi hvilken type tjener forekomsten er bygd på.

Registrer måltjeneren (tjeneren du migrerer aktiva til):

> 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> brukes for å identifisere målsluttpunktet, og kan være hvilket som helst navn.
• <target_server> og <target_port> inngår i URL-adressen du bruker for å få tilgang til måltjeneren.
• <target_username> og <target_password> må være brukernavnet og passordet til personen som vil eie aktivaene på måltjeneren.
• Verdien "pod_ec" viser til måltjenertypen, og brukes for å angi hvilken type tjener forekomsten er bygd på.

Migrer en samling av aktiva ved å kjøre følgende kommando:

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

Aktivaene opprettes på måltjeneren i det angitte registeret, og de knyttes til samlingen og kanalen. Hvis det er nødvendig, opprettes samlingen og kanalen automatisk. Standardspråket for alle migrerte aktiva blir standardspråket som er definert i det angitte registeret.