Migracja instancji Oracle Content Management z zastanej infrastruktury chmurowej

"cec migrate-site" jest nowym poleceniem, a zatem trzeba zainstalować zestaw OCE Toolkit z repozytorium Git klienta internetowego, nawet jeśli zestaw ten został wcześniej pobrany i zainstalowany.

Aby pobrać, a następnie zainstalować OCE Toolkit, należy postępować zgodnie z instrukcjami zawartymi na stronie "Sites Toolkit".

Należy zarejestrować szczegóły połączenia z serwerem docelowym (serwerem, do którego są kierowane zasoby poddane migracji):

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

• <nazwa_serwera_docelowego> służy do identyfikowania docelowego punktu końcowego; może to być dowolna nazwa wybrana przez użytkownika.
• <serwer_docelowy> i <port_docelowy> tworzą adres URL używany do uzyskiwania dostępu do serwera docelowego.
• Dla wartości <nazwa_użytkownika_docelowego> i <hasło_docelowe> należy użyć nazwy użytkownika i hasła osoby, która będzie eksportowała szablony serwisu z serwera źródłowego, dzięki czemu nie wystąpią problemy z uprawnieniami, gdy szablony będą importowane w trakcie migracji.
• Wartość "pod_ec" określa typ serwera docelowego. Wartość ta jest używana do identyfikacji typu serwera, na którym została utworzona instancja.

Aby przeprowadzić migrację serwisów, należy wykonać poniższe etapy:

1. Na serwerze źródłowym utworzyć szablony z każdego serwisu, który zawiera zasoby.
2. Na serwerze źródłowym wyeksportować każdy szablon. Należy się upewnić, że etap ten jest wykonywany przez użytkownika określonego podczas rejestrowania serwera docelowego.
3. Na serwerze docelowym zalogować się jako administrator repozytorium (użytkownik mający przypisaną rolę CECRepositoryAdministrator). Następnie należy utworzyć repozytorium dla zasobów, które będą importowane z szablonem.
4. Dla każdego pobranego szablonu uruchomić poniższe polecenie, zastępując fragment <nazwa_serwisu> nazwą serwisu, który ma się znaleźć na serwerze docelowym:

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

5. Na serwerze docelowym odpowiednio udostępnić serwisy i zasoby po migracji.

Serwis po migracji będzie działał z użyciem wywołań Content REST w wersji 1.1. Może to stwarzać pewne problemy, które trzeba rozwiązać, aby zapewnić poprawne działanie serwisu. Trzeba się przyjrzeć następującym kwestiom:

• Jeśli jest używany ContentSDK, wywołania zostaną automatycznie zaktualizowane do wywołań Content REST w wersji 1.1.
• Jeśli układy zawartości nie informują, że obsługują wersję 1.1, ContentSDK doda w odpowiedzi wpis "data" (wersja 1.0), który będzie wskazywał na wpis "fields" (wersja 1.1), dzięki czemu szablony będą mogły działać bez konieczności zmian.
• Jeśli w dodatkowym napisie-zapytaniu jest używana składnia "fields.type.equals=" z Content REST w wersji 1.0, spróbujemy rozłożyć ją i zmodyfikować tak, aby stała się składnią w wersji 1.1, lecz użytkownik powinien to sprawdzić.
• Jeśli są wykonywane jakiekolwiek bezpośrednie (nie przez ContentSDK) wywołania Content REST w wersji 1.0, to zakończą się niepowodzeniem. Należy wówczas uaktualnić wywołania, poprawiając swój kod.
• Analogicznie, należy przekształcić wszystkie niestandardowe zapytania dotyczące zawartości, w których jest używana składnia "fields.type.equals=" (wersja 1.0) w zapytania ze składnią 'q=(type eq "..")'.
• "updateddate" vs. "updatedDate": Na ogół jest to poprawiane przez CaaS, lecz — dopóki nie uzyskamy kompilatu EC, w którym Content REST API w wersji 1.1. obsługuje obie wartości — trzeba zmienić wszystkie wystąpienia "updateddate" na "updatedDate" (w notacji camelCase).

Mając poprawnie działający serwis, należy uczynić go serwisem wielojęzycznym (MLS — Multi-Lingual Site). Jeśli serwis firmowy został utworzony na zewnętrznym serwerze obliczeniowym, to wymagał języka domyślnego i założenia systemowego dotyczącego lokalizacji. Skopiowany serwis nie jest serwisem MLS, a zatem — aby zapewnić obsługę przyszłych funkcji — trzeba go uaktualnić do serwisu MLS.

W poniższej tabeli są pokazane różnice między serwisem MLS a serwisem nie-MLS.

Przed przystąpieniem do przekształcania serwisu w serwis MLS, należy:

• Uaktualnić wszystkie składniki elementów zawartości, tak aby obsługiwały Content REST API w wersji 1.1
• Uaktualnić na listach zawartości wszystkie dodatkowe napisy-zapytania, tak aby były zgodne z Content REST API w wersji 1.1

Mając kod składnika niestandardowego, zawierający wywołania Content REST, trzeba je także uaktualnić do wywołań w wersji 1.1. Na ogół jednak większość wywołań zawartości jest dokonywana z układów zawartości.

Uaktualnianie układów zawartości

Określenie obsługiwanych wersji Content REST API

Układy zawartości muszą określać, którą wersję Content REST API obsługują. Dzięki temu uzyskuje się pewność, że wykonywane jest odpowiednie wywołanie Content REST w celu uzyskania oczekiwanych danych w układzie.

Jeśli obsługiwana wersja nie będzie podana, zostanie przyjęte założenie, że układ zawartości obsługuje tylko wersję 1.0.

W konsoli będą wyszczególnione układy zawartości oparte na wersji 1.0.

