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 serem substituídos. 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 para clonagem. Por exemplo, se o destino for um MID Server, você não deve 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 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 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 SSO múltiplo

O sistema cria automaticamente os preservadores de dados necessários para clonagem quando você ativa a integração de login único 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] [OU] [Nome] [IS] [glide.authenticate.sso.redirect.idp] Nota: As propriedades glide.smtp.port, glide.smtp.authe. glide.smtp.encryptionestão obsoletos.
Propriedades do resumo	Propriedades de resumo [digest_properties]	Nenhum(a)
Provedores de Identidade	Provedores de identidade [sso_properties]	Nenhum(a)
Propriedades de Atualização 1 do SAML2	Propriedades de atualização 1 do SAML2 [saml2_update1_properties]	Nenhum(a)

Nota:

Embora você possa modificar esses preservadores de dados, é uma boa prática não fazê-lo. As tabelas Propriedades de resumo [digest_properties], Provedores de identidade [sso_properties] e Propriedades de atualização de SAML2 [saml2_update1_properties] são necessárias para que várias origens, single sign-on (SSO) funcionem corretamente. Se o login ú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-as 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

A preservação das configurações relacionadas ao SSO do SAML pode impedir que a instância de destino use os parâmetros de emissor e público incorretos 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 SAML.
• Certificados X.509 [sys_certificate]: Para preservar certificados SAML.
• Usuário [sys_user]: Para preservar usuários SAML.

Você também precisa preservar propriedades E usuários envolvidos no SAML.

Preservação de candidaturas 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 preserve aplicações não publicadas .

O processo de clonagem não preserva as diferenças de versão das 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 na instância de destino. Se a instância de destino tiver uma versão de desenvolvimento da mesma aplicação, a aplicação será editável após o clone, mas será 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.

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

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 substituir a 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 destinam-se principalmente a preservar as configurações e 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 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 nas tabelas a seguir devem ser preservados.

• 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 tenha 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 Novo.
3. Insira o rótulo da tabela como 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 pode ser enviado.
4. Selecione Tabela a ser preservado.
   O preservador de dados deve ter uma tabela selecionada ou não pode ser enviado.
5. Selecione Tema Se os dados que estão sendo preservados forem uma propriedade de IU.
6. Defina os dados a serem preservados usando Construtor de condições .
   Você pode usar condições para definir registros específicos que você deseja preservar durante um clone. Por exemplo, para preservar apenas 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 [corresponder regex] não é mais compatível.

   

   Aviso:

   Se o clone do backup falhar por algum motivo, o processo de clone fará 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 com pontos. Nesses casos, convém reagendar um clone do sistema ou transferir dados manualmente.
7. Clique em Enviar.
   Se você quiser excluir o preservador de dados mais tarde, certifique-se de não modificar ou excluir os seguintes registros de preservador de dados:

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

   Nota:

   Não é possível preservar as exibições de bancos de dados.

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

Preserve as propriedades do SAML

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

Antes de Iniciar

Função necessária: administrador

Procedimento

1. Navegar até Tudo > Clone do sistema > Preservar dados.
2. Selecione Propriedades da instância principal .
3. Adicione o seguinte 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 Tema a caixa de seleção está desmarcada para que essas propriedades sejam preservadas, independentemente de você preservar o tema da instância.
4. Clique em Atualizar.

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

Preserve 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

Certifique-se de ter acesso de gravação ao registro da aplicação.

Certifique-se de ter acesso a um repositório de controle de origem.

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 será editável após o clone, mas estará na versão que foi 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 origem. 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 na 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 sobre sua instância de desenvolvimento.
3. Após a conclusão do processo de clonagem, faça login na instância de destino do clone.
4. Nota:

   Se o controle de origem estiver vinculado, depois do pós-clone, a plataforma recuperará automaticamente as aplicações e aplicações personalizadas. Se estiver desabilitado via glide.source_control.post_clone_import_enabled você precisará recuperar manualmente fazendo o seguinte.
   Se você salvou cada aplicação em um repositório de controle de origem, use uma destas ações para recuperá-las do repositório de controle de origem:
   Nota:

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

   Tabela 2. Recupere aplicações de um repositório de controle de origem

   Estado de instalação da aplicação	Ação a ser realizada 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 origem.
   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 origem.

   Tabela 3. Mudanças remotas após clone

   Campo	Descrição
   glide.source_control.post_clone_import_enabled	Para desabilitar a automação 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. Recupere aplicações de um conjunto de atualizações

   Estado de instalação da aplicação	Ação a ser realizada 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.

Preserve a aplicação Eventos de marketing

Digamos que sua empresa tenha criado anteriormente a versão 1,0 de uma aplicação personalizada chamada Eventos de marketing. 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 que não é de produção para atender a essas solicitações. À medida que o desenvolvimento se aproxima da conclusão, você deseja atualizar sua instância de não produção para a cópia mais recente da produção para alguns testes abrangentes.

Como você usou anteriormente uma integração de controle de origem 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 origem. Você confirma a versão 2,0 da aplicação Eventos de marketing no repositório de controle de origem.

Você agenda um clone da instância de produção pela 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, aplique as mudanças remotas do repositório de controle de origem 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.