Gestionnaire de travaux parallèles
Le gestionnaire de travaux parallèles offre une fonction et une structure permettant de soumettre et gérer des travaux par lots transactionnels qui s'exécutent en tant que collection coordonnée de travaux subordonnés parallèles indépendants.
Notions PJM élémentaires
- Le gestionnaire de travaux parallèles réside dans le conteneur de lots et non pas dans une application système distincte.
- Un seul fichier xJCL est requis. Le fichier xJCL associe le contenu du xJCL du travail de niveau supérieur au contenu des xJCL des travaux subordonnés.
- Vous n'avez pas besoin de créer une base de données séparée.
- Etant donné que le gestionnaire de travaux parallèles fait partie du conteneur de lots, vous n'avez pas besoin de l'installer et de le configurer.
- Vous regroupez les API de gestionnaire de travaux parallèles dans l'application par lots en tant que fichier Java™JAR d'utilitaire. Aucune bibliothèque partagée n'est requise.
- Le contenu du fichier xd.spi.properties fait partie du xJCL. Aucun fichier xd.spi.properties n'est requis.
Fonctionnement du gestionnaire de travaux parallèles et appel des API
Les deux images suivantes illustrent l'architecture du gestionnaire de travaux parallèles et la séquence d'un travail parallèle. Pour commencer, le xJCL est soumis au planificateur de travaux. Le planificateur de travaux transmet le xJCL à un noeud final qui exécute l'application référencée par le xJCL. Le conteneur de lots détermine que des travaux subordonnés devront s'exécuter en parallèle pour le travail lorsqu'il contrôle la propriété d'exécution du travail dans le fichier xJCL. Le conteneur de lots délègue l'exécution au sous-composant du gestionnaire de travaux parallèles. Le gestionnaire de travaux parallèles appelle l'API de paramétrage et utilise les informations du xJCL pour faciliter le fractionnement du travail en travaux subordonnés. Le gestionnaire de travaux parallèles appelle ensuite l'API de synchronisation LogicalTX pour indiquer le début de la transaction logique. Le gestionnaire de travaux parallèles génère les JCL des travaux subordonnés et soumet ces derniers au planificateur de travaux. Le planificateur de travaux transmet les travaux subordonnés aux noeuds finaux du conteneur de lots de sorte qu'ils puissent s'exécuter. Le conteneur de lots exécute les travaux subordonnés. Lorsqu'un point de contrôle est pris, l'API de collecte de travaux subordonnés est appelée. Cette API collecte les informations d'état pertinentes sur les travaux subordonnés. Ces données sont envoyées à l'API d'analyse de travaux subordonnés pour interprétation. Une fois que tous les travaux subordonnés ont atteint un état final, les API beforeCompletion et afterCompletion sont appelées. L'API d'analyse est également appelée pour calculer le code retour du travail.
Une transaction logique est une démarcation d'unité de travail qui étend l'exécution d'un travail parallèle. Son cycle de vie correspond au cycle de vie combiné des travaux subordonnés du travail parallèle. Grâce à un mécanisme d'extension, vous pouvez personnaliser des ressources gérées par une application de sorte qu'elles puissent être contrôlés dans cette unité de portée de travail à des fins de validation et d'annulation.
Architecture et modèle de programmation du gestionnaire de travaux parallèles
L'image suivante récapitule l'architecture de gestionnaire de travaux parallèles, qui indique où sont appelées les API :

Séquence d'un travail parallèle
L'image suivante affiche l'ordre des événements dans un travail parallèle :

Gestion de travaux par un gestionnaire de travaux parallèles
- Si tous les travaux subordonnés se terminent avec l'état de fin, autrement dit, s'ils sont correctement exécutés, le travail de niveau supérieur se termine avec l'état de fin.
- Si l'un des travaux subordonnés se termine avec l'état redémarrable et qu'aucun d'entre eux ne se termine avec l'état d'échec, le travail de niveau supérieur se termine avec l'état redémarrable.
- Si l'un des travaux subordonnés se termine avec l'état d'échec, le travail de niveau supérieur se termine avec l'état d'échec.
- Si le travail de niveau supérieur et les travaux subordonnés sont à l'état redémarrable, redémarrez uniquement le travail de niveau supérieur. Si vous redémarrez manuellement l'un des travaux subordonnés, le travail de niveau supérieur ne traite pas la transaction logique correctement.