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
- 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]
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
| Nome | Tabela | Condições |
|---|---|---|
| Certificado | Certificados X.509 [sys_certificate] | Nenhum(a) |
| Propriedades da instância principal | Propriedades do sistema [sys_properties] |
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 de SAML2 Update1 [saml2_update1_properties] | Nenhum(a) |
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 ao seu 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 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 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 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 será editável 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
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 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.
- 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.
- 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.
- Os 20 registros na tabela sys_temp de destino foram preservados com sucesso (de acordo com a especificação do preservador de dados). Esses registros fazem 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.
Procedimento
Preservar propriedades SAML
Se você quiser que uma instância de destino do clone mantenha sua integração SAML existente, edite o preservador de dados Propriedades da instância principal para incluir as propriedades SAML.
Antes de Iniciar
Procedimento
Preservar aplicações e personalizações no 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
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
Procedimento
Resultado
Preservar a aplicação Eventos de Marketing
Digamos que sua empresa tenha criado anteriormente a versão 1.0 de um aplicativo personalizado chamado Marketing Events. Você já publicou a versão 1.0 da aplicação Marketing Events no repositório de aplicações e a instalou em sua instância de produção.
Com o passar do 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 Marketing Events, você já vinculou a aplicação Marketing Events a um repositório de controle de código-fonte. Você confirma a versão 2.0 da aplicação Marketing Events 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 Marketing Events, porque essa foi 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 Marketing Events e está disponível para desenvolvimento e testes adicionais.