Eléments xJCL

Les travaux sont exprimés en utilisant un dialecte Extensible Markup Language XML appelé xJCL (XML Job Control Language). xJCL propose des constructions pour définir toutes les informations nécessaires aux travaux à traitement intensif ou par lots, bien que certains éléments du langage soient applicables uniquement à l'une ou à l'autre de ces catégories de travaux. Pour plus d'informations sur xJCL, reportez-vous aux données xJCL fournies avec les exemples d'applications et le document de schéma XSD xJCL. La définition xJCL d'un travail ne fait pas partie de l'application de traitement par lots, mais elle est construite séparément et soumise au planificateur de travaux. Le planificateur de travaux utilise les informations fournies dans xJCL pour déterminer où et quand exécuter le travail.

Eléments xJCL

Le tableau suivant résume les éléments xJCL.

Tableau 1. Eléments xJCL. Le tableau inclut des éléments xJCL, que chaque élément xJCL s'applique à des travaux par lots ou de calcul intensif Java™ Platform, Enterprise Edition (Java EE) et des sous-éléments, des attributs et des descriptions pour chaque élément xJCL.
Elément A calcul intensif Java EE Traitement par lots Java EE Sous-élément Attributs Description
job oui oui     S'applique à la description d'un travail par lots
job oui oui   Nom Nom du travail. Le nom doit être le même que pour application de traitement par lotssauf si default-application-name est indiqué.
job oui oui   comptabilité Attribut d'informations d'utilisation facultatif
job oui oui   class Attribut de classe de travail facultatif qui identifie la classe de travail sous laquelle le travail est exécuté.
job oui oui   default-application-name Nom de l'application à utiliser lorsqu'aucun attribut application-name n'est trouvé pour l'étape de travail.

Nom de l'application à utiliser. Pour les applications par lots OSGi, nommez le travail de la manière suivante : osgi:<nom eba>:<version>.

job oui oui jndi-name   Nom JNDI attribué au bean session sans état chargé de contrôler le travail lorsque l'application de traitement par lots est déployée dans le produit.
job oui oui job-scheduling-criteria required-capability Attribut required-capability d'un travail qui doit être défini sur un noeud final pour le travail à distribuer vers ce dernier.
job oui oui step-scheduling-criteria Voir l'élément step-scheduling-criteria  
job non oui algorithme de point de contrôle Voir l'élément checkpoint-algorithm  
job non oui results-algorithm Voir l'élément d'algorithmes de résultats  
job oui oui substitution-props++ Voir l'élément prop. Attribut required-capability d'un travail qui doit être défini sur un noeud final pour le travail à distribuer vers ce dernier.
job-step oui* oui   Nom Nom facultatif de l'étape. Cette information est renvoyée dans les commandes d'exécution.
job-step oui* oui   application-name Nom facultatif de l'application exécutée par l'étape. Le nom d'attribut est utilisé si l'attribut application-name est omis, de même que l'attribut default-application-name de niveau travail.
job-step non oui step-scheduling Voir l'élément step-scheduling Permet une logique conditionnelle basée sur les codes retour des étapes pour déterminer si l'étape de la procédure par lots est appelée.
job-step oui oui classname   Nom complet de la classe qui implémente le travail à traitement intensif.
job-step oui non checkpoint-algorithm-ref   Spécifie l'algorithme de point de contrôle à utiliser pour l'étape du travail par lots.
job-step non oui results-ref Voir l'élément results-ref Indique l'algorithme de résultats à utiliser pour l'exécution de l'étape de travail par lots conditionnel.
job-step non oui batch-data-streams Voir l'élément batch-data-streams Séquence d'éléments bds. Chaque élément bds correspond aux informations de configuration nécessaires pour créer un flux de travaux par lots (BDS).
job-step oui oui props Voir l'élément props Propriétés nom-valeur à transmettre à l'étape
job-step non non exec Voir l'élément exec Identifie l'exécutable associé à l'étape de travail.
job-step non non env-entries Voir l'élément env-entries Identifie les propriétés d'environnement associées à l'étape de travail.
prop oui oui     Instance unique d'une paire nom-valeur utilisée comme propriété.
prop oui oui   Nom Nom de la propriété.
prop oui oui   valeur Valeur de la propriété.
props oui oui prop Voir l'élément prop.  
env-entries non non     Série d'éléments prop utilisés pour envoyer des propriétés de paire nom/valeur à des étapes, bd, algorithmes de point de vérification et algorithmes de résultat.
env-entries non non env-var Voir l'élément env-var  
exec non non     Série d'éléments prop utilisés pour envoyer des propriétés de paire nom/valeur à des étapes, bd, algorithmes de point de vérification et algorithmes de résultat.
exec non non   executable Nom de l'exécutable associé à l'étape de travail
exec non non arg Voir l'élément line  
line non non     Arguments de ligne de commande passés à l'exécutable d'étape de travail.
bds non oui     Instance unique d'une implémentation de flux de données par lots mise à la disposition d'un travail par lots.
bds non oui logical-name   Chaîne imbriquée dans l'étape du travail par lots, que cette étape utilise pour demander à l'environnement d'exécution une instance de flux de données par lots spécifique.
bds non oui impl-class   Nom complet de la classe d'implémentation du flux de données par lots
bds non oui props Voir les éléments props. Liste des propriétés transmises à la classe d'implémentation du flux de données par lots
batch-data-streams non oui     Série d'éléments bds.
batch-data-streams non oui bds Voir l'élément bds  
step-scheduling non oui     S'applique aux étapes du travail pour créer des flux conditionnels basés sur le code retour. L'élément step-scheduling peut comparer les valeurs des codes retour définies pour ce travail par lots pour déterminer si une étape doit être appelée lors du traitement d'un travail par lots. Les valeurs des codes retour sont comparées à l'aide de l'élément returncode-expression.
step-scheduling non oui returncode- expression Voir returncode-expression returncode-expression à évaluer.
step-scheduling non oui   condition S'il existe plusieurs éléments returncode-expression dans l'élément step-scheduling, des opérateurs conditionnels leur sont appliqués. Les opérateurs conditionnels pris en charge sont AND et OR.
returncode-expression non oui     Utilisé sous les balises step-scheduling pour déterminer si une étape d'un travail par lots s'exécute en fonction des codes retour d'autres étapes du travail.
returncode-expression non oui   step Nom de l'étape dont le code retour doit être comparé dans cette expression.
returncode-expression non oui   opérateur Opérateur à utiliser pour l'expression de code retour. Les opérateurs pris en charge sont eq pour égal, lt pour inférieur à, gt pour supérieur à, le pour inférieur ou égal à et ge pour supérieur ou égal à.
returncode-expression non oui   valeur Valeur utilisée pour comparer le code retour.
step-scheduling-criteria non oui     Décrit la séquence de traitement des étapes du travail. La planification séquentielle est actuellement prise en charge ; par exemple, les étapes sont appelées dans l'ordre dans lequel elles sont dans le document xJCL.
step-scheduling-criteria non oui scheduling-mode   Ordre dans lequel les étapes sont appelées. La seule valeur autorisée actuellement est sequential.
checkpoint-algorithm non oui     Déclare un algorithme de point de contrôle qui peut être utilisé pour l'étape d'un travail par lots.
checkpoint-algorithm non oui   Nom Nom de l'algorithme.
checkpoint-algorithm non oui classname   Classe qui implémente cet algorithme.
checkpoint-algorithm non oui props Voir l'élément props Série d'éléments prop pour l'algorithme de point de contrôle.
checkpoint-algorithm-ref non oui     Référence à un élément de l'algorithme de point de contrôle.
checkpoint-algorithm-ref non oui   Nom Nom de l'algorithme de point de contrôle auquel il est fait référence.
checkpoint-algorithm-ref non oui props Voir Elément props Série d'éléments prop pour l'algorithme de point de contrôle.

