Oracle Content Management-Instanz von Legacy-Cloud-Infrastruktur migrieren

Der Befehl "cec migrate-site" ist neu. Sie müssen also das OCE Toolkit vom Webclient-Git-Repository installieren, selbst wenn Sie das Tool bereits heruntergeladen und installiert haben.

Befolgen Sie die Anweisungen auf der Seite "Sites Toolkit", um das OCE Toolkit herunterzuladen und zu installieren.

Registrieren Sie die Verbindungsdetails für den Zielserver (der Server, in den Sie Sites migrieren):

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

• Mit dem <target_server_name>, den Sie frei wählen können, wird der Zielendpunkt identifiziert.
• Die URL für den Zugriff auf den Zielserver setzt sich aus dem <target_server> und dem <target_port> zusammen.
• Der <target_username> und das <target_password> muss der Benutzernamen und das Kennwort für die Person sein, die die Sitevorlagen vom Quellserver exportiert, damit keine Berechtigungsprobleme auftreten, wenn die Vorlagen bei der Migration importiert werden.
• Der Wert "pod_ec" ist der Zielservertyp, mit dem der Servertyp identifiziert wird, auf dem die Instanz aufgebaut wurde.

Führen Sie die folgenden Schritte aus, um Sites zu migrieren:

1. Auf dem Quellserver müssen Sie aus jeder Site, die Assets enthält, Vorlagen erstellen.
2. Exportieren Sie jede Vorlage auf dem Quellserver. Führen Sie diesen Schritt als der Benutzer aus, den Sie beim Registrieren des Zielservers referenziert haben.
3. Melden Sie sich als Repository-Administrator (Benutzer mit der Rolle "CECRepositoryAdministrator") beim Zielserver an. Führen Sie dann die Schritte zum Erstellen eines Repositorys für die Assets aus, die mit der Vorlage importiert werden.
4. Führen Sie für jede heruntergeladene Vorlage den folgenden Befehl aus, und ersetzen Sie dabei <site_name> durch den gewünschten Namen der Site auf dem Zielserver:

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

5. Geben Sie die migrierten Sites und Assets auf dem Zielserver entsprechend frei.

Nach der Migration der Site wird diese mit Content-REST-v1.1-Aufrufen ausgeführt. Dadurch können einige Probleme entstehen, die Sie lösen müssen, bevor die Site ordnungsgemäß ausgeführt wird. Bestimmen Sie die erforderliche Vorgehensweise anhand der folgenden Informationen:

• Wenn Sie das ContentSDK verwenden, werden die Aufrufe automatisch zur Verwendung von v1.1-Content-REST-Aufrufen aktualisiert.
• Wenn Ihre Inhaltslayouts nicht angeben, dass sie v1.1 unterstützen, fügt das ContentSDK den "data"-Eintrag (v1.0) in der Antwort hinzu, der auf den "fields"-Eintrag (v1.1) verweist. So können Sie Ihre Vorlagen ohne Änderung weiter verwenden.
• Wenn Sie die v1.0-Content-REST-Syntax "fields.type.equals=" in der zusätzlichen Abfragezeichenfolge verwenden, versucht Oracle, diese zu parsen und in v1.1-Syntax zu ändern. Sie sollten die Ergebnisse aber prüfen.
• Wenn Sie direkte Content-REST-v1.0-Aufrufe (anstelle des ContentSDK) verwenden, verlaufen diese nicht erfolgreich. Sie müssen Ihren benutzerdefinierten Code korrigieren und diese Aufrufe upgraden.
• Gleichermaßen müssen Sie alle benutzerdefinierten Inhaltsabfragen mit der v1.0-Syntax "fields.type.equals=" in die Syntax "q=(type eq "..")" ändern.
• "updateddate" und "updatedDate": Dieser Unterschied wird laut Angaben von CaaS korrigiert. Bis ein EC-Build verfügbar ist, in dem die Content-REST-v1.1-API beide Werte unterstützt, müssen Sie aber alle "updateddate"-Werte in den camelCase-Wert "updatedDate" ändern.

