Suite de Soluciones
EBS
FRONT
VIEW
WIZARD
 
     
     
 

Para resolver la ejecución de operaciones fuera de línea -que afectan a volúmenes masivos de datos y se estructuran en procesos que son corridos, ya sea manual o automáticamente desde un “programador de tareas”-, se han reutilizado en todo lo posible los componentes y servicios de la operatoria online. La arquitectura definida resuelve este reuso debido a la abstracción sobre la que se montan los componentes básicos. Ellos desconocen de dónde vienen los datos que usan ni las condiciones de cuándo y dónde deben grabarse dichos datos, lo que permite implementar un tipo de proceso compuesto especial para los procesos batch. Este mecanismo actúa en forma masiva, preparando el contexto a los componentes tal como ellos lo esperan, resolviendo la estrategia de iteración y manejo del lote de datos a procesar. Una operación batch toma objetos desde un cursor de la base de datos, armando el contexto con los objetos obtenidos de a uno e invocando a los componentes deseados. Esta estrategia permite reducir el acceso a la base de datos, precargando las entidades según sean necesarias. Dispone de lógicas especiales, según las cuales se pueden efectuar operaciones bajo modo de iteraciones. Así es posible definir la necesidad de un commit de la base de datos para evitar que crezca demasiado el “rollback segment” que el motor de la base asocia a la transacción en curso. Otro posible uso de estas lógicas especiales es la necesidad de dividir la tarea a efectuar en lotes por reglas de negocio, de modo de procesar todo un lote relacionado en forma conjunta. De esta manera se pueden ir cargando uno a uno datos asociados a ese lote que se procesa. La arquitectura permite múltiples motores de ejecución batch y la creación de operaciones batch ad-hoc de manera de alcanzar el máximo rendimiento. No obstante, el núcleo de una operación batch está compuesto por los mismos componentes básicos que resuelven la lógica de negocio. Cada sección de una operación batch se configura como si fuera un proceso puntual. Se han previsto dos alternativas para el caso que un proceso batch no llegue a término satisfactoriamente. En la primera, los datos necesarios para retomar el proceso están incluidos entre las tablas del modelo de negocio. En la segunda alternativa, el proceso mismo es idempotente pudiéndose correr las veces que fuera necesario manteniendo información extrínseca al modelo. En este caso la operación batch deberá recordar información para su retoma.

Diagrama estático de la arquitectura:

Ver también:

Máquina de Ejecución de Procesos
Contexto
Procesos
Manejo de los Errores
Acceso a Datos
Visión Desplegada
Estructura de Mínima


- Arquitectura MODHELUS
- MODHELUS CORE
- Características de Diseño
- Funciones Incluidas