Миграция экземпляра Oracle Content Management из устаревшей облачной инфраструктуры

"cec migrate-site" — новая команда, поэтому необходимо установить инструментарий OCE из репозитория Git веб-клиента, даже если он был выгружен и установлен ранее.

Следуйте инструкциям на странице инструментария сайтов, чтобы выгрузить и установить инструментарий OCE.

Зарегистрируйте сведения о подключении целевого сервера (сервера, на который осуществляется миграция сайтов):

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

• <target_server_name> используется для идентификации целевой конечной точки и может быть любым выбранным именем.
• <target_server> и <target_port> составляют URL-адрес, используемый для доступа к целевому серверу.
• <target_username> и <target_password> должны быть именем пользователя и паролем того пользователя, который будет экспортировать шаблоны сайтов из исходного сервера, чтобы при импорте шаблонов во время миграции не возникало проблем с разрешениями.
• Значение "pod_ec" — это тип целевого сервера, используется для определения типа сервера, на котором создан экземпляр.

Чтобы перенести сайты, выполните указанные ниже действия.

1. На исходном сервере создайте шаблоны для каждого сайта, содержащего активы.
2. На исходном сервере экспортируйте каждый шаблон. Убедитесь, что это действие выполнено от имени пользователя, на которого вы ссылались при регистрации целевого сервера.
3. На целевом сервере выполните вход как администратор репозитория (пользователь с ролью CECRepositoryAdministrator). Затем создайте репозиторий для активов, которые будут импортированы вместе с данным шаблоном.
4. Для каждого выгруженного шаблона выполните указанную ниже команду, заменив <site_name> именем, которое должно быть у сайта на целевом сервере:

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

5. На целевом сервере предоставьте соответствующий совместный доступ к перенесенным сайтам и активам.

После миграции сайт работает с использованием вызовов Content REST v1.1. Это может привести к возникновению проблем, которые необходимо устранить, чтобы сайт правильно работал. Чтобы определить, что необходимо сделать, обратите внимание на следующее:

• Если используется ContentSDK, вызовы автоматически обновляются для использования вызовов Content REST v1.1.
• Если макеты контента не поддерживают версию v1.1, ContentSDK также добавит в ответ запись "data" (v1.0), что просто указывает на запись "fields" (v1.1), чтобы шаблоны могли продолжать работать без изменений.
• Если в дополнительной строке запроса используется синтаксис "fields.type.equals=" v1.0 Content REST, попробуйте выполнить синтаксический анализ и изменить его на синтаксис версии v1.1. Однако это необходимо проверить.
• Все прямые (а не через ContentSDK) вызовы Content REST v1.0 завершаются ошибкой. Необходимо исправить пользовательский код и обновить такие вызовы.
• Точно так же потребуются все пользовательские запросы контента, использующие синтаксис v1.0 "fields.type.eques=" перевести на синтаксис "q=(type eq "..")".
• "updateddate" или "updatedDate": предположительно эта проблема исправлена в CaaS, но до получения сборки EC, в которой API-интерфейс Content REST v1.1 поддерживает оба значения, все значения "updateddate" необходимо изменить с учетом регистра, т. е. на значение "updatedDate".

Добившись правильной работы сайта необходимо обеспечить его соответствие требованиям к MLS. Если бы корпоративный сайт был создан на внешнем вычислительном сервере, то для него потребовались бы язык и политика локализации, используемые по умолчанию. После копирования сайта не является сайтом MLS, поэтому необходимо обновить его до сайта MLS, чтобы обеспечить поддержку будущих функциональных возможностей.

В таблице ниже показаны различия между сайтами MLS и другими сайтами.

Прежде чем превратить свой сайт в сайт MLS, необходимо выполнить следующие действия:

• Обновите все компоненты макета контента для поддержки API-интерфейсов Content REST версии 1.1
• В списках контента на сайте обновите все "дополнительные строки запроса", чтобы обеспечить совместимость с API-интерфейсами Content REST версии 1.1

Затем, если есть код пользовательского компонента, который совершает вызовы Content REST, необходимо обновить его, чтобы можно было выполнять вызовы версии 1.1. Это редко бывает, так как большинство вызовов контента осуществляется из макетов контента.

Обновление макетов контента

Указание поддерживаемых версий API-интерфейсов Content REST

Макеты контента должны указывать поддерживаемую версию API-интерфейсов Content REST. Это необходимо для того, чтобы выполнялся соответствующий вызов Content REST и в макет возвращались ожидаемые ответные данные.

