Dúvida

Como funciona o processo de backup/restore da base de dados entre os ambientes de Produção/Homologação no ambiente Cloud (tombamento de base)?

Observação

O processo de backup/restore entre ambientes pode ser conhecido por nomes diversos (Tombamento da Base, Dump da Base, Restauração, Cópia da base, entre outros).

Solução

Atenção

• Apesar deste artigo ser focado no processo de Clientes com ambiente Cloud Senior, muitas informações podem ser levadas em consideração para Clientes que possuem ambiente OnPremise. Neste caso, pode-se levar em consideração que as responsabilidades definidas neste artigo como Sendo de IT Services serão responsabilidades da TI interna da Empresa;
• Este artigo leva em conta as atribuições do Suporte Padrão dos Produtos. Caso sua empresa tenha contratado alguma modalidade de Suporte Premium (Exemplo: Suporte Premium Dedicado, Suporte Premium Sustentação de Customizações), você poderá verificar junto com a respectiva equipe de Suporte Premium se o seu contrato inclui algum tipo de atividade adicional no que tange ao tombamento de base de dados entre Ambientes.

1. Informações gerais sobre o processo

O processo de backup/restore (muitas vezes conhecido como tombamento de base ou dump de base), tem como característica a cópia da base de dados de um ambiente para outro. Temos comumente os seguintes cenários para esse processo:

• Cliente já em Produção, onde há necessidade de realizar testes no ambiente de Homologação para validação de versão com dados mais próximos dos dados existentes em produção. Neste cenário, executa-se o backup da base de Produção e Restauração em ambiente de Homologação;
• Cliente está em Implantação, onde foram efetuadas as configurações em ambiente de Homologação e há necessidade de levar a base de Homologação para o ambiente de Produção. Neste cenário, executa-se o backup da base de Homologação e Restauração em ambiente de Produção (esse cenário é comum ocorrer ainda em fase de Projeto de Implantação).

1.1. Sobre Pré-Requisitos para o Processo

São pré-requisitos definidos para que esse processo seja executado:

• As versões dos sistemas devem ser idênticas nos dois ambientes (Produção e Homologação). Isso é necessário para evitar incompatibilidade entre arquivos existentes nos ambientes e as bases de dados restauradas.

1.2. Sobre melhores práticas do Processo

São melhores práticas recomendadas para esse processo:

• Efetuar o processo de restauração de todos os sistemas integrados na mesma janela, para evitar desencontro de dados integrados.
  • Exemplo de um cenário que poderia apresentar problemas se essa restauração não ocorrer de forma sincronizada: utiliza-se a integração do ERP com sistema WMS. A restauração realizada é apenas da base de dados do WMS da Produção para Homologação. Neste cenário, quando o ERP de Homologação enviar uma Pedido para separação ao WMS, essa numeração de pedido do ERP de Homologação pode já existir no WMS de Homologação (porque o WMS de homologação está com uma numeração de pedidos superior, já que é uma cópia da Produção).
• Revisão completa das parametrizações depois que as bases de dados foram restauradas para evitar que os sistemas tenham apontamentos cruzados entre os ambientes, o que pode afetar a operação do ambiente de Produção;
• Desativação da execução dos Processos Agendados pelo SeniorConfigCenter no tombamento da base de Produção para Homologação para que nenhum processo seja executado antes que haja confirmação de que todas as revisões de parametrizações foram realizadas.

Observação

Consulte o tópico específico deste artigo sobre as Responsabilidades das atividades envolvidas neste processo.

2. Sobre as possibilidades/impossibilidades de execução do processo

2.1. Produtos onde o processo de backup/restore pode ser realizado

• Gestão Empresarial | ERP;
• Gestão Empresarial PME | GOUP;
• Gestão de Pessoas | HCM;
• Gestão de Armazenagem | WMS WIS;
• Gestão de Armazenagem | WMS SILT.

2.2. Produtos onde o processo de backup/restore não pode ser realizado:

• eDocs: no eDocs, apesar de em ambiente OnPremise Clientes efetuarem esse tipo de processo, no ambiente Cloud, devido a utilização de uma estrutura de eDocs Gerenciador de Tenants, não existe esta viabilidade técnica.

Importante

