Migrar uma Instância do Oracle Content Management a partir de um Cloud Infrastructure Legado

O comando "cec migrate-site" é novo, por isso terá de instalar o OCE Toolkit a partir do repositório git do cliente para a Web, mesmo que o tenha descarregado e instalado anteriormente.

Siga as instruções na página do toolkit de sites para descarregar e instalar o OCE Toolkit.

Registe os detalhes da ligação para o servidor de destino (o servidor para o qual está a migrar os seus sites):

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

• O <target_server_name> é utilizado para identificar o endpoint de destino e pode ser qualquer nome à sua escolha.
• O <target_server> e <target_port> compõem o URL que utilizar para aceder ao servidor de destino.
• O <target_username> e <target_password> devem ser o nome de utilizador e a senha da pessoa que irá exportar os modelos de sites do servidor de origem, para não haver problemas de permissão quando os modelos forem importados durante a migração.
• O valor "pod_ec" é o tipo de servidor de destino, utilizado para identificar qual o tipo de servidor na qual a instância foi criada.

Para migrar os seus sites, efetue os seguintes passos:

1. No servidor de origem, crie modelos de cada site que inclui ativos.
2. No servidor de origem, exporte cada modelo. Certifique-se de que efetua este passo como o utilizador que referenciou quando registou o servidor de destino.
3. No servidor de destino, entre em sessão como administrador do repositório (um utilizador com o perfil de grupo CECRepositoryAdministrator). Em seguida, crie um repositório para os ativos que serão importados com o modelo.
4. Para cada modelo descarregado, execute o comando seguinte, substituindo <site_name> pelo nome que pretende que o site tenha no servidor de destino:

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

5. No servidor de destino, partilhe os sites e os ativos migrados de modo adequado.

Após ter migrado o seu site, este será executado utilizando chamadas REST de Conteúdo v1.1. Isto poderá causar alguns problemas que é necessário resolver para o site ser executado corretamente. Preste atenção ao seguinte para determinar o que necessita de fazer:

• Se estiver a utilizar o ContentSDK, as suas chamadas serão atualizadas automaticamente para utilizar chamadas REST de Conteúdo v1.1.
• Se as suas disposições de conteúdo não indicarem que suportam a v1.1, o ContentSDK irá também acrescentar a entrada "data" (v1.0) na resposta que irá apontar simplesmente para a entrada "fields" (v1.1), para que os seus modelos continuem a funcionar sem alteração.
• Se estiver a utilizar a sintaxe REST de Conteúdo v1.0 "fields.type.equals=" na sua cadeia de caracteres de consulta adicional, será feita uma tentativa de análise e modificação para a sintaxe v1.1, mas o utilizador deverá efetuar a respetiva validação.
• Se estiver a efetuar quaisquer chamadas REST de Conteúdo v1.0 diretas (e não via o ContentSDK), estas falharão. Será necessário corrigir o seu código customizado e atualizar estas chamadas.
• Do mesmo modo, será necessário que quaisquer consultas de conteúdo customizadas que utilizam a sintaxe v1.0 "fields.type.equals=" mudem para a sintaxe 'q=(type eq "..")'.
• "updateddate" vs. "updatedDate": Supostamente, isto está a ser corrigido pelo CaaS, mas até haver um build EC onde a API REST de Conteúdo v1.1 suporte ambos os valores, é necessário alterar quaisquer valores "updateddate" para o valor camelCase: "updatedDate".

Assim que o seu site estiver a ser executado corretamente, é necessário torná-lo compatível com MLS. Para criar um site Empresarial num servidor de External Compute, é necessária uma língua por omissão e um perfil de localização. Como o seu site foi copiado, não é um site MLS e, por isso, é necessário atualizá-lo para um site MLS de modo a garantir o suporte da funcionalidade futura.

A tabela seguinte mostra as diferenças entre sites MLS e não MLS.

Antes de transformar o seu site num site MLS, necessita de efetuar o seguinte:

• Atualize todos os seus componentes de disposição de conteúdo para suportarem APIs REST de Conteúdo v1.1
• Atualize quaisquer "cadeias de caracteres de consulta adicionais" nas suas listas de conteúdos no site de modo a serem compatíveis com a API REST de Conteúdo v1.1

Depois, se tiver código de componente customizado que efetue chamadas REST de Conteúdo, também terá de as atualizar para efetuar chamadas v1.1. Isto não é comum, uma vez que a maior parte das chamadas de conteúdo são efetuadas a partir de disposições de conteúdo.

Atualizar Disposições de Conteúdo

Especificar as Versões de API REST de Conteúdo Suportadas

As disposições de conteúdo devem especificar qual a versão da API REST de Conteúdo que suportam. Isto garante que é efetuada a chamada REST de Conteúdo adequada para devolver os dados de resposta esperados à disposição.