Aby umożliwić układom zawartości obsługę innych wersji, należy dodać do obiektu układu zawartości właściwość "contentVersion".

W tym przykładzie układ zawartości informuje, że obsługuje wszystkie wersję zawarte między 1.0 a 2.0 (uwaga: wersja 2.0 nie istnieje, lecz wraz ze zmianą numeru głównego wersji mogą zostać wprowadzone znaczące zmiany).

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

Obsługa zmian w odpowiedzi w wersji 1.1

Aby zapewnić obsługę zmian w odpowiedzi Content REST API w wersji 1.1, należy — jako minimum — zmienić "data" na "fields". Najłatwiej jest to zrobić, dodając ponownie właściwość "data" i odwzorować ją na właściwość "fields".

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

Lepszym sposobem jest wprowadzenie zmiany polegającej na używaniu wartości "fields" (z wersji 1.1) we wszystkich układach zawartości. Wymagać to będzie aktualizacji kodu JavaScript i kodu szablonu.

W celu zapewnienia pełnej obsługi wersji 1.1 trzeba uwzględnić następujące różnice między Content REST API w wersji 1.0 i w wersji 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"        }    },

Uaktualnienie napisu-zapytania dla zawartości

Jeśli wywołania Content API są używane w kodzie niestandardowym, to trzeba sprawdzić całość kodu używanego przez serwis i upewnić się, że są to wywołania Content REST API.

• Składniki niestandardowe: Należy sprawdzić następujące składniki:
  • Układy zawartości
  • Składniki lokalne
  • Układy sekcji
  • Składniki odległe
• Motywy: JavaScript: Jest możliwe, że w używanym motywie istnieje kod JavaScript wykonujący niestandardowe wywołania Content REST API; w takim przypadku należy te wywołania sprawdzić.
• Właściwości serwisu: Dodatkowy napis-zapytanie: Po uaktualnieniu całości niestandardowego kodu wykonującego wywołania Content REST API należy także uaktualnić "Dodatkowy napis-zapytanie" we wszelkich składnikach "lista zawartości" na wszystkich stronach serwisu. Wprawdzie próbujemy przeanalizować składniowo i przekształcić te napisy-zapytania w trybie wykonawczym, to jednak — aby zapewnić bezustanną obsługę — należy przekształcić je w wywołania Content REST w wersji 1.1.

Przekształcanie serwisu nie-MLS w serwis MLS

Po uaktualnieniu serwisu, tak aby w pełni obsługiwał Content REST API w wersji 1.1, można dodać obsługę języków, zmieniając go w serwis MLS.

Jeśli serwis zostanie wybrany w UI zarządzania serwisami, to w menu podręcznym będzie widoczna opcja "Możliwe do przetłumaczenia" (Translatable). Gdy opcja ta zostanie wybrana, pojawi się okno dialogowe z prośbą o wybranie założenia systemowego dot. lokalizacji oraz języka domyślnego z listy wymaganych języków, zawartej w założeniu systemowym dot. lokalizacji. Jeśli nie istnieje żadne założenie systemowe dot. lokalizacji, nie będzie można ukończyć tego etapu — w takiej sytuacji trzeba najpierw przejść na stronę administrowania zawartością i utworzyć założenie systemowe dot. lokalizacji, zawierające przynajmniej jeden wymagany język.

Gdy etap ten zostanie ukończony, serwis będzie renderowany w języku domyślnym. Będzie także możliwe przełączanie się do innych ustawień narodowych, określonych w założeniu systemowym dot. lokalizacji.

Trzeba samodzielnie sprawdzić, czy serwis jest renderowany — zgodnie z oczekiwaniami — z użyciem domyślnych ustawień narodowych.

Można zarejestrować szczegóły połączenia dla serwerów źródłowych i docelowych.

Rejestrowanie serwera źródłowego (serwera, z którego pochodzą zasoby poddane migracji):

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

• <nazwa_serwera_źródłowego> służy do identyfikowania źródłowego punktu końcowego; może to być dowolna nazwa wybrana przez użytkownika.
• <serwer_źródłowy> i <port_źródłowy> tworzą adres URL używany do uzyskiwania dostępu do serwera źródłowego.
• Dla wartości <nazwa_użytkownika_źródłowego> i <hasło_źródłowe> należy użyć nazwy użytkownika i hasła osoby, która ma dostęp do zasobów znajdujących się na serwerze źródłowym.
• Wartość "pod_ic" określa typ serwera źródłowego. Wartość ta jest używana do identyfikacji typu serwera, na którym została utworzona instancja.

Rejestrowanie serwera docelowego (serwera, do którego są kierowane zasoby poddane migracji):

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

• <nazwa_serwera_docelowego> służy do identyfikowania docelowego punktu końcowego; może to być dowolna nazwa wybrana przez użytkownika.
• <serwer_docelowy> i <port_docelowy> tworzą adres URL używany do uzyskiwania dostępu do serwera docelowego.
• Dla wartości <nazwa_użytkownika_docelowego> i <hasło_docelowe> należy użyć nazwy użytkownika i hasła osoby, która będzie właścicielem zasobów znajdujących się na serwerze docelowym.
• Wartość "pod_ec" określa typ serwera docelowego. Wartość ta jest używana do identyfikacji typu serwera, na którym została utworzona instancja.

Migracja kolekcji zasobów odbywa się poprzez uruchomienie następującego polecenia:

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

Zasoby zostaną utworzone na serwerze docelowym w określonym repozytorium oraz będą powiązane z kolekcją i kanałem. Jeśli będzie to potrzebne, kolekcja i kanał zostaną automatycznie utworzone. Domyślnym językiem wszystkich zasobów poddanych migracji będzie język domyślny, który został ustawiony w określonym repozytorium.