Caso o Produto que você utilize não esteja listado acima como possibilidade ou impossibilidade e você deseja verificar a disponibilidade do processo, entre em contato com equipe de IT Services para maiores orientações.

2.3. Impossibilidades/restrições conhecidas

Em alguns casos, apesar da restauração de base de dados entre ambientes ser possível de ser realizada, podem haver restrições ou impossibilidades técnicas que afetam rotinas específicas do sistema.

São impossibilidades/restrições conhecidas:

• Rotinas integradas com Senior X: a Senior X possui uma base de dados própria que não pode ser restaurada/tombada (então não existe o conceito de copiar a base de um Tenant de Produção para Tenant de Homologação). Isso pode impactar diretamente a integração de rotinas que utilizem Senior X. Exemplos:
  • Gestão Empresarial | ERP integrando Requisições Eletrônicas com Senior X: caso seja efetuado o tombamento da base de dados de Produção para Homologação, a integração com Senior será comprometida. É necessário efetuar o reset da base de dados pelas telas da Senior X e executar uma nova Carga Inicial (todos os dados da Senior X para esse Modulo/Processo serão excluídos);
  • Gestão Empresarial | ERP integrado com WMS SILT ou ALCIS: para esse processo, utiliza-se um fluxo de integração que passa pelo ISL que está na Plataforma Senior X. Não há possibilidade de limpeza da base de dados do ISL manualmente (a limpeza ocorre apenas pelo Agendamento padrão da integração) e nem tombamento entre ambientes/Tenants. Neste caso, os eventuais ajustes precisam ser executados manualmente para as questões que ocorreram com os registros de integração.

Importante

Leve em consideração que, não é porque uma restrição não esteja mapeada neste artigo, então não há impeditivo técnico para realização. A utilização de rotinas integradas entre os sistemas Senior (e inclusive sistemas de Terceiros) é bem abrangente e, em muitos casos, não é possível mapear impossibilidades/restrições para todos os cenários. Avalie antecipadamente os cenários técnicos específicos da sua empresa para avaliar eventuais impossibilidades/restrições relacionadas a este processo de restauração.

3. Sobre as responsabilidades da execução dos processos

3.1. Responsabilidades da equipe de IT Services

São responsabilidades da equipe de IT Services:

• Validar as versões das bases de dados antes de executar o processo, indicando eventual necessidade de efetuar a atualização de versão antes de executar a restauração;
• Executar a restauração das bases conforme solicitação (garantindo integridade dos dados e arquivos restaurados como, por exemplo, Regras LSP, TBS, Modelos de Relatórios, leiautes de Importação e Exportação);
• Garantir a execução dos Serviços do ambiente restaurado (caso os serviços já estivessem instalados/configurados no ambiente antes da restauração). Exemplo de serviços: SeniorMiddleware, AppManager, ERP_Service).

3.2. Responsabilidades do Cliente/Solicitante

São responsabilidades do Cliente/Solicitantes da restauração:

• Validar a viabilidade técnica para execução do processo de restauração solicitado;
• Revisar parametrizações que possam impactar os ambientes após a restauração (Exemplo: apontamentos fixos para APIs externas em Regras LSP, revisão de configurações que variam conforme ambiente [Conexão com eDocs na tela F191CPT, Diretórios de geração de arquivos XML na tela F020SNF, entre outros]);
• Solicitar antecipadamente a revisão de parametrizações do SeniorConfigCenter que IT Services precise executar logo após a restauração;
• Solicitação para ativar execução de Processos Agendados no ambiente restaurado (caso tenha sido efetuada a ativação da execução dos processos durante a restauração).

4. Sobre os impactos de não serem efetuadas revisões de parametrizações

O processo de backup/restore de base pode ter efeitos colaterais que impactem diretamente o ambiente de Produção, causando, inclusive, indisponibilidade temporária de processos cruciais para empresa.

Exemplo de impacto (apenas para exemplificar um contexto que impactará diretamente o ambiente de Produção)

• Base de dados de do Gestão Empresarial | ERP foi restaurada do ambiente de Produção para Homologação e existe integração com Gestão de Armazenagem | WMS WIS ativada, mas não foram revisados os apontamentos no ERP para conexão com a base de dados do WMS de Homologação. Neste cenário, o ERP de Homologação ativará integração com o WMS de Produção e impactará na integração direta do ambiente de Produção, podendo causar a parada temporária do faturamento da empresa.

