Las tareas diferenciadas de una aplicación de proceso por
lotes pueden dividirse en pasos por lotes. Los pasos por lotes se implementan como EJB (Enterprise
JavaBeans) locales gestionados por contenedor que especifican
com.ibm.websphere.batch.BatchJobStepLocalInterface como la
interfaz de empresa.
Los métodos de retorno de llamada de BatchJobStepLocalInterface
permiten que el entorno de larga ejecución (LREE) ejecute pasos por lotes
cuando ejecute un trabajo por lotes.
Un EJB de pasos por lotes contiene la lógica empresarial que se puede
procesar por lotes para ejecutar una parte del trabajo por lotes. Generalmente, un paso por
lotes contiene código para leer un registro de una secuencia de datos por
lotes, realizar la lógica empresarial con ese registro y, a continuación,
leer el siguiente registro. El LREE de un bucle por lotes llama al método
processJobStep de un EJB de pasos por lotes. Este método debería
contener toda la lógica que se puede procesar por lotes para actuar en
los datos.
El LREE invoca a los métodos del EJB de pasos por lotes bajo una
transacción global. El LREE gestiona esta transacción global. El algoritmo
de punto de control asociado con el trabajo por lotes al que pertenece el
paso controla el comportamiento de la transacción como, por ejemplo, el
tiempo de espera excedido de transacción o el intervalo de compromiso de
transacción.
A continuación aparecen los métodos de retorno de llamada de LREE de
BatchJobStepLocalInterface invocados por el LREE en el orden enumerado:
- setProperties(java.util.Properties properties): hace que las
propiedades definidas en xJCL están disponibles para el paso por lotes de
un objeto java.util.Properties. Este método se invocará bajo una
transacción global.
- void createJobStep(): indica al paso que se ha inicializado. La
lógica de inicialización como, por ejemplo, la recuperación de
un descriptor de contexto de una secuencia de datos por lotes, puede
colocarse aquí. Este método se invocará bajo una transacción global.
- int processJobStep(): repetidamente invocado por el LREE de un bucle por lotes hasta que el número entero del código de retorno de
este método indica que el paso ha finalizado su proceso. Consulte
BatchConstants en la API por lotes para ver qué códigos de retorno pueden
devolverse. Un código de retorno de BatchConstants.STEP_CONTINUE
indica al LREE que debe continuar llamando a este método del bucle por lotes. Un código de retorno de BatchConstants.STEP_COMPLETE indica al
LREE que el paso ha finalizado y que ahora está llamando a destroyJobStep.
- int destroyJobStep(): indica al paso que se ha completado. El
número entero del código de retorno de este método es totalmente
arbitrario y puede seleccionarlo el desarrollador de aplicaciones de proceso por lotes. Este código de retorno se guarda en la base de datos de LREE y
representa el código de retorno del paso por lotes. Si
el Algoritmo de
resultados está asociado con el trabajo por lotes, este código de
retorno se pasará a ese algoritmo. Si existe una lógica condicional
basada en el código de retorno en el xJCL del trabajo por lotes, el LREE
utilizará este código de retorno para evaluar esa lógica.
Tenga en cuenta que el LREE no llama actualmente al método
getProperties() de BatchJobStepLocalInterface. Se incluye en la
interfaz por razones de simetría y para su posible uso en el futuro.
Resolución de problemas durante el desarrollo por lotes
- El descriptor de despliegue del bean de controlador por lotes debe
declararse en el descriptor de despliegue EJB de una aplicación
de proceso por lotes y debe tener referencias de EJB locales a
los EJB de pasos utilizados en la aplicación de proceso por
lotes. Únicamente un bean de controlador puede definirse por aplicación de
proceso por lotes.
- Los atributos de transacción de todos los métodos de pasos por lotes
deben establecerse en necesario.
- El desarrollador de aplicaciones de proceso por lotes debe garantizar
que el trabajo transaccional realizado en los métodos de retorno
de llamada de pasos por lotes hereda la transacción global iniciada por
el LREE. Con esta acción se garantiza que el trabajo realizado durante un
paso por lotes sólo se compromete en todos los puntos de control y se
retrotrae si el paso se encuentra con una condición anómala.
- Si el paso por lotes utiliza una secuencia de datos por lotes (BDS)
cuyos datos sean locales para el sistema de archivos del servidor de
aplicaciones en el que está desplegada la aplicación de proceso por lotes, es importante realizar varios pasos para dar soporte a los casos de ejemplo
de reinicio de trabajos. Si una aplicación de proceso por lotes de este
tipo se despliega en servidores de aplicaciones que pueden ejecutarse en
varias máquinas, por ejemplo, cuando se despliega en un clúster dinámico
que existe en un grupo de nodos que tiene varios nodos, y si un trabajo
por lotes que se ejecuta en esta aplicación se cancela
y se vuelve a iniciar, no hay garantía de que la petición de reinicio vaya
a la máquina donde se ha ejecutado originalmente el trabajo por lotes.
Cuando la aplicación de proceso por lotes se despliega en un clúster
dinámico que existe en un grupo de nodos que tiene varios nodos, y un
trabajo por lotes que se ejecuta en ésta se cancela y se vuelve a iniciar,
no hay garantía de que la petición de reinicio vaya a la misma máquina. En este caso de ejemplo, es posible que la ubicación
de larga ejecución envíe la petición de reinicio a un servidor de
aplicaciones que se ejecute en una máquina distinta. Por lo tanto,
en los casos donde es necesaria la afinidad basada en archivos,
las siguientes soluciones pueden aplicarse para dar soporte al
caso de ejemplo de reinicio de trabajo:
- Asegúrese de que los datos estén igualmente disponibles para todas
las máquinas donde se pueda iniciar la aplicación de proceso por
lotes. Por ejemplo, como ocurriría a través de un sistema de archivos en
red (esto puede reducir el rendimiento de la aplicación).
- Despliegue la aplicación en los servidores de aplicaciones que
sólo pueden activarse en la máquina donde existen los datos locales. Esto
puede llevarse a cabo desplegando la aplicación en un clúster dinámico
que exista en un grupo de nodos que sólo tenga un nodo.