Introdução ao Spring Batch

Todo ambiente de negócio em que grandes volumes de dados são continuamente gerados e processados acabará se tornando um potencial cliente de sistemas de processamento em lotes. Imagine, por exemplo, grandes operadoras de telefonia que recebem, por dia, milhares de ligações de clientes para reclamar de um serviço, buscar informações gerais ou, ainda, cancelar ou atualizar seus planos.

Todas as informações geradas a partir dessas experiências são muito valiosas e, quando combinadas com dados provenientes de outros sistemas e/ou serviços – como ERPs e CRMs – resultam em um material extremamente estratégico que pode ser usado – e frequentemente o é – para melhorar a experiência do público.

Neste caso que acabamos de citar, a leitura e a persistência desses dados são apenas os primeiros passos de uma série de outros que ocorrem no interior desses grandes sistemas.

Todo registro de entrada, quando armazenado, representa um evento bastante pontual, uma experiência bastante particular.

Quando combinados com toda uma base histórica previamente disponível, ganham uma importância muito mais evidente, pois somam-se a inúmeras ocorrências similares que, então, permitem a analistas traçar perfis de comportamento de seus clientes ao longo do tempo.

Além disso, nada impede que registros cheguem a uma plataforma por inúmeros pontos de entrada e, internamente, sejam combinados para representar uma informação de forma mais rica, mais completa.

Voltando ao exemplo de atendimento ao cliente, é possível que os diversos componentes envolvidos – atendimento automático, transferência para e entre agentes, dentre outros – utilizem sistemas de informação/armazenamento separados e, para que a interação do cliente seja representada de forma plena, algumas transformações e combinações devam ser realizadas.

Outro cenário típico de processamento de dados em lotes é o de sistemas de fechamento contábil utilizado pelas empresas, na organização de sua saúde financeira. Periodicamente, a cada fim de mês, todos os registros de entrada e saída de capital são combinados e processados para que um balanço final possa ser obtido. Novamente, percebemos que há um volume importante de registros que deve ser lido e processado para que possa, enfim, ser empregado em análises e tomadas de decisão.

Torna-se simples constatar, pelos exemplos supracitados, o quão amplo é o leque de cenários em que este tipo de sistema pode ser aplicado. Logo mais, na parte prática do artigo, veremos em detalhes outro exemplo bastante corriqueiro.

Ao mesmo tempo que esta arquitetura de sistemas é comum e sua empregabilidade tende a ser alta, seus componentes essenciais variam muito pouco em comportamento. Em linhas gerais, os elementos centrais destinam-se a:

· Organizar o processamento em lotes de itens;

· Ler itens em alguma fonte de dados;

· Escrever itens em alguma fonte de dados;

· Registrar todas as operações realizadas ao longo da vida útil do sistema.

As fontes de dados mais comuns, por sua vez, são bancos de dados relacionais, arquivos de texto em formatos como XML ou CSV e filas e tópicos de sistemas de mensageria. Essas fontes servem tanto para consumo quanto para escrita de itens, mas a operação de escrita ou leitura sobre elas é algo bem conhecido da grande maioria dos desenvolvedores, e sua implementação tende a não variar em lógica, mas no conteúdo do que se lê ou escreve.

Por esta breve descrição de apenas parte do que sistemas dessa natureza fazem, já identificamos características e operações que tendem a se repetir em toda implementação. Sendo assim, escrevê-lo a cada projeto que iniciamos seria, sem dúvidas, um consumo desnecessário de tempo e recursos; traria, também, o risco que todo código-fonte novo tem, por mais bem escrito e testado que esteja: a possibilidade de falhar.

A solução natural para alcançar alta produtividade ...