Les différentes tâches d'une application par lots peuvent être divisées en étapes. Les étapes sont implémentées sous la forme d'EJB locaux gérés par conteneur qui spécifientcom.ibm.websphere.batch.BatchJobStepLocalInterface comme l'interface métier.
Les méthodes de rappel de l'interface BatchJobStepLocalInterface permettent à l'environnement LREE
(Long-Running Execution Environment) d'exécuter les étapes du travail par lots lors du traitement d'un travail.
L'EJB d'une étape de travail par lots contient la logique métier nécessaire pour exécuter une partie du travail par lots. En règle générale, l'étape d'un travail par lots contient le code requis pour lire un enregistrement dans le flux de données par lots (BDS), effectuer la logique métier avec cet enregistrement, puis continuer en lisant l'enregistrement suivant. La méthode processJobStep d'un EJB de l'étape du travail par lots est appelée par l'environnement LREE dans une boucle par lots. Cette méthode doit contenir toute la logique traitée par lots pour prendre en charge les données.
L'environnement LREE appelle les méthodes de l'EJB d'une étape du travail par lots lors d'une transaction globale. Cette transaction globale
est gérée par l'environnement LREE. Le comportement de la transaction, tel que le délai d'expiration ou l'intervalle de validation de la transaction, est contrôlé par l'algorithme de point de contrôle associé au travail par lots auquel l'étape appartient.
Les informations ci-après représentent les méthodes de rappel de l'environnement LREE disponibles dans l'interface BatchJobStepLocalInterface et appelées dans l'ordre indiqué :
- setProperties(java.util.Properties properties) : Met les propriétés
définies dans le document xJCL à la disposition de l'étape du travail par lots dans un objet java.util.Properties.
Cette méthode est appelée lors d'une transaction globale.
- void createJobStep() : Indique à l'étape du travail par lots qu'elle a été initialisée. La logique d'initialisation, telle que l'extraction d'un descripteur destiné à un flux de données par lots, peut être placée ici. Cette méthode est appelée lors d'une transaction globale.
- int processJobStep() : Méthode appelée régulièrement par l'environnement LREE dans une boucle de traitement par lots jusqu'à ce que l'entier du code retour de cette méthode indique que l'étape est terminée. Reportez-vous à BatchConstants dans l'API de traitement par lots pour identifier les codes retour qui peuvent être renvoyées. Le code retour BatchConstants.STEP_CONTINUE indique à l'environnement LREE qu'il doit continuer à appeler cette méthode dans la boucle de traitement par lots. Le code retour de BatchConstants.STEP_COMPLETE indique à l'environnement LREE que l'étape est terminée et qu'il appelle à présent destroyJobStep.
- int destroyJobStep() : Indique à l'étape qu'elle est terminée.
Le code retour (entier) de cette méthode est totalement arbitraire et peut être choisi par le développeur de l'application par lots. Il est sauvegardé dans la base de données LREE et représente le code retour de l'étape du travail par lots. Si un algorithme de résultats est associé au travail par lots, ce code retour lui est transmis. Si un code retour est défini en fonction de la logique conditionnelle dans le document
xJCL du travail par lots, l'environnement LREE l'utilise pour évaluer cette logique.
La méthode getProperties() de l'interface BatchJobStepLocalInterface
n'est pas actuellement appelée par l'environnement LREE. Elle est incluse dans l'interface pour assurer une symétrie et permettre une utilisation ultérieure éventuelle.
Identification et résolution des incidents lors du développement par lots
- Le descripteur de déploiement du bean chargé de contrôler la procédure par lots doit être déclaré dans le descripteur de déploiement de l'EJB d'une application par lots et doit comporter des références locales aux EJB de l'étape du travail par lots utilisés dans l'application. Un seul bean contrôleur peut être défini par application par lots.
- Les attributs de transaction de toutes les méthodes de l'étape doivent être obligatoires.
- Le développeur de l'application par lots doit s'assurer que les tâches transactionnelles effectuées dans les méthodes de rappel de l'étape héritent de la transaction globale lancée par l'environnement LREE. Cela permet de s'assurer que les tâches effectuées lors de l'étape du travail par lots
sont uniquement validées à chaque point de contrôle et annulées lorsque l'étape échoue.
- Si l'étape du travail par lots utilise un flux de données BDS (Batch Data Stream) dont les données se trouvent en local sur le système de fichiers du serveur d'applications où l'application est déployée, il est nécessaire de prendre un certain nombre de mesures pour prendre en charge les scénarios de redémarrage des travaux. Si ce type d'application par lots est déployé sur des serveurs d'applications exécutés sur plusieurs systèmes, par exemple sur le cluster dynamique d'un groupe de noeuds comprenant plusieurs membres, et que le travail par lots qui s'exécute dans cette application est annulé, puis redémarré, la demande de redémarrage n'est pas forcément adressée au système où le travail par lots a été initialement exécuté. Si une application par lots est déployée sur un cluster dynamique d'un groupe de noeuds comprenant plusieurs membres, et qu'un travail par lots qui s'exécute dans cette application est annulé, puis redémarré, la demande de redémarrage n'est pas forcément adressée au même système. Dans ce scénario, il est possible que la demande de redémarrage soit envoyée à un serveur d'applications exécuté sur un autre système. Dans les cas où l'affinité par fichier est nécessaire, les solutions suivantes peuvent être appliquées pour prendre en charge le redémarrage du travail :
- Assurez-vous que les données sont toutes disponibles sur chaque système où l'application par lots peut être lancée. Par exemple, à l'aide d'un système de fichier réseau (risque de réduction des performances de l'application).
- Déployez l'application sur des serveurs d'applications qui peuvent uniquement fonctionner sur le système où se trouvent les données locales. Pour effectuer cette opération, déployez l'application sur un cluster dynamique d'un groupe de noeuds comportant un seul membre.