++ L'élément xJCL substitution-props est décrit dans la section suivante.

Elément xJCL substitution-props

L'élément xJCL de travail peut contenir des variables symboliques. Une variable symbolique est une expression sous la forme ${nom-variable) qui se trouve en dehors d'un commentaire dans un document par ailleurs syntaxiquement correct. Exemple :
<checkpoint-algorithm-ref name="${checkpoint}" />
L'élément xJCL substitution-props définit un nom par défaut et des paires de valeurs pour les variables symboliques. Voici un exemple d'élément substitution-props, extrait du document postingSampleXJCL.xml :
<substitution-props>
<prop name="wsbatch.count" value="5" /> 
<prop name="checkpoint" value="timebased" />
<prop name="checkpointInterval" value="15" />
<prop name="postingsDataStream" value="${was.install.root}${file.separator}temp${file.separator}postings" />
</substitution-props>

Le remplacement des variables symboliques est effectué au moment de l'exécution. Au moment de l'exécution, la chaîne ${nom-variable} est remplacée par la valeur de la propriété lorsque le xJCL est soumis pour être exécuté. A l'aide des propriétés de l'exemple précédent, la chaîne ${checkpoint} est remplacée par la chaîne time-based avant la soumission du travail.

Les variables symboliques peuvent être indirectes. Par exemple : name=FILENAME value=${${filename}} utilisé avec la paire nom/valeur filename=postingsDataStream donne le même résultat que si vous indiquez name=FILENAME value=${postingsDataStream}.

Les variables symboliques peuvent également être composées. Par exemple, name=postingsDataStream value=${was.install.root}${file.separator}temp${file.separator}postings.

Il n'est pas nécessaire de définir des paires nom-valeur dans l'élément substitution-props du document du travail. Les paires nom-valeur props définies dans l'élément substitution-props sont des valeurs par défaut pour les variables nommées. Si elles ne sont pas définies dans l'élément substitution-props, les paires nom-valeur doivent être transmises via les API du planificateur de travaux lorsque le travail est soumis ou défini dans les propriétés du système pour le JVM. Chaque variable symbolique définie dans le corps d'un document de travail doit être résolue pour le xJCL afin d'être considérée comme valide. Chaque paire nom-valeur définie dans le document du travail doit être résolue en variable symbolique figurant dans le corps du xJCL pour que le xJCL soit considéré comme étant valide.

Si les paires nom-valeur sont à la fois définies dans le document xJCL et transmises aux API du gestionnaire des travaux au moment de la soumission, les paires nom-valeur transmises via les API du gestionnaire de travaux remplacent les valeurs définies dans le document xJCL. Si les paires nom-valeur ne sont pas transmises via les API du gestionnaire de travaux ni définies comme valeurs par défaut dans le document xJCL, les paires nom-valeur correspondant aux variables symboliques doivent être définies dans les propriétés système JVM pour le xJCL afin d'être considérées comme étant valides.

Les variables symboliques sont résolues par le gestionnaire de travaux avant la soumission des travaux, à l'exception des variables spéciales suivantes qui sont résolues au niveau du noeud final de grille. Toutes les variables spéciales suivantes doivent être définies en tant que propriétés système JVM. Ces variables sont les suivantes :
  • ${was.install.root}
  • ${user.install.root}
  • ${agent.home}

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cgrid_xdbatchjcl
Nom du fichier : cgrid_xdbatchjcl.html