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.
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
<checkpoint-algorithm-ref name="${checkpoint}" />
<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.
- ${was.install.root}
- ${user.install.root}
- ${agent.home}