Se você tiver instâncias do Oracle Content Management em execução no Cloud infrastructure legado com uma assinatura sem medição de consumo, a Oracle recomenda que você migre essas instâncias para o novo ambiente do Oracle Cloud Infrastructure (OCI) nativo - OCI 2ª Geração (ou seja, usando a Console do Infrastructure para gerenciar instâncias de serviço). Isso vai garantir que você desfrute dos benefícios e avanços da plataforma de nuvem da Oracle no futuro.
Para iniciar a migração, você precisará executar algumas etapas antes da migração e trabalhar com o Suporte Técnico da Oracle para programar a migração.
Esta tabela descreve o mapeamento de grupos de permissões do Oracle Content Management para atribuições de aplicativos do OCI.
| Grupo de Permissões do Oracle Content Management | Atribuição de Aplicativo do OCI |
|---|---|
| DocumentsServiceUser | CECStandardUser |
| DocumentsServiceAdmin | CECServiceAdministrator |
| SitesServiceVisitor | CECSitesVisitor |
| SitesServiceAdmin | CECSitesAdministrator |
| ContentAdministratorRole | CECContentAdministrator |
| CECSStandardUser | CECStandardUser |
| CECSEnterpriseUser | CECEnterpriseUser |
Nota:
Se o domínio de destino do IDCS já contiver um usuário com o mesmo nome, o usuário receberá as atribuições de aplicativos do OCI correspondentes aos grupos de permissões do Oracle Content Management do usuário.Quando estiver pronto para sua migração, você deverá submeter uma solicitação de migração para iniciar o processo:
Depois que o Suporte Técnico da Oracle receber sua solicitação de serviço de migração, vamos programar sua migração com base na data solicitada, e a solicitação de serviço será atualizada com a data e o horário em que a migração vai começar.
As atualizações serão feitas na solicitação de serviço para mostrar como está o andamento da migração. A migração de dados será feita no back end; nenhuma ação será necessária da sua parte, a não ser acompanhar as atualizações da solicitação de serviço, e validar a migração após sua conclusão.
Isto é o que acontece durante a migração:
Importante:
Nesse ponto, você não deve fazer nenhuma alteração na instância antiga (de origem). Quaisquer alterações feitas após o início da migração não serão migradas para a nova instância.Nota:
A instância antiga permanecerá ativa para que você possa consultá-la novamente para validação. Você também precisará dela para migrar qualquer site que use ativos e para migrar qualquer outro ativo que foi excluído durante a migração.Caso a instância antiga esteja integrada ou comunicada com outros serviços ou aplicativos, seja diretamente ou por meio de chamadas de API REST, talvez seja necessário executar tarefas de pós-migração.
Os itens a seguir se aplicam no nível do serviço:
Os URLs antigos usavam o seguinte padrão:
https://<service-name>-<account-name>.<region>.oraclecloud.com/documents
Os URLs novos usavam o seguinte padrão:
https://<service-name>-<account-name>.<service-type>.ocp.oraclecloud.com/documents
| Integração | Coisas a Serem Feitas após a Migração |
|---|---|
| Oracle Integration |
|
| Oracle Commerce Cloud |
|
| Oracle Process Cloud Service |
|
| Oracle Eloqua Cloud Service |
|
| Oracle Intelligent Advisor |
|
| Oracle Cobrowse Cloud Service |
|
| Responsys |
|
| Visual Builder Cloud Service (VBCS) |
|
| CDN/Akamai |
|
| Chamadas de API REST |
|
| Uso de SDK/CLI cliente |
|
| Conectores |
|
Nota:
Quaisquer marcadores de conteúdo na instância antiga não funcionarão mais, porque o URL da nova instância foi alterado.Os sites que não incluírem ativos serão migrados automaticamente, mas aqueles que de fato incluírem ativos exigirão algumas etapas adicionais para fazê-los funcionar em sua nova instância do Oracle Content Management.
O comando "cec migrate-site" é novo; por isso, instale o OCE Toolkit pelo repositório git do webclient mesmo que você o tenha baixado e instalado anteriormente.
Siga as orientações na página do kit de ferramentas de sites para fazer download e instalar o OCE Toolkit.
Anote os detalhes da conexão do servidor de destino (o servidor para o qual você está migrando seus sites):
> cec register-server <target_server_name>
-e http://<target_server>:<target_port>
-u <target_username> -p <target_password>
-t pod_ec
Para migrar seus sites, execute as seguintes etapas:
<site_name> pelo nome que o site deverá ter no servidor de destino:
> cec migrate-site <site_name> --template <template_path_and_name> --destination <registered_target_server_name> --repository <repository_name>
Depois de ter migrado seu site, ele será executado usando chamadas REST de Conteúdo v1.1. Isso pode causar alguns problemas que precisam ser resolvidos visando a execução correta do site. Analise as seguintes informações para determinar o que você precisa fazer:
Após a execução correta do seu site, você precisa torná-lo compatível com MLS. Se você fosse criar um site Empresarial em um servidor de Computação Externa, isso exigiria uma política de idioma padrão e localização. Como seu site foi copiado, ele não é MLS; por isso, você precisa fazer o upgrade dele para um site MLS para garantir que tenha suporte a futuras funcionalidades.
A tabela a seguir mostra as diferenças entre sites MLS e não MLS.
| Objeto do Site | Site MLS | Site Não MLS |
|---|---|---|
| Itens de Conteúdo | A variante de idioma do item de conteúdo será exibida, não o item de conteúdo solto na página. O idioma pode ser alterado dependendo do idioma solicitado quando o site é renderizado. | O item de conteúdo que foi solto na página será sempre exibido. |
| Layouts de Conteúdo | Os Layouts de Conteúdo devem suportar APIs v1.1. Caso contrário, o item de conteúdo não aparecerá, um aviso será exibido. Isso se deve ao fato de que todas as chamadas de API v1.1 terão uma "configuração regional" adicionada que não é suportada na API v1.0. | Os layouts de conteúdo podem ser v1.0 ou v1.1. Se o layout de conteúdo suportar apenas v1.0, o ContentSDK adicionará uma entrada "dados" na resposta para corresponder à entrada "campos". Pode haver ainda outros problemas, de modo que isso não deve ser considerado uma "funcionalidade suportada" para não fazer upgrade do layout de conteúdo. |
| Listas de Conteúdo | Somente itens de conteúdo disponíveis na variante do idioma solicitado serão exibidos. | Todos os itens de conteúdo independentemente do idioma serão exibidos. O usuário tem a opção na lista de conteúdo de fixar os resultados a um idioma específico; assim, você poderá ter duas listas de conteúdo na página mostrando resultados em idiomas diferentes. Essa opção do painel de definições para escolher um idioma não está disponível para sites MLS. |
| defaultLocale | Os sites MLS têm uma configuração regional padrão do site. Isso significa que todas as consultas de conteúdo só retornarão itens de conteúdo que estão nessa configuração regional (ou não traduzíveis). | Não há configuração regional padrão em um site não MLS; portanto, a consulta de conteúdo usada retorna todos os itens de conteúdo, independentemente do idioma. |
| Política de Localização |
Define a lista de idiomas disponíveis ao site. Haverá uma lista drop-down deles no construtor. Além disso, na interface do usuário de gerenciamento, haverá uma lista drop-down de idiomas para permitir que você abra/visualize no idioma solicitado. |
Como não há política de localização, a lista drop-down para alternar idiomas é removida do construtor. Na interface do usuário de gerenciamento, não há idioma listado, inclusive nenhum idioma "padrão". É assim que você reconhece sites MLS e não MLS na interface do usuário de gerenciamento. |
| Tradução/Traduzível | O menu de contexto na interface do usuário de gerenciamento tem "Traduzir" como opção. Isso permite que você crie um job de tradução para traduzir o site. |
O menu de contexto na interface do usuário de gerenciamento terá uma opção "Traduzível". Efetivamente, um site não MLS não é traduzível; por isso, você precisa torná-lo um site traduzível (MLS) primeiro para poder traduzi-lo. É dessa forma também que você "faz upgrade" de um site de não MLS para MLS. Observação: isso tem uma direção apenas. Você não pode fazer downgrade para não traduzível. |
Para poder tornar seu site em MLS, faça o seguinte:
Então, se você tiver qualquer código de componente personalizado que faça chamadas REST de Conteúdo, faça também o upgrade para fazer chamadas v1.1. Isso é incomum, já que a maioria das chamadas de conteúdo é feita de layouts de conteúdo.
Fazendo Upgrade de Layouts de Conteúdo
Especificando Versões Suportadas da API REST de Conteúdo
Os layouts de conteúdo precisam especificar qual versão da API REST de Conteúdo eles suportam. Isso assegura que a chamada REST de Conteúdo apropriada seja feita para retornar ao layout os dados de resposta esperados.
Se você não especificar qualquer suporte de versão, será assumido que o layout de conteúdo suporta apenas a versão v1.0.
A console listará os layouts de conteúdo que ainda estão na versão v1.0.
Para permitir que seu layout de conteúdo suporte outras versões, adicione a propriedade "contentVersion" ao seu objeto de layout de conteúdo.
Neste exemplo, diz que há suporte para todas as versões entre v1.0 e antes de 2.0 (Observação: 2.0 não existe, mas grandes alterações de versão podem introduzir alterações quebradas)
// 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)
{
Tratando Alterações de Resposta v1.1
O mínimo que você precisará fazer é lidar com a alteração de resposta da API REST de Conteúdo, de "dados" para "campos". A maneira mais simples de fazer isso é adicionar novamente a propriedade "dados" e apontar para a nova propriedade "campos"
render: function (parentObj)
{ ... if(!content.data) { content.data =
content.fields; }
Uma opção melhor seria alterar para o uso do valor "campos" da v1.1 em todos os seus layouts de conteúdo. Isso envolverá atualização do código de JavaScript e modelo.
Para suportar totalmente a versão v1.1, trate as seguintes alterações da API REST de Conteúdo entre as versões v1.0 e v1.1:
| Alteração da API REST de Conteúdo | v1.1 | v1.0 |
|---|---|---|
| "campos" versus "dados" |
"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" } }, |
| nomes de propriedades camelCase | "updatedDate" | "updateddate" |
| formato de consulta | /items?q=(type eq "Starter-Blog-Author") | /items?fields.type.equals="Starter-Blog-Author" |
| Versão da API | /content/management/api/v1.1/items | /content/management/api/v1/items |
| consultas específicas do idioma | /content/management/api/v1.1/items?q=((type eq "Promo") e (language eq "en-US" or translatable eq "false")) |
Não suportado. Migre todas as chamadas v1 personalizadas para incluir a opção "idioma". Isso assegura a consistência dos resultados com aqueles retornados do site MLS quando exibidos em um idioma específico. |
Fazendo Upgrade da String de Consulta de Conteúdo
Você pode estar fazendo chamadas de API de Conteúdo em qualquer código personalizado; por isso, valide todo código personalizado utilizado pelo site que está fazendo as chamadas de API REST de Conteúdo.
Convertendo Site Não MLS em MLS
Depois que você tiver convertido seu site para suportar totalmente APIs REST de Conteúdo v1.1, será possível adicionar suporte para idiomas alterando para um site MLS.
Se você selecionar seu site na interface do usuário de gerenciamento de site, verá uma opção de menu de conteúdo "traduzível". A seleção dessa opção exibirá uma caixa de diálogo solicitando que você escolha uma política de localização e um idioma padrão para o site na lista de idiomas obrigatórios da política de localização. Se nenhuma política de localização existir, você não poderá concluir esta etapa e terá de primeiro ir até as telas de administração de conteúdo e criar uma política de localização com pelo menos um idioma obrigatório.
Após a conclusão desta etapa, seu site agora será renderizado na configuração regional padrão. Ele também permitirá que você alterne para outras configurações regionais especificadas na sua política de localização.
Você precisará confirmar se seu site é renderizado conforme esperado em sua configuração regional padrão.
Os ativos associados a sites serão migrados quando você migrar seus sites, mas qualquer ativo não associado a sites precisa ser migrado separadamente.
Antes de iniciar a migração, leve em conta os seguintes pontos:
Para migrar seus ativos, execute as seguintes etapas:
Registre os detalhes de conexão dos servidores de origem e destino.
Registre o servidor de origem (o servidor do qual você está migrando os ativos):
> cec register-server <source_server_name>
-e http://<source_server>:<source_port>
-u <source_username> -p <source_password>
-t pod_ic
Registre o servidor de destino (o servidor para o qual você está migrando os ativos):
> cec-install % cec register-server <target_server_name>
-e http://<source_server>:<source_port>
-u <target_username> -p <target_password>
-t pod_ec
Migre uma coleção de ativos executando o seguinte comando:
> 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 necessário, a coleção e o canal serão criados automaticamente. O idioma padrão para todos os ativos migrados será o idioma padrão definido no repositório especificado.