Le signole attività di un'applicazione batch possono essere divise in operazioni batch. Le operazioni batch sono implementate come EJB (Enterprise JavaBeans)gestiti dal contenitore locale che specificano com.ibm.websphere.batch.BatchJobStepLocalInterface come interfaccia aziendale.
I metodi di richiamata in BatchJobStepLocalInterface consentono a LREE (long-running
execution environment) di eseguire operazioni batch quando eseguono un processo batch.
Un EJB di un'operazione batch contiene la logica di business che può essere divisa in batch per eseguire solo una parte del processo. Di solito, un'operazione batch contiene il codice necessario per leggere un record da un flusso di dati batch, per eseguire la logica di business associata a tale record e continuare a leggere il record successivo. Il metodo processJobStep si un EJB di un'operazione batch è richiamato dal LREE in un loop batch. Questo metodo deve contenere tutta la logica che può essere divisa in batched da eseguire sui dati.
LREE richiama i metodi dell'EJB dell'operazione batch con una transazione globale. Tale transazione globale è gestita da LREE. Le caratteristiche della transazione, come ad esempio il timeout della transazione o l'intervallo di commit, sono controllate dall'algoritmo del punto di controllo associato a un processo batch a cui appartiene l'operazione.
Di seguito sono riportati i metodi di richiamata LREE su BatchJobStepLocalInterface
che vengono richiamati da LREE nell'ordine riportato:
- setProperties(java.util.Properties properties) - rende le proprietà definite in xJCL disponibili per l'operazione batch in un oggetto java.util.Properties.
Questo metodo verrà richiamato con una transazione globale.
- void createJobStep() - indica all'operazione che è stata inizializzata. La logica di inizializzazione, come il richiamo di un handle su un flusso di dati batch, può essere inserita qui. Questo metodo verrà richiamato con una transazione globale.
- int processJobStep() - richiamato più volte da LREE in un loop batch
fino a che l'intero del codice di ritorno di questo metodo indica che l'operazione ha terminato l'elaborazione. Fare riferimento a BatchConstants nell'API batch per visualizzare i codici di ritorno che possono essere restituiti. Un codice di ritorno di BatchConstants.STEP_CONTINUE
segnala a LREE che può continuare a richiamare questo metodo nel loop batch. Un codice di ritorno BatchConstants.STEP_COMPLETE indica a LREE
che l'operazione è terminata e che viene quindi richiamato destroyJobStep.
- int destroyJobStep() - indica l'operazione che è stata completata.
Il codice di ritorno intero di questo metodo è del tutto arbitrario e può essere scelto dallo sviluppatore dell'applicazione batch. Questo codice di ritorno viene salvato nel database LREE
e rappresenta il codice i ritorno dell'operazione batch. Se l'algoritmo dei risultati è associato al processo batch, il codice di ritorno lo inoltrerà ad esso. Se esiste una logica condizionale basata sul codice di ritorno nell'xJCL del processo batch, il LREE utilizzerà questo codice per valutare la logica.
Il metodo getProperties() su BatchJobStepLocalInterface
non viene richiamato da LREE. Esso è incluso nell'interfaccia per la simmetria e per un possibile uso futuro.
Risoluzione dei problemi relativi allo sviluppo batch
- Il descrittore di distribuzione del bean del controller batch deve essere dichiarato nel descrittore di distribuzione EJB di un'applicazione batch e deve avere i riferimenti EJB locali agli EJB dell'operazione utilizzati in un'applicazione batch. È possibile definire soltanto un bean di controller per applicazione batch.
- Gli attributi delle transazioni di tutti i metodi delle operazioni batch devono essere impostato su richiesto.
- Lo sviluppatore dell'applicazione batch deve verificare che il lavoro transazionale eseguito all'interno dei metodi di richiamata dell'operazione batch ereditino la transazione globale avviata da LREE. Ciò assicura che il lavoro eseguito in un'operazione batch venga commesso a ogni punto di controllo e ne venga eseguito il rollback nel caso in cui l'operazione rilevi una condizione di errore.
- Se l'operazione batch utilizza un flusso di dati batch (batch data stream, BDS) i cui dati sono locale al file system del server delle applicazioni su cui è distribuita l'applicazione batch, allora è importante effettuare determinate operazioni per supportare gli scenari di riavvio dei processi. Se una applicazione batch del genere viene distribuita sul server delle applicazioni che vengono eseguite su più macchine, ad esempio quando viene distribuita su un cluster dinamico presente in un gruppo di nodi che ha più membri, e un processo batch eseguito rispetto a tale applicazione viene annullato e quindi riavviato, allora non esiste alcuna garanzia che la richiesta originale arrivi alla macchina su cui era stato eseguito originariamente
il processo batch. Se una applicazione batch del genere viene distribuita su un cluster dinamico presente in un gruppo di nodi che ha più membri, e un processo batch eseguito rispetto a tale applicazione viene annullato e quindi riavviato, allora non esiste alcuna garanzia che la richiesta originale arrivi alla stessa macchina. In questo scenario, la gestione a lunga durata potrebbe inviare la richiesta di riavvio a un server delle applicazioni che viene eseguito su una macchina differente. Pertanto, nei casi in cui è richiesta l'affinità basata su file, le seguenti soluzioni possono essere applicate per supportare lo scenario di riavvio del processo:
- Verificare che i dati siano ugualmente disponibili su ogni macchina su cui l'applicazione batch può essere avviata. Ad esempio, mediante un file system
di rete (ciò potrebbe infatti ridurre le prestazioni dell'applicazione).
- Distribuire l'applicazione sui server delle applicazioni che sono attivi solo sulla macchina su cui sono presenti i dati locali. Ciò è possibile distribuendo l'applicazione su un cluster dinamico che esiste nel gruppo di nodi che ha solo un nodo del membro.