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

Sobre minha saída da Timbira

Há 14 anos, durante o PGConf.Brasil 2009, lá na UNICAMP em Campinas/SP, 4 pessoas se reuniram e idealizaram a criação da primeira empresa dedicada exclusivamente

Split brain

Já tem algum tempo que eu pensava em fazer isso e chegou a hora. Este blog vai se dividir em 2 partes a partir de

plugins premium WordPress