Wenn die Site korrekt ausgeführt wird, müssen Sie sicherstellen, dass sie mehrere Sprachen unterstützt. Wenn Sie eine Enterprise-Site in einem External Compute-Server erstellen, erfordert diese eine Standardsprache und eine Lokalisierungs-Policy. Die Site wurde als Nicht-MLS-Site kopiert. Daher müssen Sie ein Upgrade auf eine MLS-Site durchführen, damit Sie die jeweiligen Funktionen in Zukunft unterstützen können.

Die folgende Tabelle zeigt die Unterschiede zwischen MLS- und Nicht-MLS-Sites.

Führen Sie folgende Schritte aus, bevor Sie Ihre Site zu einer MLS-Site machen:

• Führen Sie ein Upgrade aller Inhaltslayoutkomponenten durch, sodass diese Content-REST-APIs v1.1 unterstützen.
• Führen Sie ein Upgrade aller "zusätzlichen Abfragezeichenfolgen" in Ihren Inhaltslisten in der Site durch, sodass diese mit Content-REST-API v1.1 kompatibel sind.

Wenn Sie benutzerdefinierten Komponentencode verwenden, der Content-REST-Aufrufe ausführt, müssen Sie dann auch diesen für v1.1-Aufrufe upgraden. Das ist eher selten der Fall, da die meisten Inhaltsaufrufe von Inhaltslayouts durchgeführt werden.

Inhaltslayouts upgraden

Unterstützte Content-REST-API-Versionen angeben

Inhaltslayouts müssen angeben, welche Version der Content-REST-API sie unterstützten. So wird sichergestellt, dass der richtige Content-REST-Aufruf gesendet wird, um die erwarteten Antwortdaten an das Layout zurückzugeben.

Wenn Sie keine unterstützte Version angeben, wird davon ausgegangen, dass das Inhaltslayout nur v1.0 unterstützt.

Der Inhaltslayouts, die noch auf v1.0 basieren, werden in der Konsole aufgelistet.

Damit Ihr Inhaltslayout andere Versionen unterstützt, fügen Sie die Eigenschaft "contentVersion" zum Inhaltslayoutobjekt hinzu.

In diesem Beispiel wird die Unterstützung aller Versionen von v1.0 bis unter 2.0 angegeben. (Hinweis: 2.0 gibt es nicht, aber Hauptversionsänderungen können wichtige Änderungen mit sich bringen.)

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

Antwortänderungen mit v1.1 verarbeiten

Sie müssen zumindest die Änderung in der Content-REST-API-Antwort von "data" in "fields" unterstützen. Am einfachsten geht das, indem Sie die "data"-Eigenschaft hinzufügen und auf die neue "fields"-Eigenschaft verweisen.

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

Besser wäre es aber, eine Änderung vorzunehmen, um den "fields"-Wert von v1.1 in allen Inhaltslayouts zu verwenden. Dazu müssen Sie den JavaScript-Code und den Vorlagencode aktualisieren.

Zur vollständigen Unterstützung von v1.1 müssen Sie die folgenden Content-REST-API-Änderungen zwischen v1.0 und v1.1 verarbeiten:

"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"        }    },

Inhaltsabfragezeichenfolge upgraden

Möglicherweise verwenden Sie benutzerdefinierten Code mit Content-API-Aufrufen. Daher müssen Sie den gesamten von der Site verwendeten benutzerdefinierten Code mit Content-REST-API-Aufrufen validieren.

• Benutzerdefinierte Komponenten: Prüfen Sie die folgenden Komponenten:
  • Inhaltslayouts
  • Lokale Komponenten
  • Abschnittslayouts
  • Remotekomponenten
