Migrera en instans av Oracle Content Management från den äldre molninfrastrukturen

Kommandot "cec migrate-site" är nytt, så du måste installera verktygen för OCE från Git-datalagret för webbklienten även om du har laddat ned och installerat dem tidigare.

Följ anvisningarna på sidan med webbplatsverktygslåda för att ladda ned och installera verktygen för OCE.

Registrera anslutningsdetaljerna för målservern (servern du migrerar webbplatserna till):

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

• <target_server_name> används till att identifiera målslutpunkten och kan väljas fritt.
• <target_server> och <target_port> utgör den URL du använder till att komma åt målservern.
• <target_username> och <target_password> måste vara användarnamnet och lösenordet för personen som ska exportera webbplatsmallarna från källservern, så att det inte uppstår problem med behörigheter när mallarna importeras i samband med migreringen.
• Värdet pod_ec anger målservertypen och används till att identifiera vilken typ av server instansen är byggd på.

Utför följande steg om du vill migrera dina webbplatser:

1. På källservern ska du skapa mallar från varje webbplats som inkluderar tillgångar.
2. På källservern ska du sedan exportera varje mall. Se till att du utför det här steget som den användare du refererade till när du registrerade målservern.
3. Gå till målservern och logga in som datalageradministratör (en användare med rollen CECRepositoryAdministrator). Därefter ska du skapa ett datalager för de tillgångar som ska importeras med mallen
4. För varje nedladdad mall kör du sedan följande kommando, där du ersätter <site_name> med namnet du vill att webbplatsen ska ha på målservern:

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

5. Dela de migrerade webbplatserna och tillgångarna på lämpligt sätt på målservern.

När du har migrerat webbplatsen körs den med hjälp av innehålls-REST v1.1-anrop. Det här kan orsaka vissa problem som måste lösas innan webbplatsen körs korrekt. Ta en titt på följande för att fastställa vad du behöver göra:

• Om du använder ContentSDK uppdateras anropen automatiskt så att v1.1-innehålls-REST-anrop används.
• Om innehållslayouterna inte anger att de stöder v1.1 lägger ContentSDK även till posten "data" (v1.0) i svaret som helt enkelt pekar på posten "fields" (v1.1), så att mallen kan fortsätta fungera utan ändring.
• Om du använder syntaxen "fields.type.equals=" för innehålls-REST v1.0 i den extra frågesträngen försöker vi parsa och ändra den till v1.1-syntax, men du ska validera detta.
• Om du gör några direkta innehålls-REST v1.0-anrop (snarare än via ContentSDK) utförs de inte. Du måste korrigera den anpassade koden och uppgradera de här anropen.
• På samma sätt måste du se till att alla anpassade innehållsfrågor som använder v.1.0-syntaxen "fields.type.equals=" får syntaxen 'q=(type eq "..")'.
• "updateddate" kontra "updatedDate": Det påstås att det här korrigeras av CaaS, men tills vi har fått ett EC-bygge där innehålls-REST v1.1-API:t stöder båda värdena måste du ändra alla "updateddate"-värden till värdet med kamelNotation: "updatedDate".

När webbplatsen körs korrekt måste du se till att göra den kompatibel med flerspråkiga webbplatser. Om du skulle skapa en företagswebbplats på en extern beräkningsserver skulle den kräva ett standardspråk och en språkanpassningspolicy. När din webbplats kopieras över är den en icke-flerspråkig webbplats, så du måste uppgradera den till en flerspråkig webbplats för att säkerställa att du har stöd för framtida funktioner.

I följande tabell visas skillnaderna mellan flerspråkiga och icke-flerspråkiga webbplatser.

Innan du kan förvandla webbplatsen till en flerspråkig webbplats måste du göra följande:

• Uppgradera alla innehållslayoutkomponenter så att de stöder REST-API:er för innehåll v1.1
• Uppgradera alla eventuella "extra frågesträngar" i innehållslistorna på webbplatsen så att de är kompatibla med REST-API för innehåll v1.1

Om du sedan råkar ha någon anpassad komponentkod som gör innehålls-REST-anrop måste du även uppgradera dessa så att v1.1-anrop görs. Det här är ovanligt eftersom de flesta innehållsanrop görs från innehållslayouter.

Uppgradera innehållslayouter

Ange de versioner av REST-API:er för innehåll som stöds

Innehållslayouter måste ange vilken version av REST-API:t för innehåll de har stöd för. Syftet med detta är att säkerställa att ett lämpligt innehålls-REST-anrop görs, så att förväntade svarsdata returneras till layouten.

