As tarefas distintas de uma aplicação em batch podem ser divididas em
etapas de batch. As etapas de batch são implementadas como EJBs (Enterprise JavaBeans)
gerenciados por contêiner locais que especificam o com.ibm.websphere.batch.BatchJobStepLocalInterface como suas interfaces de negócios.
Os métodos de retorno de chamada no BatchJobStepLocalInterface permitem que o LREE (Long-running Execution Environment) execute as etapas de batch quando executar a tarefa do batch.
Um EJB de etapa de batch contém a lógica de negócios em batch a ser executada para uma
parte da tarefa do batch. Tipicamente, uma etapa de batch contém o código para ler um
registro de um fluxo de dados de batch, desempenhar a lógica de negócios com esse
registro e, em seguida, continuar lendo o próximo registro. O método processJobStep
de um EJB de etapa de batch é chamado pelo LREE em um loop de batch. Esse método deve
conter toda a lógica que pode ser colocada em batch para desempenhar os dados.
O LREE chama os métodos EJB da etapa de batch sob uma transação global. Essa
transação global é gerenciada pelo LREE. O comportamento da transação, como o
tempo limite ou o intervalo de confirmação da transação, é controlado
pelo algoritmo de ponto de verificação associado à tarefa do batch à qual a etapa
pertence.
A seguir encontram-se os métodos de retorno de chamada LREE no BatchJobStepLocalInterface
que são chamados pelo LREE na ordem listada:
- setProperties(java.util.Properties properties) - torna propriedades definidas
no xJCL disponível para a etapa de batch em um objeto java.util.Properties.
Esse método será chamado em uma transação global.
- void createJobStep() - indica a etapa que foi
inicializada. A lógica de inicialização, como recuperar um manuseio para um fluxo de dados de batch, pode ser colocada aqui. Esse método será chamado sob uma transação global.
- int processJobStep() - chamado repetidamente pelo LREE em um loop
de batch até que o inteiro do código de retorno desse método indique que a
etapa terminou o processamento. Consulte BatchConstants na API do batch para ver quais
códigos de retorno podem ser retornados. Um código de retorno de sinais
BatchConstants.STEP_CONTINUE ao LREE que deve continuar para chamar esse método no loop de
batch. Um código de retorno do BatchConstants.STEP_COMPLETE indica no
LREE que a etapa foi concluída e agora chama o destroyJobStep.
- int destroyJobStep() - indica a etapa que foi concluída.
O código de retorno de inteiro desse método é inteiramente arbitrário e pode ser escolhido
pelo desenvolvedor de aplicativos do batch. Esse código de retorno é salvo no banco de dados
LREE e representa o código de retorno da etapa de batch. Se o Algoritmo de Resultados for associado à tarefa do batch,
esse código de retorno será transmitido a ele. Se houver um código de retorno baseado em
lógica condicional no xJCL da tarefa do batch, o LREE utilizará esse código de retorno
para avaliar essa lógica.
Observe que o método getProperties() no BatchJobStepLocalInterface
não é chamado atualmente pelo LREE. Ele é incluído na interface para simetria
e possível utilização futura.
Resolvendo Problemas no Desenvolvimento em Batch
- O descritor de implementação do bean do controlador de batch deve ser declarado
no descritor de implementação EJB de uma aplicação em batch e deve ter referências
EJB locais aos EJBs de etapa utilizados em uma aplicação em batch. Apenas um
bean do controlador pode ser definido por aplicação em batch.
- Os atributos de transação de todos os métodos de etapa de batch devem ser configurados
conforme requerido.
- O desenvolvedor da aplicação em batch deve assegurar que o trabalho transacional
seja feito nos métodos de retorno de chamada da etapa de batch herde a transação global
iniciada pelo LREE. Isso assegurará que o trabalho executado em uma etapa de batch seja
confirmado apenas em cada ponto de verificação e que seja revertido caso a etapa encontre
uma condição de falha.
- Se a etapa de batch utilizar um BDS (Batch Data Stream) cujos dados sejam
locais para o sistema de arquivo do servidor de aplicativos ao qual o aplicativo do
batch é implementado, é importante executar determinadas etapas para suportar os cenários
de reinício da tarefa. Se tal aplicativo em batch for implementado nos servidores de aplicativos
que podem ser executados em várias máquinas, por exemplo, quando implementados em um cluster
dinâmico existente em um grupo de nós que tem vários membros do nó e se uma tarefa do batch
executada neste aplicativo for cancelada e, em seguida, reiniciada,
não haverá garantia de que o pedido de reinício irá para a máquina na qual a
tarefa do batch foi executada originalmente. Quando implementado em um cluster dinâmico que existe em um grupo de nós que possua vários membros de nós e uma tarefa de batch que seja
executada nesse tipo de aplicativo foi cancelada e reiniciada, não haverá garantias de que
o pedido de reinício chegará à mesma máquina. Nesse cenário, o posicionamento de execução longa pode enviar o pedido de reinício para um servidor de aplicativo que seja executado
em uma máquina diferente. Portanto, em casos onde a afinidade baseada em arquivo
é requerida, as seguintes soluções podem ser aplicadas para suportar o cenário
de reinício de tarefa:
- Certifique-se de que os dados fiquem igualmente disponíveis em cada máquina na qual a
aplicação em batch pode ser iniciada. Por exemplo, através de um sistema de arquivos de
rede (isso pode reduzir o desempenho do aplicativo).
- Implemente o aplicativo no(s) servidor(es) de aplicativos que possa(m) aparecer apenas
na máquina em que existam dados locais. Isso pode ser alcançado implementando
o aplicativo em um cluster dinâmico existente em um grupo de nós que possua
apenas um nó de membro.