Preservação de dados na clonagem de instâncias de destino

Você pode usar preservadores de dados para proteger os dados na instância de destino contra a substituição. Se você tiver aplicações personalizadas, também deverá preservar manualmente o conteúdo da aplicação não publicado.

Preservadores de dados

Às vezes, é necessário preservar alguns dados em uma instância destinada à clonagem. Por exemplo, se o destino for um MID Server, você não deverá substituir a tabela do MID Server [ecc_agent]. Os dados preservados são armazenados na instância de destino antes do início da clonagem e são restaurados na instância de destino após a clonagem.

Aviso:

Você deve definir preservadores de dados na instância de origem. Defini-los na instância de destino não preserva os dados.

Os preservadores de dados normalmente preservam as configurações e os temas do sistema, como:

• Configurações de autenticação específicas da instância
• Marcador [sys_ui_bookmark]
• Seleção recente [sys_ui_recent_selection]
• Preferência do usuário [sys_user_preference]

Nota:

Um clone não é compatível com a preservação de dados de uma exibição de banco de dados.

Não use preservadores de dados para transferir grandes conjuntos de dados, como grupos de usuários. Se você precisar preservar os dados da tabela, como usuários, grupos e funções, considere exportar os registros para um arquivo e importá-los após a clonagem.

Preservadores de dados para Multi-SSO

O sistema cria automaticamente os preservadores de dados necessários para clonagem quando você ativa a integração de Single Sign-On de vários provedores.

Nome	Tabela	Condições
Certificado	Certificados X.509 [sys_certificate]	Nenhum(a)
Propriedades da instância principal	Propriedades do sistema [sys_properties]	[OU] [Nome] [é um de] [glide.authenticate.external, glide.authenticate.external.logout_redirect] [OU] [Nome] [começa com] [com.snc.integration.saml_esig] [OU] [Nome] [é um de] [glide.smtp.port, glide.smtp.auth, glide.smtp.encryption] [OU] [Nome] [começa com] [glide.authenticate.multisso] [OR] [Name] [is] [glide.authenticate.sso.redirect.idp] Nota: As propriedades glide.smtp.port, glide.smtp.authe glide.smtp.encryption estão obsoletas.
Propriedades do resumo	Propriedades de resumo [digest_properties]	Nenhum(a)
Provedores de Identidade	Provedores de identidade [sso_properties]	Nenhum(a)
Propriedades de SAML2 Update1	Propriedades do Update1 do SAML2 [saml2_update1_properties]	Nenhum(a)

Nota:

Embora você possa modificar esses preservadores de dados, é uma prática recomendada não fazê-lo. As tabelas Propriedades de resumo [digest_properties], Provedores de identidade [sso_properties] e Propriedades de atualização1 do SAML2 [saml2_update1_properties] são necessárias para que o Single Sign-on (SSO) de várias origens funcione corretamente. Se o logon único de várias origens estiver desabilitado na instância de destino, você poderá remover com segurança todos os três preservadores de dados. Remova-os ao mesmo tempo, pois o sistema encerra o clone com uma mensagem de erro quando você tenta clonar com uma ou duas dessas tabelas sendo preservadas.

Preservadores de dados para SAML

Preservar as configurações relacionadas ao SSO do SAML pode impedir que a instância de destino use os parâmetros incorretos de emissor e público ao fazer solicitações de autenticação para o IdP. Para preservar as configurações de SAML, crie preservadores de dados para as seguintes tabelas:

• Propriedade do sistema [sys_properties]: para preservar as propriedades do SAML.
• Certificados X.509 [sys_certificate]: para preservar os certificados SAML.
• Usuário [sys_user]: para preservar os usuários do SAML.

Você também precisa preservar as propriedades e os usuários envolvidos no SAML.

Preservação de aplicações não publicadas

Você não pode usar preservadores de dados para salvar aplicações não publicadas. Em vez disso, os desenvolvedores de aplicações devem escolher como desejam preservar aplicações não publicadas.

O processo de clonagem não preserva as diferenças de versão para aplicações em desenvolvimento. Em vez disso, o clone do sistema copia somente a versão da aplicação instalada na instância de origem para a instância de destino. Se a instância de destino tiver uma versão de desenvolvimento da mesma aplicação, a aplicação poderá ser editada após o clone, mas estará em qualquer versão instalada na instância de origem. Se a aplicação estiver ausente na instância de origem, o processo de clonagem excluirá a aplicação da instância de destino.

Criar um preservador de dados

Os preservadores de dados mantêm os dados especificados em uma instância de destino.

Antes de Iniciar

Função necessária: clone_admin ou administrador

Por Que e Quando Desempenhar Esta Tarefa

Às vezes, é desejável preservar determinados dados em uma instância de destino. Por exemplo, ao usar um MID Server, você pode evitar a substituição da tabela do MID Server [ecc_agent]. Os dados preservados são armazenados em uma lista gerada dinamicamente na instância de destino antes do clone e restaurados na instância de destino após a conclusão do clone. Você define preservadores de dados na instância de origem.

