Questa è generalmente una buona applicazione per Spring Batch e sembra che tu capisca abbastanza bene la separazione logica di Reader, Processor e Writer.
Ci sono alcune cose che dovresti considerare e pensare quando si tratta di un'applicazione come questa. Spring Batch ti dà il concetto di chunking in cui invece di leggere / elaborare / scrivere ogni record uno alla volta puoi leggere diversi elementi come un chunk, elaborarli come una singola transazione e scriverli come una singola transazione. Qualcosa che non mi è chiaro in base alla tua domanda è come apparirà il tuo modello di dominio nella tua applicazione dove è possibile. Sembra che ci sia una relazione uno a molti dall'URL agli utenti. Probabilmente leggeresti un singolo URL e costruirai una raccolta di oggetti User pronti per essere elaborati e scritti come una singola transazione.
La seconda cosa che prenderei in considerazione nel tuo progetto e in generale una buona pratica per entrare in fase di progettazione del software è documentare quali sono i tuoi vincoli di sistema.
- Esistono mezzi alternativi per recuperare i dati richiesti su un utente a parte lo scraping dello schermo? Se non documenta i vincoli esistenti.
- Quale sistema o componente software richiede che i dati dell'utente siano forniti dal software (API REST). Questo software di terze parti è in grado di acquisire un file batch per l'input anziché l'API REST? Ci sono altre potenziali interfacce che potrebbero essere più affidabili?
Buono anche per documentare i rischi:
- Lo scraping dello schermo presenta uno stretto accoppiamento tra il web design e l'applicazione e il lavoro in batch
Alla luce di queste informazioni vorrei progettare come tale:
Reader
- Recupera l'URL dal database
- Scrape schermo per i dati utente
- Crea oggetti
List<User> per il passaggio Processore
Processore
- Integrazione di dati da più lettori, se applicabile?
- Regole di elaborazione speciali o calcolo dei dati derivati?
- Preparazione dell'oggetto utente per i writer
Writer
- Un unico autore per persistere nel tuo database
- Secondo autore unico per l'API POST a REST
Ogni chunk sarà composto da utenti in un singolo URL. Ogni blocco in corso deve essere sottoposto a transazioni in modo che in caso di un'eccezione o di un errore, è possibile eseguire il rollback di eventuali modifiche persistenti. Nel caso di un'eccezione, è possibile definire un comportamento di rollback personalizzato per l'API REST?
Le tue considerazioni finali dovrebbero essere la supportabilità e la manutenibilità del lavoro batch. Potresti prendere in considerazione l'amministratore di Spring Batch per questo. Ogni volta che il processo aziendale dipende dalle risorse URL per la rete interna o esterna, lo scraping dello schermo e la disponibilità e il corretto funzionamento di un'API REST, ritengo che questo sia un rischio sufficientemente elevato. Ci sono molti potenziali punti di errore in questo lavoro, quindi non solo le Transazioni e una buona gestione delle eccezioni sono un must, ma anche la possibilità di amministrarle facilmente e con un intervento manuale minimo.
L'amministratore di Spring Batch gestisce un database di lavori storici nonché i lavori attualmente in esecuzione e i lavori in pausa e non riusciti. È possibile configurare un processo Spring Batch gestito con Spring Batch Admin per riprendere da dove il lavoro non funzionante è stato interrotto. Forse il tuo lavoro ha ottenuto 350 URL da 400 di scansione. Non è necessario pulire e ricominciare da capo se è possibile riavviare l'istanza di lavoro non riuscita, verrà ripresa al record 351 e riproverà. Potresti anche essere in grado di farlo attendere alcuni minuti e provare più volte prima di inviare notifiche.
Spero che questo ti dia delle cose da considerare.