Se não especificar nenhum suporte de versão, assume-se que a disposição de conteúdo só suporta a v1.0.

A consola irá listar as disposições de conteúdo que ainda estão na v1.0.

Para permitir que a sua disposição de conteúdo suporte outras versões, acrescente a propriedade "contentVersion" ao seu objeto de disposição de conteúdo.

Neste exemplo, é indicado o suporte a todas as versões entre a v1.0 e anteriores à 2.0 (Nota: a 2.0 não existe, mas as alterações em versões principais podem introduzir mudanças radicais)

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

Processar Alterações de Resposta v1.1

O mínimo que terá de fazer é processar a alteração da resposta da API REST de Conteúdo de: "data" para "fields". A forma mais simples de o fazer é voltar a acrescentar a propriedade "data" e apontar para a nova propriedade "fields"

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

Uma opção melhor é começar a utilizar o valor "fields" v1.1 em todas as suas disposições de conteúdo. Isto irá envolver a atualização do seu código JavaScript e do modelo.

Para suporte total da v1.1, terá de processar as seguintes alterações da API REST de Conteúdo entre a v1.0 e a 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"        }    },

Atualizar a Cadeia de Caracteres de Consulta de Conteúdo

Poderá estar a efetuar chamadas da API de Conteúdo em qualquer código customizado e, por isso, é necessário validar todo o código customizado utilizado pelo seu site que esteja a efetuar chamadas da API REST de Conteúdo.

• Componentes Customizados: Verifique os seguintes componentes:
  • Disposições de Conteúdo
  • Componentes Locais
  • Disposições de Secção
  • Componentes Remotos
• Temas: JavaScript: Embora seja menos provável, poderá ter JavaScript no seu tema que esteja a efetuar chamadas customizadas da API REST de Conteúdo, pelo que também deve ser feita a respetiva validação.
• Propriedades do Site: Cadeia de Caracteres de Consulta Adicional: Após confirmar que atualizou todo o seu código customizado que efetua chamadas da API REST de Conteúdo, também deve atualizar a "Cadeia de Caracteres de Consulta Adicional" nos componentes "Lista de Conteúdos" existentes em quaisquer páginas do seu site. Embora haja uma tentativa de análise e conversão em runtime, deve ser feita a respetiva atualização para chamadas REST de Conteúdo compatíveis com v1.1, para suporte contínuo.

Converter um Site Não MLS em MLS

Depois de ter convertido o seu site para suporte total das APIs REST de Conteúdo v1.1, pode acrescentar suporte para línguas transformando-o num site MLS.

Se selecionar o seu site na IU de gestão de sites, verá uma opção de menu de conteúdo "traduzível". Se selecionar esta opção, será apresentada uma caixa de diálogo a pedir que escolha um perfil de localização e uma língua por omissão para o site a partir da lista de línguas obrigatórias no perfil de localização. Se não existir nenhum perfil de localização, não poderá concluir este passo e, primeiro, terá de aceder aos ecrãs de administração de conteúdo e criar um perfil de localização com, pelo menos, uma língua obrigatória.

Após concluir este passo, o seu site será agora renderizado nas definições locais por omissão. Também lhe permitirá mudar para outras definições locais especificadas no seu perfil de localização.

Será necessário confirmar que o seu site é renderizado conforme esperado nas suas definições sites por omissão.

Registe os detalhes da ligação para os servidores de origem e de destino.

Registe o servidor de origem (o servidor a partir do qual está a migrar os seus ativos):

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

• O <source_server_name> é utilizado para identificar o endpoint de origem e pode ser qualquer nome à sua escolha.
• O <source_server> e <source_port> compõem o URL que utilizar para aceder ao servidor de origem.
• O <source_username> e <source_password> devem ser o nome de utilizador e a senha da pessoa que pode aceder aos ativos no servidor de origem.
• O valor "pod_ic" é o tipo de servidor de origem, utilizado para identificar qual o tipo de servidor na qual a instância foi criada.

Registe o servidor de destino (o servidor para o qual está a migrar os seus ativos):

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

• O <target_server_name> é utilizado para identificar o endpoint de destino e pode ser qualquer nome à sua escolha.
• O <target_server> e <target_port> compõem o URL que utilizar para aceder ao servidor de destino.
• O <target_username> e <target_password> devem ser o nome de utilizador e a senha da pessoa que será a proprietária dos ativos no servidor de destino.
• O valor "pod_ec" é o tipo de servidor de destino, utilizado para identificar qual o tipo de servidor na qual a instância foi criada.

Migre uma coleção de ativos executando o comando seguinte:

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

Os ativos serão criados no servidor de destino, no repositório especificado, e serão associados à coleção e ao canal. Se for necessário, a coleção e o canal serão criados automaticamente. A língua por omissão para todos os ativos migrados será a língua por omissão que está definida no repositório especificado.