Os preservadores de dados têm como objetivo principal preservar as configurações e os temas do sistema, como configurações de autenticação específicas da instância. Não use preservadores de dados para transferir grandes conjuntos de dados, como grupos de usuários. Se você precisar preservar os dados da tabela, como usuários, grupos e funções, considere exportar os registros para um arquivo e importá-lo após a conclusão do clone.

Considere se os dados devem ser preservados nas tabelas a seguir.

• Marcador [sys_ui_bookmark]
• Seleção recente [sys_ui_recent_selection]
• Preferência do usuário [sys_user_preference]

Se você definir um preservador de dados em uma tabela em que a instância de origem tem mais registros do que a instância de destino, os dados preservados na instância de destino também incluirão os registros adicionais da instância de origem.

Por exemplo, suponha que o preservador de dados já esteja em vigor.

• Na instância de origem, a tabela sys_temp contém 100 registros.
• Na instância de destino, a tabela sys_temp contém 20 registros.

Após o clone, a tabela sys_temp na instância de destino contém 100 registros.

• Os 20 registros na tabela sys_temp de destino são preservados com sucesso (de acordo com a especificação do preservador de dados). Esses registros faziam parte dos 100 registros na tabela sys_temp de origem.
• A tabela sys_temp de origem traz os 80 registros restantes para a tabela sys_temp de destino.

Para resolver esse problema e preservar somente os registros na tabela de destino, crie um registro de tabela de exclusão para a tabela de destino, além de definir o preservador de dados na tabela de origem.

Importante:

Configure preservadores na instância de origem.

Procedimento

1. Na instância de origem, navegue até Clone do sistema > Preservar dados.
2. Clique em Nova.
3. Insira o rótulo da tabela como o Nome, por exemplo, Preferência do usuário para a tabela [sys_user_preference].
   O preservador de dados deve ter um nome de tabela ou não poderá ser enviado.
4. Selecione a Tabela a ser preservada.
   O preservador de dados deve ter uma tabela selecionada ou não poderá ser enviado.
5. Marque a caixa de seleção Tema se os dados que estão sendo preservados forem uma propriedade de IU.
6. Defina os dados a serem preservados usando o Construtor de condições.
   Você pode usar condições para definir registros específicos que deseja preservar durante um clone. Por exemplo, para preservar somente propriedades específicas do sistema, você pode adicionar condições para cada nome de propriedade que deseja preservar.

   Nota:

   A condição para corresponder a expressões regulares [match regex] não é mais compatível.

   

   Aviso:

   Se o clone do backup falhar por algum motivo, o processo de clone fará o failover para o mecanismo de clone legado. O mecanismo de clone legado não pode preservar dados de tabelas estendidas, relacionamentos, hierarquias entre tabelas e consultas de referência com pontos. Você pode reprogramar um clone do sistema ou transferir dados manualmente nesses casos.
7. Clique em Enviar.
   Se você quiser excluir o preservador de dados posteriormente, certifique-se de não modificar ou excluir os seguintes registros do preservador de dados:

   • Propriedades da instância principal
   • Semáforos
   • Contas de e-mail

   Nota:

   As exibições do banco de dados não podem ser preservadas.

   Os preservadores não podem estar vazios e os usuários não poderão enviar o clone se os preservadores estiverem vazios.

Preservar propriedades de SAML

Se você quiser que uma instância de destino de clone mantenha a integração SAML existente, edite o preservador de dados Propriedades da instância principal para incluir as propriedades SAML.

Antes de Iniciar

Função necessária: administrador

Procedimento

1. Navegar até Todos > Clone do sistema > Preservar dados.
2. Selecione Propriedades da instância de núcleo.
3. Adicione as seguintes Condições.
   • [OU] [Nome] [é um de] [glide.authenticate.external, glide.authenticate.external.logout_redirect, glide.authenticate.failed_requirement_redirect]
   • [OU] [Nome] [começa com] [glide.authenticate.sso.saml2]
   • [OU] [Nome] [começa com] [com.snc.integration.saml_esig]

   

   Nota:

   Certifique-se de que a caixa de seleção Tema esteja desmarcada para que essas propriedades sejam preservadas, independentemente de você preservar o tema da instância.
4. Clique em Atualizar.

Preservar aplicações e personalizações em desenvolvimento durante um clone do sistema

Preservar manualmente uma cópia de cada aplicação e personalização que você tem atualmente em desenvolvimento antes de clonar a versão da aplicação para a instância de destino (desenvolvimento).

Antes de Iniciar

Verifique se você tem acesso de gravação ao registro da aplicação.

Verifique se você tem acesso a um repositório de controle de código-fonte.

Função necessária: administrador

Por Que e Quando Desempenhar Esta Tarefa

O processo de clonagem não preserva as diferenças de versão para aplicações e personalizações de aplicações em desenvolvimento. Em vez disso, o sistema clona somente as cópias da aplicação e as versões de personalização da aplicação que estão instaladas na instância de origem na instância de destino. Se a instância de destino tiver uma versão de desenvolvimento da mesma aplicação, a aplicação poderá ser editada após o clone, mas estará na versão instalada na instância de origem. Se a aplicação estiver ausente na instância de origem, o processo de clonagem excluirá a aplicação da instância de destino.

