Migrere en Oracle Content Management-instans fra den ældre cloud-infrastruktur

Kommandoen "cec migrate-site" er ny, så du skal installere OCE Toolkit fra webklientens Git-informationsbase, selvom du tidligere har downloadet og installeret det.

Følg retningslinjerne på siden Sites Toolkit for at downloade og installere OCE Toolkit.

Registrer forbindelsesdetaljerne for målserveren (den server, som du migrerer dine sites 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> bruges til at identificere målslutpunktet og kan være ethvert navn, som du vælger.
• <target_server> og <target_port> udgør den URL, som du bruger til at oprette adgang til målserveren med.
• <target_username> og <target_password>skal være brugernavnet og adgangskoden for den person, som skal eksportere siteskabelonerne fra kildeserveren, så der ikke bliver tilladelsesproblemer, når skabelonerne importeres under migrering.
• Værdien "pod_ec" er målservertypen, der bruges til at identificere, hvilken type server instansen er bygget på.

Udfør følgende trin for at migrere dine sites:

1. På kildeserveren skal du oprette skabeloner fra hvert site, der indeholder aktiver.
2. På kildeserveren skal du eksportere hver skabelon. Sørg for at udføre dette trin som den bruger, som du refererede til, da du registrerede målserveren.
3. Log på målserveren som informationsbaseadministrator (en bruger med rollen CECRepositoryAdministrator). Opret derefter en informationsbase til de aktiver, der importeres sammen med skabelonen.
4. For hver downloadede skabelon skal du køre følgende kommando, idet du erstatter <site_name> med det navn, som sitet skal have på målserveren:

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

5. På målserveren skal du dele de migrerede sites og aktiver efter behov.

Når du har migreret dit site, kører det ved hjælp af indholds-REST v1.1-kald. Det kan give nogle problemer, som skal løses, før sitet kan køre korrekt. Læs følgende for at finde ud af, hvad du skal gøre:

• Hvis du bruger ContentSDK, bliver dine kald automatisk opdateret til at bruge v1.1-indholds-REST-kald.
• Hvis dine indholdslayouts ikke understøtter v1.1, tilføjer ContentSDK også posten "data" (v1.0) i svaret, hvilket blot peger på posten "fields" (v1.1), så dine skabeloner kan fortsætte med at virke uden ændringer.
• Hvis du bruger "fields.type.equals=" v1.0-indholds-REST-syntaksen i din yderligere forespørgselsstreng, forsøger vi at analysere og modificere dette til at være v1.1-syntaks, men du bør validere det.
• Hvis du foretager direkte (i stedet for via ContentSDK) indholds-REST v1.0-kald, mislykkes de. Du skal rette din tilpassede kode og opgradere disse kald.
• Du skal også have eventuelle tilpassede indholdsforespørgsler, som får "fields.type.equals=" v1.0-syntaksen til at være 'q=(type eq "..")'-syntaks.
• "updateddate" versus "updatedDate": Det skulle blive rettet af CaaS, men indtil vi har en EC-build, hvor indholds-REST v1.1 API understøtter begge værdier, skal du ændre eventuelle "updateddate"-værdier til værdien camelCase: "updatedDate".

Når dit site kører korrekt, skal du gøre det MLS-kompatibelt. Hvis du skal oprette et virksomhedssite på en External Compute-server, kræver det et standardsprog og en lokaliseringspolitik. Da dit site er kopieret over, er det ikke et MLS-site, så du skal opgradere det til et MLS-site for at sikre understøttelse af fremtidig funktionalitet.

Følgende tabel viser forskellene mellem MLS- og ikke-MLS-sites.

Før du gør dit site til et MLS-site, skal du gøre følgende:

• Opgrader alle dine indholdslayoutkomponenter til at understøtte indholds-REST-API'er v1.1
• Opgrader eventuelle "yderligere forespørgselsstrenge" på dine indholdslister på sitet til at være kompatible med indholds-REST-API v1.1

Hvis du har tilpasset komponentkode, der foretager indholds-REST-kald, skal du også opgradere dem til v1.1-kald. Det er ualmindeligt, da de fleste indholdskald foretages fra indholdslayouts.

Opgradering af indholdslayouts

Angivelse af understøttede indholds-REST-API-versioner

Indholdslayouts skal angive, hvilken version af indholds-REST-API de understøtter. Det sikrer, at det relevante indholds-REST-kald foretages for at returnere de forventede svardata til layoutet.

Hvis du ikke angiver nogen versionsunderstøttelse, antages det, at indholdslayoutet kun understøtter v1.0.

Konsollen viser de indholdslayouts, der stadig er på v1.0.

Hvis du vil gøre det muligt for dit indholdslayout at understøtte andre versioner, skal du føje egenskaben "contentVersion" til dit indholdslayoutobjekt.

I dette eksempel står der, at det understøtter alle versioner mellem v1.0 og 2.0 (Bemærk: 2.0 findes ikke, men større versionsændringer kan introducere nye ændringer).

// 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åndtering af v1.1-svarændringer

Du skal som minimum håndtere indholds-REST-API-svarændringen fra "data" til "fields". Det er nemmest at gøre ved at genindsætte egenskaben "data" og pege på den nye "fields"-egenskab

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

En bedre mulighed er at skifte over til at bruge v1.1-værdien "fields" i alle dine indholdslayouts. Det vil involvere opdatering af både JavaScript og skabelonkode.

For at få fuld understøttelse af v1.1 skal du håndtere følgende indholds-REST-API-ændringer mellem 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"        }    },

Opgradering af streng til indholdsforespørgslen

Du kan foretage indholds-API-kald i enhver tilpasset kode, så du skal validere al den tilpassede kode, der bruges af dit site og foretager indholds-REST-API-kald.

• Tilpassede komponenter: Kontroller følgende komponenter:
  • Indholdslayouts
  • Lokale komponenter
  • Sektionslayouts
  • Eksterne komponenter
• Temaer: JavaScript: Selvom det er mindre sandsynligt, kan du have JavaScript i dit tema, som foretager tilpassede indholds-REST-API-kald, så de skal også valideres.
• Egenskaber for site: Yderligere forespørgselsstreng: Når du har valideret, at du har opgraderet al din tilpassede kode, som foretager indholds-REST-API-kald, skal du også opgradere "Yderligere forespørgselsstreng" i eventuelle "Indholdsliste"-komponenter på alle sider af dit site. Vi forsøger at analysere og konvertere disse ved runtime, men de bør opgraderes til at være kompatible v1.1-indholds-REST-kald af hensyn til fortsat understøttelse.

Konvertering af ikke-MLS-site til MLS

Når du har konverteret dit site, så det understøtter v1.1-indholds-REST-API'er fuldt ud, kan du tilføje understøttelse af sprog ved at skifte til et MLS-site.

Hvis du vælger dit site i brugergrænsefladen for sitestyring, kan du se valget "Kan oversættes" i indholdsmenuen. Dette valg åbner en dialogboks, hvor du skal vælge en lokaliseringspolitik og et standardsprog for sitet på listen over påkrævede sprog i lokaliseringspolitikken. Hvis der ikke findes nogen lokaliseringspolitik, vil du ikke kunne fuldføre dette trin, og du skal først gå til skærmene for indholdsstyring og oprette en lokaliseringspolitik med mindst ét påkrævet sprog.

Når du har fuldført dette trin, gengives dit site i standardlandestandarden. Du kan også skifte til andre landestandarder, der er angivet i din lokaliseringspolitik.

Du skal validere, at dit site gengives som forventet i din standardlandestandard.

Registrer forbindelsesdetaljerne for kilde- og målserverne.

Registrer kildeserveren (den server, som du migrerer dine aktiver 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> bruges til at identificere kildeslutpunktet og kan være ethvert navn, som du vælger.
• <source_server> og <source_port> udgør den URL, som du bruger til at oprette adgang til kildeserveren med.
• <source_username> og <source_password> skal være brugernavnet og adgangskoden for den person, der har adgang til aktiverne på kildeserveren.
• Værdien "pod_ic" er kildeservertypen, der bruges til at identificere, hvilken type server instansen er bygget på.

Registrer målserveren (den server, som du migrerer dine aktiver 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> bruges til at identificere målslutpunktet og kan være ethvert navn, som du vælger.
• <target_server> og <target_port> udgør den URL, som du bruger til at oprette adgang til målserveren med.
• <target_username> og <target_password> skal være brugernavnet og adgangskoden for den person, der har adgang til aktiverne på målserveren.
• Værdien "pod_ec" er målservertypen, der bruges til at identificere, hvilken type server instansen er bygget på.

Migrer en samling af aktiver ved at kø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>

Aktiverne bliver oprettet på målserveren i den angivne informationsbase og bliver knyttet til samlingen og kanalen. Om nødvendigt bliver samlingen og kanalen oprettet automatisk. Standardsproget for alle migrerede aktiver bliver det standardsprog, som er konfigureret i den angivne informationsbase.