Spring Batch + Web Scraping

5

Eu preciso desenvolver um processamento em lote que será executado todos os dias. Estas são as etapas:

  1. Leia cada linha de uma tabela de banco de dados que contenha uma URL (SQLite)
  2. Extraia alguns dados, digamos User s, desse site, copiando-os. Cada site pode conter usuários 1.n.
  3. Persista cada User em um banco de dados NoSQL local.
  4. Envie cada User (um por um) por meio da API REST de terceiros.

Vou implementar esse processo usando o Spring Batch e pensei neste design:

  • Item Reader: Leia cada URL do banco de dados SQLite usando JdbcCursorItemReader.
  • Processador de itens: desfaça e desserialize os usuários do site. %código%
  • Criador de itens: para cada (Url -> List<User>) , persista no banco de dados e envie-o por meio da API REST.

Esta abordagem está correta? Devo mudar qualquer passo? Eu nunca trabalhei com Spring Batch, então estou disposto a mudar a tecnologia, se necessário. Preciso de alguns conselhos antes de começar a desenvolver, pois preciso que esse processo seja muito robusto.

    
por Héctor 03.12.2015 / 11:13
fonte

1 resposta

3

Em geral, essa é uma boa aplicação para o Spring Batch, e você parece entender bastante bem a separação lógica do Reader, Processor e Writer.

Há certas coisas que você deve considerar e pensar quando se trata de um aplicativo como este. O Spring Batch oferece o conceito de fragmentação, em vez de ler / processar / gravar cada registro, um de cada vez, que você pode ler em vários itens como um bloco, processá-los como uma única transação e gravá-los como uma única transação. Algo que não está claro para mim com base em sua pergunta é como será seu modelo de domínio em seu aplicativo para onde isso for possível. Soa como se houvesse um para muitos relacionamento de URL para os usuários. Você provavelmente leria em uma única URL e criaria uma coleção de objetos User prontos para serem processados e gravados como uma única transação.

A segunda coisa que eu consideraria em seu design e, geralmente, uma boa prática a ser usada ao criar um software é documentar quais são as restrições do sistema.

  • Existem meios alternativos para recuperar dados necessários sobre um usuário, além da captura de tela? Se não documentar as restrições que existem.
  • Qual sistema ou componente de software requer que os dados do usuário sejam fornecidos por seu software (API REST). Este software de terceiros tem a capacidade de obter um arquivo em lotes para entrada em oposição à API REST? Existem outras interfaces potenciais que podem ser mais confiáveis?

Também é bom documentar os riscos:

  • A captura de tela apresenta um acoplamento estreito entre o design da web e o aplicativo e seu trabalho em lote

À luz dessa informação, eu criaria assim:

Leitor

  • Recupere o URL do banco de dados
  • Captura de tela para dados do usuário
  • Crie um List<User> objetos para a etapa do Processador

Processador

  • Integração de dados de vários leitores, se aplicável?
  • Regras especiais de processamento ou cálculo de dados derivados?
  • Preparação do objeto Usuário para os escritores

Escritor

  • Um escritor exclusivo para persistir no seu banco de dados
  • Segundo escritor exclusivo do POST para a API REST

Cada parte será composta por usuários em um único URL. Cada bloco no processo deve ser transacionado para que, no caso de uma exceção ou falha, quaisquer alterações persistentes possam ser revertidas. No caso de uma exceção, é possível definir o comportamento de reversão personalizada para a API REST?

Suas considerações finais devem ser a capacidade de suporte e manutenção do trabalho em lote. Você pode querer considerar o Spring Batch Admin para isso. Sempre que seu processo de negócios depende de recursos de URL para rede interna ou externa, captura de tela e disponibilidade e funcionamento adequado de uma API REST, considero esse risco suficientemente alto. Existem muitos pontos potenciais de falha neste trabalho, de modo que não apenas as Transações e uma boa exceção são necessárias, mas também a capacidade de administrá-la facilmente e com mínima intervenção manual.

O Spring Batch Admin mantém um banco de dados de tarefas históricas, bem como trabalhos em execução no momento e pausados e com falhas. Você pode configurar um trabalho do Spring Batch gerenciado com o Spring Batch Admin para escolher onde o trabalho com falha foi interrompido. Talvez o seu trabalho tenha conseguido 350 URLs de 400 para digitalizar. Não há necessidade de limpar e começar de novo se você puder reiniciar a instância do job com falha, ela irá pegar no registro 351 e tentar novamente. Você pode até esperar alguns minutos e tentar várias vezes antes de enviar as notificações.

Espero que isso lhe dê coisas a considerar.

    
por 03.12.2015 / 14:00
fonte