• Themes: JavaScript: Auch wenn das weniger wahrscheinlich ist, verwenden Sie eventuell JavaScript-Code in Ihrem Theme, der Content-REST-API-Aufrufe sendet. Dieser muss also ebenfalls validiert werden.
• Siteeigenschaften: Zusätzliche Abfragezeichenfolge: Wenn Sie sichergestellt haben, dass Sie den gesamten benutzerdefinierten Code mit Content-REST-API-Aufrufen upgegradet haben, müssen Sie auch ein Upgrade der zusätzlichen Abfragezeichenfolge in allen Inhaltslistenkomponenten auf den Seiten Ihrer Site vornehmen. Auch wenn Oracle versucht, diese zur Laufzeit zu parsen und zu konvertieren, sollten sie für die weitere Unterstützung auf kompatible v1.1-Content-REST-Aufrufe upgegradet werden.

Nicht-MLS-Site in MLS-Site konvertieren

Nach der Konvertierung der Site für die vollständige Unterstützung von v1.1-Content-REST-APIs können Sie die Unterstützung mehrerer Sprachen hinzufügen, indem Sie die Site zu einer MLS-Site machen.

Wenn Sie die Site in der Sitemanagement-UI auswählen, wird die Option "Übersetzbar" im Inhaltsmenü angezeigt. Wenn Sie auf diese Option klicken, wird ein Dialogfeld geöffnet, in dem Sie eine Lokalisierungs-Policy und eine Standardsprache für die Site in der Liste der erforderlichen Sprachen in der Lokalisierungs-Policy auswählen. Wenn keine Lokalisierungs-Policys vorhanden sind, können Sie diesen Schritt nicht ausführen. Dann müssen Sie zunächst zu den Bildschirmen für die Inhaltsadministration gehen und eine Lokalisierungs-Policy mit mindestens einer erforderlichen Sprache erstellen.

Anschließend wird die Site im Standardgebietsschema gerendert. Sie können dann auch zu anderen in der Lokalisierungs-Policy angegebenen Gebietsschemas wechseln.

Stellen Sie sicher, dass die Site wie erwartet im Standardgebietsschema gerendert wird.

Registrieren Sie die Verbindungsdetails für den Quell- und den Zielserver.

Registrieren Sie den Quellserver (der Server, aus dem Sie Assets migrieren):

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

• Mit dem <source_server_name>, den Sie frei wählen können, wird der Quellendpunkt identifiziert.
• Die URL für den Zugriff auf den Quellserver setzt sich aus dem <source_server> und dem <source_port> zusammen.
• Der <source_username> und das <source_password> müssen der Benutzername und das Kennwort für die Person sein, die auf die Assets auf dem Quellserver zugreifen kann.
• Der Wert "pod_ic" ist der Quellservertyp, mit dem der Servertyp identifiziert wird, auf dem die Instanz aufgebaut wurde.

Registrieren Sie den Zielserver (der Server, in den Sie Assets migrieren):

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

• Mit dem <target_server_name>, den Sie frei wählen können, wird der Zielendpunkt identifiziert.
• Die URL für den Zugriff auf den Zielserver setzt sich aus dem <target_server> und dem <target_port> zusammen.
• Der <target_username> und das <target_password> müssen der Benutzername und das Kennwort für die Person sein, die Eigentümer des Assets auf dem Zielserver sein wird.
• Der Wert "pod_ec" ist der Zielservertyp, mit dem der Servertyp identifiziert wird, auf dem die Instanz aufgebaut wurde.

Migrieren Sie eine Assetsammlung, indem Sie den folgenden Befehl ausführen:

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

Die Assets werden auf dem Zielserver im angegebenen Repository erstellt und mit der Sammlung und dem Kanal verknüpft. Gegebenenfalls werden die Sammlung und der Kanal automatisch erstellt. Die Standardsprache für alle migrierten Assets ist die im angegebenen Repository festgelegte Standardsprache.