Om du inte specificerar något versionsstöd antas det att innehållslayouten endast har stöd för v1.0.

Konsolen visar en lista över de innehållslayouter som fortfarande använder v1.0.

Om du vill att innehållslayouten ska ha stöd för andra versioner lägger du till egenskapen "contentVersion" i innehållslayoutobjektet.

I det här exemplet anges att den stöder alla versioner mellan v1.0 och lägre än 2.0 (Obs! 2.0 finns inte, men stora versionsändringar kan medföra icke-bakåtkompatibla ändringar)

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

Hantera v1.1-svarsändringar

Det minsta du måste göra är att hantera ändringen av svaret för REST-API:t för innehåll från: "data" till "fields". Det enklaste sättet att göra detta är att lägga till egenskapen "data" och peka på den nya egenskapen "fields"

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

Ett bättre alternativ är att ändra till att använda v1.1-värdet för "fields" i alla innehållslayouter. Det här involverar uppdatering av både JavaScript- och mallkoden.

För att uppnå fullständigt stöd för v1.1 måste du hantera följande ändringar för REST-API för innehåll mellan v1.0 och 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"        }    },

Uppgradera innehållsfrågesträng

Du kan göra API-anrop för innehåll med valfri anpassad kod, så du måste validera all den anpassade kod som används av webbplatsen för REST-API-anrop för innehåll.

• Anpassade komponenter: Kontrollera följande komponenter:
  • Innehållslayouter
  • Lokala komponenter
  • Sektionslayouter
  • Fjärrkomponenter
• Teman: JavaScript: Även om det är mindre sannolikt, kan du ha JavaScript i temat som gör anpassade REST-API-anrop för innehåll, så dessa ska också valideras.
• Egenskaper för webbplats: Extra frågesträng: När du har validerat att du har uppgraderat all anpassad kod som gör REST-API-anrop för innehåll ska du även uppgradera den "extra frågesträngen" i eventuella "innehållslistkomponenter" på alla sidor på webbplatsen. Vi försöker visserligen parsa och konvertera dessa vid exekveringen, men de ska ändå uppgraderas så att de är kompatibla v1.1-innehålls-REST-anrop för fortsatt support.

Konvertera en icke-flerspråkig webbplats till en flerspråkig webbplats

När du har konverterat webbplatsen så att den har fullt stöd för REST-API:er för innehåll v1.1 kan du lägga till stöd för språk genom att ändra till en flerspråkig webbplats.

Om du väljer din webbplats i användargränssnittet för webbplatsadministration ser du innehållsmenyalternativet "Översättningsbart". Om du väljer det här alternativet visas en dialogruta där du ombeds välja en språkanpassningspolicy och ett standardspråk för webbplatsen i listan över obligatoriska språk i språkanpassningspolicyn. Om det inte finns några språkanpassningspolicyer kan du inte utföra det här steget. Då måste du först gå till fönstren för innehållsadministration och skapa en språkanpassningspolicy med minst ett obligatoriskt språk.

När du har slutfört det här steget återges webbplatsen med standardspråkkonventionen. Den ger dig även möjlighet att växla till andra språkkonventioner som finns angivna i språkanpassningspolicyn.

Du måste validera att webbplatsen återges som förväntat med standardspråkkonventionen.

Registrera anslutningsdetaljerna för käll- och målservrarna.

Registrera källservern (servern du migrerar tillgångarna från):

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

• <source_server_name> används till att identifiera källslutpunkten och kan väljas fritt.
• <source_server> och <source_port> utgör den URL du använder för att komma åt källservern.
• För <source_username> och <source_password> måste du ange användarnamnet och lösenordet för den person som har åtkomst till tillgången på källservern.
• Värdet pod_ic anger källservertypen och används till att identifiera vilken typ av server instansen är byggd på.

Registrera målservern (servern du migrerar tillgångarna till):

> 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> används till att identifiera målslutpunkten och kan väljas fritt.
• <target_server> och <target_port> utgör den URL du använder till att komma åt målservern.
• För <target_username> och <target_password> måste du ange användarnamnet och lösenordet för den person som ska äga tillgångarna på målservern.
• Värdet pod_ec anger målservertypen och används till att identifiera vilken typ av server instansen är byggd på.

Migrera en samling tillgångar genom att köra följande 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>

Tillgångarna skapas på målservern i det angivna datalagret och associeras med samlingen och kanalen. Vid behov skapas samlingen och kanalen automatiskt. Standardspråket för alla migrerade tillgångar är det standardspråk som angetts i det angivna datalagret.