| | | Mais exemplos práticos para GeneXus X Evolution 1 |
|
| Um artigo de Gustavo Carriquiry, gerente de operações da Artech, que começa com uma anedota pessoal sobre inicializar dados com transações, procedures e Data Providers, e que conclui com exemplos práticos de uso para a GeneXus X Evolution 1, como o vídeo do Business Component e Data Providers. |
Há apenas umas semanas descobri que a Karina (Santos) tinha razão 20 anos atrás; só foi preciso que esses 20 anos se passaram, que eu abrisse minha mente e fosse corajoso. Como forma de reconhecimento e para ajudar outras pessoas a abrir suas mentes, escrevo este post.
Meu problema nesse momento
Há muitos anos que trabalho com o GeneXus, comecei em um cliente há quase 20 anos e lembro um telefonema ao suporte; nesse momento Karina era “suporte-documentação-teste-capacitação-consultoria-e-tudomais”.
Nessa época eu estava desenvolvendo um sistema para o controle de frotas (estoque de reposição, manipulação de combustível, da oficina, etc). Precisava fazer um processo de atualização de estoque “batch”, mas GX nesse momento só tinha Transações e Relatórios. Não existiam os procedures (muito menos workpanels nem nada do que existe hoje).
Entrei em contato com Suporte para saber como resolver o problema e foi Karina quem tentou me convencer de que o que eu estava fazendo estava “conceitualmente errado”. Que a atualização a base de dados devia ser via a transação, onde estavam as regras do negócio e o que assegurava a consistência dos dados, etc. Argumentação atendível.
Eu tinha 20 anos, era um calouro na Faculdade e a Karina era muito convincente. Apesar disso não fiquei convencido e, eu, pecador (além de basco), fiz um programa em DBase III Plus (que produto!) muito simples e integrável que resolveu o assunto. Sorte minha não ter que migrar ao RPG porque me daria mal!
Meu problema hoje
Há alguns dias precisei fazer uma aplicação e queria que tivesse Geografias (a frequente Pais/Estado/Cidade); peguei o caminho “conhecido”.
O primeiro que fiz foi definir a estrutura geográfica, bastante simples:
CountryID*CountryName(StateId*StateName(CityId*CityName))
Depois comecei a desenvolver pelo “velho_conhecido_seguro_confiável” caminho de um procedure com “news” que acrescentasse os dados. Algo do tipo:
new
CountryId=1
CountryName=”Uruguai”
endnew
new
CountryId=1
StateId=1
StateName=”Montevidéu”
endnew
new
CountryId=1
StateId=1
CityId=1
CityName=”Montevidéu”
endnew
etc., etc., etc.
Houve um momento de “copy/paste” bastante extenso e chato, processo no qual cometi N erros (é frequente quando fico aborrecido): em um bloco errava ao colocar o código do país e ficavam mal os dados e assim por diante.
Tem que existir um modo melhor
“Inicializar” dados é algo que costumo precisar porque faço muitas KBs “from scratch” e ter sempre um jogo de dados “razoável” é um problema.
Acredito também que é algo bastante comum em processos de implantação onde depois do “create” é preciso acrescentar a base de dados com dados iniciais.
Procurei algumas KBs para ver como tinha sido resolvido (GXserver!) e achei em vários lugares a mesma solução do procedure e os news. Inclusive alguma parecida com o que estava procurando, mas não o suficiente como para reutilizá-la a baixo custo.
Lembrei de um DataProvider que publiquei faz tempo no wiki, um que fiz com um pequeno programa para ler os ISO codes de um Excel que gera um TXT com o formato DP, depois “copiei/colei” do TXT no DataProvider. Às vezes pratico esses esportes.
Esse Data Providers é bom, mas não tem os estados nem as cidades… enfim… não aplicava muito para meu caso, porém dos DP parecia chegar a solução.
Ao final da história (vou abreviar) fiquei com uma solução com DataProviders que retorna os dados e um procedure que em lugar de um “new” usa um business component, também utilizei autonumber e um par de série para evitar a confusão da primary key.
A seguir um vídeo de como o fiz:
Vantagens que encontrei
1. Mais simples. Quero acrescentar a estrutura de Countries, então Drag&drop a um DP, mais alguma coisa e pronto.
2. Mais barato. Levou muito menos tempo a versão inicial. Embora tive um trabalho de “copy/paste”, foi mais simples, pelo menos não me preocupei dos CountryCode, StateCode, etc.
3. Mais claro. Separei a “alta” da “fonte de dados”, assim se quiser adicionar dados não tenho que me colocar com os news nem nada, simplesmente os adiciono no DP.
4. Mais potente. No meu caso era uma estrutura bastante simples com regras simples, mas igual resolveu o alta, a numeração e as regras que tiver associadas ao Country, etc. (se tiver que adicionar alguma regra a TRN do Countries sei que não terei que modificar o procedure, isto é importante para a consistência/qualidade dos dados).
5. Mais reusável. Meu desafio agora é evitar o copy/paste e intuo que via o Data Provider Generator e serviços como os de freesbase.com não terei maiores inconvenientes (assim que puder mergulhar em freebase.com um pouco mais).
De qualquer forma se isto o implementasse em um cliente talvez a fonte de dados seja outra e tendo separado os dados da alta, considero que será mais fácil adaptar o “input” do DP.
Enfim, várias vantagens do uso do DP e BC em um cenário como o descrito. Depois de “abrir minha mente” em relação aos DP e BC acredito que há muitos mais cenários de uso possíveis para os mesmos, então minha mensagem é somente esta: mantenha sua mente alerta, há novas e melhores soluções para novos e velhos problemas.
Ah… esquecia: Karina tinha razão: só temos de abrir nossa mente, para a atualização é suficiente a transação (ou quase).
* Publicado em Blog de Gustavo Carriquiry |
| | | | | | | | |
| |