Ufa!!!

Depois de quase um mês remodelando uma interface entre dois sistemas que deixaram de se comunicar por causa da mudana de um parêmetro… homologamos a solução!!! Bem, pelo menos a primeira parte. Agora falta botar pra funcionar o que nunca funcionou…

Pra mim foi um grande aprendizado…

– Primeiro documentei o nome de todas tabelas, procedures, gatilhos, sinônimos, dependncias e tudo quanto objeto que estava relacionada a interface. Deram uns 50 objetos diferentes…
– Depois fui atrás de informações sobre como os dois sistemas funcionavam no tocante a parte que precisava ser mexida.
– No meio do caminho li um livro inteiro de PL/SQL do Oracle pois conhecia muito pouco do assunto e mesmo assim só tinha mexido com isso no PostgreSQL.
– Fiz um diagrama de blocos de como eu gostaria que ficassem as novas procedures e gatilhos.
– Criei um script para alterar e criar todas tabelas, sequências, permições e comentários necessários, Incluindo algumas instruções DML necessárias para criar as condições de teste corretas.
– Escrevi de novo as procedures e gatilhos praticamente do zero.
– Adicionei uma boa dose de comentários em todo o codigo escrito
– Testei os scripts e compilei os procedures e gatilhos
– Fiz um tutorial para a alterão dos procedimentos necessários para a empresa que manda os dados para interface
– Recebi uma carga de dados de teste da empresa e testei a parafernália toda
– Pedi para a equipe que de suporte do outro sistema para checar se os dados de teste entraram com sucesso na base de teste.
– Atualizei toda a documentação
– Carreguei todos os objetos no banco de dados de produção
– Liberei a empresa para comeaçar a fazer a carga na interface com dados reais.

Putz! Que trampo!!! Agora só falta avisar uma das empresas que eu fui obrigado a alterar 2 gatilhos deles que estavam dando erro quando mudei os procedimentos.

Isso ainda pode gerar um abacaxi…

Bem, mas o importante que eu aprendi muuuuita coisa no processo. Tô comeando a fazer as coisas como gente grande. Documentando tudo, testando em um ambiente separado, homologando a solução e redocumentando tudo de novo. Deu muito trabalho deste jeito, mas pela complexidade da coisa e o número de erros que tive que corrigir (os meus e alguns dos outros dois sistemas…) a coisa seria bem mais complicada se eu fisesse de outra forma. Como estou mexendo em um sistema de tributação, qualquer erro poderia ter gerado graves consequências em pouquíssimo tempo.

, desenvolver em ambiente corporativo é como na Educação:
o bagulho louco e o processo lento.

Compartilhe

Você pode gostar

pg_hba.conf

Introdução O arquivo pg_hba.conf (PostgreSQL Host-Based Authentication) é uma peça fundamental na configuração de segurança de qualquer instância PostgreSQL. Ele define as regras de autenticação

Tuning de SO (no Linux)

Introdução Tuning refere-se ao processo de ajustar e otimizar o desempenho de um sistema, software ou aplicação. A otimização do sistema operacional é uma etapa

Tipos de cargas dos bancos de dados

Introdução Cargas de dados referem-se aos diferentes tipos de operações e transações que um banco de dados deve processar. Essas cargas variam conforme o tipo

plugins premium WordPress