Procedimento

1. Para preservar a aplicação na instância de destino do clone, execute uma destas ações:

   Tabela 1. Diferenças de versão entre instâncias

   Estado da versão da aplicação	Ação a ser realizada
   A versão da aplicação na instância de destino do clone é diferente da versão da instância de origem.	Exporte cada aplicação da instância de destino do clone. As opções incluem: Vincule cada aplicação a um repositório de controle de código-fonte. Nota: Se a aplicação já estiver vinculada a um repositório de controle de código-fonte, confirme a versão mais recente nele. Publique cada aplicação em um conjunto de atualizações.
   A aplicação está disponível somente na instância de destino do clone.
   A versão da aplicação na instância de destino do clone é a mesma da instância de origem.	Nenhum. O processo de clone do sistema copia esta versão da aplicação para a instância de destino durante o clone.

2. Solicite um clone do sistema da instância de origem para a instância de destino.
   Por exemplo, clone sua instância de produção na instância de desenvolvimento.
3. Depois que o processo de clonagem terminar, faça login na instância de destino do clone.
4. Nota:

   Se o controle de código-fonte estiver vinculado, após a clonagem, a plataforma recuperará automaticamente as aplicações e as aplicações personalizadas. Se estiver desabilitado por meio de glide.source_control.post_clone_import_enabled, será necessário recuperar manualmente, fazendo o seguinte.
   Se você salvou cada aplicação em um repositório de controle de código-fonte, use uma destas ações para recuperá-las do repositório de controle de código-fonte:
   Nota:

   Para saber o que esperar após a pós-clonagem da personalização da aplicação, consulte Resultados pós-clonagem para personalizações da aplicação.

   Tabela 2. Recuperar aplicações de um repositório de controle de código-fonte

   Estado de instalação da aplicação	Ação a ser executada no destino do clone
   A aplicação e a personalização foram instaladas anteriormente na instância de origem.	Aplique mudanças remotas do repositório de controle de código-fonte.
   A aplicação nunca foi instalada na instância de origem.	Exclua a configuração do repositório (sys_repo_config) e importe a personalização do repositório de controle de código-fonte.

   Tabela 3. Mudanças remotas após clonagem

   Campo	Descrição
   glide.source_control.post_clone_import_enabled	Para desabilitar a automação de aplicar mudanças remotas, defina como Falso. O padrão é Verdadeiro.
   glide.source_control.post_clone_import_delay_time_sec	Para fornecer um tempo de atraso, que atrasará o processamento da fila, forneça um valor. O padrão é zero.
   glide.source_control.post_clone_import_pause_refresh_time_sec	Para fornecer um intervalo no qual o trabalho de atualização do repositório não será executado, forneça um valor. O padrão é três horas (10800).

5. Se você salvou cada aplicação em um conjunto de atualizações, execute uma destas ações para recuperá-las do conjunto de atualizações:

   Tabela 4. Recuperar aplicações de um conjunto de atualizações

   Estado de instalação da aplicação	Ação a ser executada no destino do clone
   A aplicação foi instalada anteriormente na instância de origem.	Exclua a versão da aplicação que foi clonada da instância de origem. Carregue o conjunto de atualizações que contém a versão atual da aplicação.
   A aplicação nunca foi instalada na instância de origem.	Carregue o conjunto de atualizações que contém a versão atual da aplicação.

Resultado

As aplicações anteriormente em desenvolvimento estão disponíveis para desenvolvimento adicional na instância de destino do clone.

Preservar a aplicação Eventos de Marketing

Digamos que sua empresa tenha criado anteriormente a versão 1.0 de uma aplicação personalizada chamada Marketing Events. Você já publicou a versão 1.0 da aplicação Eventos de Marketing no repositório de aplicações e a instalou em sua instância de produção.

Com o tempo, os usuários enviaram solicitações de aprimoramento para a aplicação e você decide desenvolver a versão 2.0 da aplicação Eventos de Marketing em uma instância de não produção para atender a essas solicitações. Conforme o desenvolvimento se aproxima da conclusão, você deseja atualizar sua instância de não produção para a cópia mais recente de produção para alguns testes abrangentes.

Como você usou anteriormente uma integração de controle de código-fonte para desenvolver a versão 1.0 da aplicação Eventos de Marketing, você já vinculou a aplicação Eventos de Marketing a um repositório de controle de código-fonte. Você confirma a versão 2.0 da aplicação Eventos de Marketing para o repositório de controle de código-fonte.

Você programa um clone da instância de produção na instância de desenvolvimento. Após a conclusão, você faz login na instância de desenvolvimento e vê que ela tem a versão 1.0 da aplicação Eventos de Marketing, porque essa era a versão instalada na instância de origem.

Como a aplicação já foi instalada na instância de origem, você aplica as mudanças remotas do repositório de controle de código-fonte para receber a versão mais recente da aplicação. A instância de desenvolvimento agora tem a versão 2.0 da aplicação Eventos de Marketing e está disponível para desenvolvimento e testes adicionais.