Если поддержка версии не указана, предполагается, что макет контента поддерживает только версию 1.0.

В консоли будут перечислены макеты контента, которые все еще поддерживают версию 1.0.

Чтобы макет контента поддерживал другие версии, добавьте в объект макета контента свойство "contentVersion".

В этом примере указано, что поддерживаются все версии от 1.0 до 2.0. (Примечание. Версия 2.0 не существует, но изменения основной версии могут привести к критическим изменениям.)

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

Обработка изменений в версии 1.1

Потребуется, как минимум, обработать изменение ответа API-интерфейса Content REST: с "data" на "fields". Проще всего это сделать, если добавить свойство "data" и указать новое свойство "fields".

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

Лучший вариант изменения — перейти к использованию значения "fields" в версии 1.1 во всех макетах контента. Для этого потребуется обновить JavaScript и код шаблона.

Для полной поддержки версии 1.1 необходимо выполнить следующие изменения API-интерфейсов Content REST между версиями 1.0 к 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"        }    },

Обновление строки запроса контента

Интерфейс Content API может вызываться в любом пользовательском коде, поэтому необходимо проверить весь пользовательский код, используемый сайтом, совершающим вызовы API-интерфейсов Content REST.

• Пользовательские компоненты: проверьте следующие компоненты:
  • Макеты контента
  • Локальные компоненты
  • Макеты разделов
  • Удаленные компоненты
• Темы: JavaScript: очень низка вероятность того, что в вашей теме имеется код JavaScript, который выполняет пользовательские вызовы API-интерфейсов Content REST, поэтому их также следует проверить.
• Свойства сайта: дополнительная строка запроса: после подтверждения обновления всего пользовательского кода, который совершает вызовы API-интерфейсов Content REST, также следует обновить "дополнительную строку запроса" во всех компонентах "Список контента" на всех страницах сайта. Пока мы пытаемся проанализировать и преобразовать их во время выполнения, их следует обновить до состояния совместимости с вызовами Content REST версии 1.1 для дальнейшей поддержки.

Преобразование обычного сайта в сайт MLS

После преобразования сайта до полной поддержки API-интерфейсов Content REST версии 1.1 можно добавить поддержку языков, превратив сайт в сайт MLS.

Если выбрать сайт в пользовательском интерфейсе управления сайтом, появится пункт меню контента "Переводимый". Если выбрать этот пункт, открывается диалоговое окно с запросом выбора политики локализации и языка по умолчанию для сайта из списка требуемых языков в политике локализации. Если политики локализации нет, этот шаг выполнить невозможно, и сначала потребуется перейти к экранам администрирования контента и создать политику локализации, указав хотя бы один обязательный язык.

После выполнения этого шага сайт будет визуализироваться в соответствии с языковыми настройками по умолчанию. Кроме того, это позволит переключаться на другие языки, указанные в политике локализации.

Необходимо проверить, что сайт отображается в соответствии с языковыми настройками по умолчанию.

Зарегистрируйте сведения о подключении для исходного и целевого серверов.

Зарегистрируйте исходный сервер (сервер, с которого осуществляется миграция активов):

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

• <source_server_name> используется для идентификации исходной конечной точки и может быть любым выбранным именем.
• <source_server> и <source_port> составляют URL-адрес, используемый для доступа к исходному серверу.
• <source_username> и <source_password> должны быть именем пользователя и паролем для лица, имеющего доступ к активам на исходном сервере.
• Значение "pod_ic" — это тип исходного сервера, используется для определения типа сервера, на котором создан экземпляр.

Зарегистрируйте целевой сервер (сервер, на который осуществляется миграция активов):

> 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> используется для идентификации целевой конечной точки и может быть любым выбранным именем.
• <target_server> и <target_port> составляют URL-адрес, используемый для доступа к целевому серверу.
• <target_username> и <target_password> должны быть именем пользователя и паролем для лица с собственными активами на целевом сервере.
• Значение "pod_ec" — это тип целевого сервера, используется для определения типа сервера, на котором создан экземпляр.

Миграция набора активов выполняется с помощью следующей команды:

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

Активы будут созданы на целевом сервере в указанном репозитории и связаны с коллекцией и каналом. При необходимости коллекция и канал создаются автоматически. Язык по умолчанию для всех перенесенных активов — язык по умолчанию, заданный в указанном репозитории.