Puede separar las tareas de una aplicación de proceso por lotes 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 pasos
de trabajo por lotes se ejecutan secuencialmente.
Los métodos de retorno de llamada de BatchJobStepLocalInterface
permiten que los puntos finales de Compute Grid ejecuten 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. Los puntos finales de Compute Grid de un bucle por lotes llaman al método processJobStep de un EJB de pasos por lotes.
Este método contiene toda la lógica que se puede procesar por lotes para actuar
en los datos.
Los puntos finales de Compute Grid invocan los métodos del EJB
de pasos por lotes en una transacción global. Los puntos finales de Compute Grid gestionan 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.
Existen los siguientes métodos de retorno de llamada de los
puntos finales de Compute Grid en la
BatchJobStepLocalInterface que están invocados por los
puntos finales de Compute Grid en la siguiente lista ordenada:
- setProperties(java.util.Properties properties): hace que las propiedades definidas en
el lenguaje de control de trabajos XML (xJCL) están disponibles para el paso por lotes de
un objeto java.util.Properties. Este método se invoca en 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 invoca en una transacción global.
- int processJobStep(): repetidamente invocado por los
puntos finales de Compute Grid 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. Revise las 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 a los
puntos finales de Compute Grid que continúen llamando a este
método del bucle por lotes. Un código de retorno de BatchConstants.STEP_COMPLETE indica a
los puntos finales de Compute Grid que el paso ha finalizado.
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 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 puntos finales de Compute Grid y representa el código de retorno del paso por lotes.
Si el algoritmo de resultados está asociado con el trabajo por lotes, el código de
retorno se pasa al algoritmo. Si existe una lógica condicional basada en el código de
retorno en el xJCL del trabajo por lotes, los
puntos finales de Compute Grid utilizan este código de retorno
para evaluar esa lógica.
Los puntos finales de Compute Grid no llaman actualmente al
método getProperties() de BatchJobStepLocalInterface. El método se incluye en la interfaz
por razones de simetría y para su posible uso posterior.
Resolución de problemas durante el desarrollo por lotes
- Debe declarar el descriptor de despliegue del bean de controlador por lotes en el
descriptor de despliegue de Enterprise JavaBeans (EJB) de una aplicación de proceso por
lotes e incluir referencias de EJB locales al enterprise bean de pasos utilizado en la
aplicación de proceso por lotes. Únicamente un bean de controlador puede definirse por aplicación de
proceso por lotes.
- Establezca los atributos de transacción de todos los métodos de pasos por lotes en
necesarios.
- 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 los puntos finales de Compute Grid.
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 falla.
- 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, deben efectuarse 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, no hay garantía de que la solicitud de reinicio sea aceptada por la máquina donde se ha ejecutado originalmente el trabajo por lotes. Esto puede ocurrir 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 miembros de nodos, y si un trabajo de proceso por lotes que se ejecuta en dicha aplicación se cancela y, a continuación, se vuelve a iniciar. En este
caso de ejemplo, es posible que la ubicación envíe la solicitud 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, puede aplicar las siguientes soluciones 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. Utilice un sistema de archivos de red para este ejemplo. Esta acción puede reducir
el rendimiento de la aplicación.
- Despliegue la aplicación en los servidores de aplicaciones que sólo pueden ejecutarse
en la máquina donde existen los datos locales. Para ello, despliegue la aplicación en un
clúster dinámico que exista en un grupo de nodos que sólo tenga un nodo.