Por isso é de extrema importância que haja a revisão completa de parametrizações e apontamentos na base de dados que tenha sido restaurada antes da inserção de dados ou execução de processos nesta base,

5. Sobre a documentação do processo e possibilidades de automatismos no processo

5.1. Sobre a documentação do processo

Cada Cliente pode utilizar as rotinas dos sistemas Senior de formas diferentes, além de possuir customizações específicas sendo utilizadas.

Desta forma, é indicado que cada Cliente construa e mantenha um Documento interno padrão com os passos a serem utilizados para esse processo de backup/restore de base de dados. Esse tipo de documento, além de trazer padronização de todo o processo, garantirá que etapas essenciais para o sucesso do processo sejam respeitadas, evitando assim impactos que podem comprometer o ambiente de Produção.

5.2. Sobre possibilidades de automatismos no processo

Para Clientes que executam o processo de backup/restore com maior frequência, é possível verificar a possibilidade de criação de automatismos ou processos que possam distinguir entre ambientes de Produção/Homologação.

Observação

A criação desse tipo de automatismo pode necessitar de um Serviço de Consultoria, caso haja necessidade de apoio da Senior. Para maiores informações sobre serviços adicionais disponíveis, verifique o tópico específico deste artigo.

Exemplos de automatismos para o Processo:

• Para parametrizações que estão armazenadas a nível de tabelas/campos do banco de dados:
  • Para esse tipo de cenário é possível a criação de scripts SQL (Updates) que podem ser executados na base de dados após a restauração para mudança das informações/parametrizações em lote de maneira rápida e segura. Abaixo alguns exemplos:
    • Produto Gestão Empresarial | ERP:
      • Diretórios de Integração: possibilidade de alteração de diretório de integração em tabelas/campos que armazenam essas informações (Exemplo: tabela E020SNF que armazena o diretório de geração de arquivos XMLs de NF-e
      • URLs de comunicação com outros sistemas: possibilidade de alteração de URLs e credenciais de autenticação (exemplo: tabelas E191CPT/E191CPV que armazenam a comunicação do ERP com o WebService do eDocs);
• Para parametrizações a nível de Regras LSP
  • Para esse cenário é possível fazer tratativas tanto de validação para impedir execução de processos  que podem estar com apontamentos incorretos (ou até mesmo o login na base de dados) e também criação de condicionais que se adaptem a base de dados restaurada. Alguns exemplos abaixo:
    • Produto Gestão Empresarial | ERP:
      • Identificador de Regras GER-000SELEF2: impedir o login no sistema caso não exista alguma condição específica na base de dados do sistema que garanta que a base tenha sido toda revisada para acesso. Exemplo: pode-se ter um fluxo de restauração de base que, ao final da restauração, defina o valor de um campo em uma tabela específica como "Base_OK". Dentro da regra do identificador pode-se verificar que se a base de dados for de Homologação, esse campo da tabela tenha que ter esse valor. Se não tiver o valor, o usuário não pode logar no sistema;
      • Condicionais de regras que validem informações do SeniorConfigCenter: através da função de programador RetornaValorCFG é possível buscar o valor de informações armazenadas como chaves do arquivo CFG (que é Administrador pelo SeniorConfigCenter). Então, é possível criar algumas lógicas como, por exemplo:
        • Buscar o nome do usuário da base de dados configurado no SeniorConfigCenter pela função RetornaValorCFG. Se o nome do usuário da base de dados for "ERP_Empresa_Homolog", a regra LSP considera determinadas informações (Exemplo: apontamento de API externa de Homologação);
        • Identificar o ambiente de configuração de integração com a Plataforma Senior X pela função RetornaValorCFG. Se o ambiente for de Homologação, a regra LSP considera determinadas informações (Exemplo: apontamento de API externa de Homologação).

6. Sobre serviços adicionais disponíveis

A Senior disponibiliza serviços adicionais de Consultoria que podem ser contratados tanto para apoio na construção de um Documento/Fluxo padrão para esse tipo de processo como também para a criação de automatismos que possam melhorar sua experiência com esse tipo de processo.

Para verificar um orçamento para esse tipo de tratativa, entre em contato com o seu Executivo Comercial.