Tenía pendiente desde hace unos días escribir algo sobre uno de los componentes de Spring más desconocidos:
Spring Batch. Desde luego, Spring Batch ni suena, ni es uno de los componentes más
sexies o excitantes con los que uno se vaya a encontrar en su vida laboral, a fin de cuentas los batches son una de esas cosas que cuando te la nombran ya se te ponen los pelos como escarpias; pero el caso es que es uno de esos frameworks oscuros que hacen su labor.
Hace unas semanas, tuve la oportunidad de jugar, no dejó de ser un juego, con esta librería durante unos días, y la verdad es que tengo que reconocer que quedé mucho más satisfecho de lo que me experaba. Me explico. Cuando uno se enfrenta a la
página principal y de
features del framework, uno se queda con el sabor de boca de que está delante de algo en los que sus creadores se han pasado de rosca. "
Overengineered para lo que quiero hacer", es lo primero que pensé yo.
Aún así, conforme vas adentrándote en
su documentación, y vas comprendiendo sus conceptos, y sobre todo conforme vas implementando algo de código, te das cuenta de su modularidad. En especial en un mundo, el de los
batches, donde literalmente "vale todo", y los programas tienden a ser los más monolíticos, sucios, incomprensibles y difíciles de mantener por lo general que uno se pueda encontrar. Que conste que esto que pongo se basa única y exclusívamente en mi experiencia laboral (que no es realmente muy amplia), pero es que siempre que me ha tocado lidiar con algún proceso batch, siempre ha sido la parte que a todos nos daba miedo tocar. Tanto da que sea un proceso que realiza un cálculo de gestión de costes cada mes, o un proceso que cierra cuentas de traders y envía informes a medianoche en Java, o un proceso que extrae noticias de fuentes cada cinco minutos y las va procesando. Siempre es lo mismo. No sé que pasa que con este tipo de procesos periódicos, la cosa siempre se lía.
Por eso uno, después de desarrollar un pequeño batch con Spring Batch se da cuenta de que mmmm, quizás el diseño no sea excesivo, es más, por fin creo que tengo delante de mi un batch realmente mantenible.
Si estáis pensando que Spring Batch es una librería cuyo uso sólo se aplica a aplicaciones bancarias que procesen enormes cantidades de registros a medianoche, estáis equivocados. Esta es una herramienta realemente aplicable a un amplio número de procesos ya que se basa en unas abstracciones muy generales. En mi opinión, Spring Batch no es realmente un framework si no un esqueleto de aplicación de procesado de datos. Y como tal, se puede aplicar a muchos entornos y problemas.
Describiéndolo muy rápidamente, Spring Batch define lo que son Trabajos que a su vez están definidos en tareas:
<bean id="footballJob"
class="org.springframework.batch.core.job.SimpleJob">
<property name="steps">
<list>
<!-- Step Bean details ommitted for clarity -->
<bean id="playerload" parent="simpleStep" />
<bean id="gameLoad" parent="simpleStep" />
<bean id="playerSummarization" parent="simpleStep" />
</list>
</property>
<property name="restartable" value="true" />
</bean>
Spring Batch se encargará de ejecutar estos trabajos y tareas y de repetirlos si se ha producido un error y cosas así, pero también de lo que quizás sea más importante: de guardar contabilidad de todo lo que ha pasado con estos trabajos y tareas en base de datos.
| JOB_EXECUTION_ID | JOB_INSTANCE_ID | START_TIME | END_TIME | STATUS |
| 1 | 1 | 2008-01-01 21:00:23.571 | 2008-01-01 21:30:17.132 | FAILED |
Así, por ejemplo si nuestro proceso batch fuera un demonio que lee noticias RSS de diferentes sitios web (por poner algo diferente a bancos y todo esto) y las almacena en base de datos. Tendríamos un trabajo (o varios) con diferentes tareas que se encargarían de recoger las noticias y almacenarlas. Lo genial de Spring Batch es que podríamos configurar estas tareas como repetibles en caso de error, y que Spring Batch iría rellenando la tabla que veis arriba con los resultados de las diferentes ejecuciones. Sin ningún esfuerzo estamos obteniendo una enorme transparencia y monitorabilidad en nuestra aplicación.
Bueno, para mi esto que he explicado es lo más importante. A mayores Spring Batch ofrece muchas más cosas. Por ejemplo, cada trabajo podrá utilizar diferentes
Writers,
Readers o
Transformers. Spring Batch viene por defecto con diferentes tipos de
Readers para leer ficheros planos, XML o datos de base de datos. Estos
Readers se configuran con una especie de mapeo entre registros y objetos de modo que algo en principio complicado como:
ID,lastName,firstName,position,birthYear,debutYear
"AbduKa00,Abdul-Jabbar,Karim,rb,1974,1996",
será traducido en:
public class Player implements Serializable {
private String ID;
private String lastName;
private String firstName;
private String position;
private int birthYear;
private int debutYear;
por obra y gracia de Spring Batch. Esos datos podrían por ejemplo ser transformados con cadenas de transformadores en base a diferentes reglas y posteriormente almacenados utilizando un
Writer a base de datos con su correspondiente mapeo entre los diferentes campos y las columnas de una tabla que recoja esos datos.
En fin, que no quiero aburriros mucho, que realmente creo que la gente de Spring ha hecho un buen trabajo al recopilar patrones comunes en las aplicaciones de manejo de datos, ofreciento artefactos para leer, tratar y almacenar estos datos, para ejecutar, parar, saltarse o repetir tareas sobre estos datos, y para monitorizar el estado de las ejecuciones del proceso sobre estos datos. Todo este trabajo nos permite hacer aplicaciones de tratamiento de datos, es decir aplicaciones batch, realmente mantenibles, aunque tenga el coste inicial de comprender y acostumbrarse al framework.
¿Alguno tiene alguna experiencia con Spring Batch que quiera compartir?
