É possível separar tarefas de um aplicativo em lote em etapas em lote.
As etapas em lote são implementadas como EJBs (Enterprise JavaBeans) gerenciados pelo contêiner
local que especificam a com.ibm.websphere.batch.BatchJobStepLocalInterface
como sua interface de negócios. As etapas da tarefa em lote são executadas em seqüência.
Os métodos de retorno de chamada no BatchJobStepLocalInterface permitem ao
terminais de Compute Grid executar etapas em lote ao executar
uma tarefa em lote.
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 da etapa em lote é chamado pelo terminais de Compute Grid
em um loop de lote. Esse método contém toda a lógica que pode ser colocada em lote para executar
os dados.
Os terminais de Compute Grid chamam os métodos EJB
da etapa em lote em uma transação global. Essa transação global é gerenciada pelo
terminais de Compute Grid. 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.
Os seguintes métodos de retorno de chamada dos
terminais de Compute Grid
existem na BatchJobStepLocalInterface que são chamados pelos
terminais de Compute Grid na seguinte lista
ordenada:
- setProperties(java.util.Properties properties): Disponibiliza as propriedades
definidas no xJCL (XML Job Control Language) para a etapa em lote em um objeto
java.util.Properties. Esse método é chamado em uma transação global.
- void createJobStep(): Indica à etapa que ela 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 é chamado em uma transação global.
- int processJobStep(): Chamado repetidamente pelos terminais de Compute Grid em
um loop de lote, até que o inteiro do código de retorno desse método indique que a
etapa concluiu o processamento. Revise BatchConstants na API do lote para ver
quais códigos de retorno podem ser retornados. Um código de retorno BatchConstants.STEP_CONTINUE
sinaliza aos terminais de Compute Grid para continuar a
chamar esse método no loop de lote. Um código de retorno de BatchConstants.STEP_COMPLETE
indica aos terminais de Compute Grid que
a etapa foi concluída. Agora ele chama destroyJobStep.
- int destroyJobStep() - indica à etapa que a conclusão ocorreu.
O código de retorno de inteiro desse método é arbitrário e pode ser escolhido pelo
desenvolvedor de aplicativos em lote. Esse código de retorno é salvo no banco de
dados terminais de Compute Grid e representa o código de
retorno da etapa de lote. Se o algoritmo de resultados
estiver associado à tarefa em lote, esse código de retorno será transmitido a ele. Se
houver uma lógica condicional baseada em código de retorno no xJCL da tarefa em lote,
os terminais de Compute Grid utilizarão esse código de
retorno para avaliar essa lógica.
O método getProperties() na BatchJobStepLocalInterface não é chamado atualmente
pelos terminais de Compute Grid. Ele
é incluído na interface para simetria e possível utilização posterior.
Resolvendo Problemas no Desenvolvimento em Lote
- O descritor de implementação do bean do controlador em lote deve ser declarado
no descritor de implementação EJB (Enterprise JavaBeans) de um aplicativo em lote
e incluir referências EJB locais nos enterprise beans da etapa utilizados em um aplicativo em
lote. Apenas um
bean do controlador pode ser definido por aplicação em batch.
- Configure os atributos de transação de todos os métodos da etapa em lote como necessários.
- O desenvolvedor de aplicativos em lote deve garantir que o trabalho transacional feito
nos métodos de retorno de chamada da etapa em lote herde a transação global iniciada
pelos terminais de Compute Grid. Esta ação garantirá
que o trabalho executado em uma etapa em lote seja confirmada apenas em cada ponto de verificação
e que seja recuperada se a etapa falhar.
- Se a etapa em lote usar um Batch Data Stream (BDS), cujos dados são locais para o sistema de arquivos do servidor de aplicativos no qual o aplicativo em lote está implementado, determinadas etapas deverão ser seguidas para suportar cenários de reinício de tarefas. Se esse aplicativo em lote estiver implementado nos servidores de aplicativos que podem ser executados em várias máquinas, não haverá nenhuma garantia de que o pedido de reinício será aceito pela máquina na qual a tarefa em lote foi executada originalmente. Isso pode ocorrer quando o aplicativo em lote estiver implementado em um cluster dinâmico que existe em um grupo de nós que tem vários membros de nós, e se uma tarefa em lote que é executada em relação a esse aplicativo for cancelada e, em seguida, reiniciada. Nesse cenário, o posicionamento pode
enviar o pedido de reinício para um servidor de aplicativos que é executado
em uma máquina diferente. Portanto, em casos onde a afinidade baseada em arquivo é necessária, as
seguintes soluções poderão 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. Utilize um Network File System para este exemplo.
Esta ação pode reduzir o desempenho do aplicativo.
- Implemente o aplicativo em servidores de aplicativos que só possam ser executados na
máquina em que existam dados locais. Conclua esta ação implementando o
aplicativo em um cluster dinâmico existente em um grupo de nós que possua apenas
um nó de membro.