Temario‎ > ‎

Arquitectura Batch

Descripción

Lo que llamamos arquitectura "batch" se puede pensar como un patrón, pero a diferencia de los patrones de diseño que conocemos, se trata de uno con mayor alcance (scope), que involucra a la aplicación y sus partes.
Entonces, al igual que los patrones aplica en ciertos casos o para resolver ciertas problemáticas.
Veámos cuales son las características de estos casos:
  • Procesamiento de grandes volúmenes de información.
  • Sin interacción (directa) del usuario.
  • Requerimientos no funcionales complejos e importantes:
    • trazabilidad de la información y su ejecución.
    • alta velocidad de ejecución/procesamiento

Qué es una aplicación batch ?

Podemos pensarla como una aplicación standalone que se ejecuta periódicamente para realizar una tarea y luego termina.
Esta tarea generalmente se tiene 3 partes:
  • Input: se obtiene y lee la información de entrada al proceso.
  • Procesamiento: se realiza algún tipo de lógica de negocio sobre estos datos de entrada.
  • Output: se escribe o realiza alguna acción como resultado del procesamiento.

El ejemplo típico y clásico es el de la aplicación de facturación. Que se ejecuta una vez por mes, y por cada cliente realiza el cálculo del consumo y el costo a pagar, emitiendo la factura como resultado.

Complejidades de una aplicación batch

Se preguntarán: tanto lío para eso ? Parece simple, parece fácil, y también parece ya bien conocido y nada nuevo.
Porque muchas veces cuando empezamos a aprender a programar, practicamos con ejemplos que uno pensaría, son como estos. Entradas, procesamiento, y salidas.
Parece programación estructurada.

Entonces las complejidades están en varios puntos
  • Inputs
    • Problemáticas propias de cada tecnología:
      • Archivos de texto
        • XML
        • CSV
        • etc
      • Conexión y lectura de bases de datos
      • Conexiones con sistemas externos: webservices, etc.
    • Particionamiento y agrupamiento de "registros"
  • Outputs
    • Problemáticas propias de cada tecnología: de nuevo DB, archivos de texto, etc.
    • Buffering
  • Incumbencias transversales
    • Ejecución
      • Flujo: decisiones y descomposición en nodos.
      • Paralelismo: optimización de ejecución con ejecución de tareas en paralelo.
      • Reintentos: ante fallos
    • Transacciones:
      • delimitación de transacciones
      • rollback
    • Trazabilidad:
      • registro del estado de ejecución de cada registro
      • tiempos de ejecución
      • información propia de dominio
      • Necesario para futuros reportes y estadísticas de negocio.
  • Performance
    • Tiempos de ejecución
    • Operaciones de I/O y su optimización
    • Uso de recursos y su optimización
      • conexiones a base de datos
      • conexiones a sistemas externos (http, webservices, etc)

Spring Batch Framework

Este framework modela las ideas que venimos mencionando hasta ahora, y provee un conjunto de implementaciones reutilizables como componentes para input, output, etc.
Además se integra con el microcontenedor spring y sigue la misma filosofía de frameworks simples orientados al dominio (POJOs).

Job

La primer entidad o concepto que podemos mencionar es el Job que representa al proceso completo. Para poner un ejemplo, y siguiendo con el clásico de facturación, nuestro Job sería FacturaciónJob.

Un job está compuesto por uno o más Step's, que como su nombre indica es un paso o una actividad dentro del proceso. Esto permite tener un grado de modularización dentro del proceso, y por ende, reutilización, abstracción, facilidad de testeo, etc.

Veamos como sería el ejemplo. Para eso contamos que el fwk provée una extensión a spring IoC mediante namespaces que hace más simple su utilización desde el xml. Una especie de "DSL".

//TODO: pensar un ejemplo digno que vayamos implementando de verdad y que vayamos completando durante toda la clase. Esto es sarasa como bosquejo
<job id="facturacionJob">
    <step id="clientes" next="consumos"/>
    <step id="consumos" next="creacionDeFactura"/>
<step id="creacionDeFactura"/> </job>

Step

Un Step, a su vez puede estar compuesto por varias partes, separando la lectura de elementos (ItemReader), el procesamiento (ItemProcessor) y la escritura (ItemWriter).


En este caso, nosotros somos los responsables de, o bien reutilizar una implementación de estas interfaces, o bien de implementarlas para nuestro dominio particular.
Lo interesante es que Spring Batch, o su implementación default de Step es la que se encarga de manejar la lógica de ejecución.
Y por default trabaja en la forma que se denomina Chunk-Oriented. Que quiere decir que se van leyendo items, procesando, y buffereando, hasta cierto número. Luego se procede a la escritura del chunk completo.


Continuando con nuestro ejemplo, definimos los steps

<job id="sampleJob">
    <step id="step1">
        <tasklet transaction-manager="transactionManager">
            <chunk reader="itemReader" writer="itemWriter" commit-interval="10"/>
        </tasklet>
    </step>
</job>

commit-interval define cada cuántos elementos procesados spring va a llamar al writer.

Reader & Writers

ItemReader es entonces una interface (strategy) que encapsula la respondabilidad de proveer items o elementos que luego serán procesados. La interface es bien sencilla como se muestra a continuación:

public interface ItemReader<T> {
    T read() throws Exception, UnexpectedInputException, ParseException;
}

Y lo mismo para el ItemWriter

public interface ItemWriter<T> {
    void write(List<? extends T> items) throws Exception;
}

Lo interesante acá es que, por un lado podemos hacer nuestra propia implementeción para conectarnos con un sistema externo u obtener información mediante alguna tecnología propietaria o nueva. Pero por otro lado, podemos reutilizar implementaciones ya existentes que provee spring batch y que muy probablemente se ajustan a la gran mayoría de los casos de uso:

  • Readers:
    • FlatFileItemReader
      • para leer archivos de texto en general y CSV (comma separated values)
      • introduce abstracciones aún más pequeñas (strategies) como: 
        • LineMapper
        • LineTokenizer: DelimitedLineTokenizer, FixedLengthTokenizer
        • FieldSetMapper: BeanWrapperFieldSetMapper
    • XML
      • independiente de la tecnología de parseo y binding a objetos: utiliza OXM (Object XML Mapping) y spring-oxm

    • //TODO: otros
  • Writers:
    • FlatFileItemWriter

Primer Ejemplo: Hola Mundo

Veamos entonces a detalle cómo sería un primer ejemplo con Spring Batch. Para eso, deberían instalarse el entorno como dice acá. Y luego, seguir los pasos como se indica en esta página.

Conceptos de Ejecución

//TODO: no me decido en el orden de esto. Trataría de patearlo y luego dar todo el soporte que tiene spring batch para trazabilidad y persistencia de la ejecución. Peeero, si para contar las implementaciones aparecen estas clases, capaz mejor explicarlo acá.

JobInstance, JobExecution, StepExecution, etc. Spring Batch Admin

Flujo de ejecución


Comments