Spécifier le mot-clé “batch” permet d'appeler l'interface de traitement par lot de la CLI. Dans ce cas, la CLI attend un nom de fichier (nomfichier) séparé par au moins un espace du mot-clé “batch”. Ce nom de fichier peut être un nom de fichier absolu ou relatif. Il identifie un fichier contenant une liste des commandes de CLI qui doivent être exécutées par cet appel.
La CLI traite le fichier de commandes comme suit. Elle commence par établir une session avec le gestionnaire spécifié (par exemple un gestionnaire par défaut), pour l'utilisateur spécifié (voir connexion). Ensuite, elle lit le fichier de commandes ligne par ligne. Une ligne dans un fichier de commandes peut contenir plusieurs commandes. Par contre, une commande ne peut pas s'étendre au-delà d'une ligne. Pour des raisons de lisibilité, il est conseillé de coder une commande par ligne. La CLI lit le fichier depuis le début, jusqu'à ce qu'elle identifie la commande CLI suivante ou qu'elle atteigne la fin du fichier, en fonction de ce qu'elle rencontre en premier. Cette lecture des informations (sans la commande possible identifiée à la fin) est interprétée comme une commande CLI avec ses définitions de paramètres et est exécutée.
Après une exécution complète réussie, la recherche de la commande ou fin de fichier suivante se poursuit et la commande analysée est également exécutée. La lecture continue ainsi jusqu'à ce qu'une erreur se produise ou que la fin du fichier soit atteinte. L'exemple suivant illustre le contenu d'un fichier de commandes :
regsw -item=prod_1 -version=1.0 -path=/products/prod_1 ~procedures=/products/proc_1 regsw -item=prod_2 -version=1.1 -path=/products/prod_2 ~procedures=/products/proc_2
Ce fichier de commandes enregistre deux produits dans SD. La CLI analyse d'abord le fichier jusqu'à ce qu'elle trouve la seconde commande regsw, puis traite la commande regsw pour prod_1 avec les paramètres item, version, path et procedures. Si l'exécution se termine avec succès, elle analyse alors le reste du fichier jusqu'à la fin et traite également la seconde commande regsw. Si l'exécution de la première commande regsw échoue, la seconde n'est pas exécutée et la CLI s'arrête.
Il est possible d'ajouter des commentaires à un fichier de commandes à des fins de documentation. Les commentaires sont indiqués par le symbole dièse #. Tout ce qui suit un symbole dièse jusqu'à la fin d'une ligne est considéré comme un commentaire par la CLI, qui l'ignore. Vu sa signification particulière, évitez d'utiliser “#” dans les définitions de paramètre. Il peut cependant arriver qu'un paramètre contienne un symbole dièse. Le cas échéant, entourez la valeur du paramètre de guillemets pour empêcher la CLI d'interpréter le symbole comme un début de commentaire. Ainsi, le contenu du fichier ci-dessus pourrait également se transformer en cet exemple :
# Enregistrer le produit 1 regsw -item=prod_1 -version=1.0 -path=/products/prod_1 ~procedures=/products/proc_1 -comment=”produit_1 pour département #1” # Enregistrer le produit 2 regsw -item=prod_2 -version=1.1 -path=/products/prod_2 ~procedures=/products/proc_2 -comment=”produit_2 pour département #100”
Au passage, notez que les valeurs de paramètre contenant le symbole “#” ne sont pas les seules qui doivent être mises entre guillemets. C'est également le cas des valeurs contenant des espaces vides.
Dans les exemples ci-dessus, les paramètres sont précédés d'un tiret “-“. Il est recommandé d'indiquer les paramètres de cette manière, mais ce n'est pas une obligation. Quoiqu'il en soit, dans le cas de paramètres ambigus susceptibles d'être confondus avec une commande, utilisez le tiret. “stagingServer” est un tel paramètre : c'est en effet une commande CLI également.
Comme précisé plus haut, la CLI arrête normalement le traitement par lot lorsque l'exécution d'une commande échoue. Il peut cependant arriver que les commandes d'un fichier de commandes soient indépendantes les unes des autres. Dans l'exemple ci-dessus, par exemple, les produits prod_1 et prod_2 peuvent être indépendants. Par conséquent, si l'enregistrement de prod_1 échoue, cela n'a aucun impact sur l'enregistrement de prod_2 et donc le produit prod_2 pourrait quand même être enregistré. En définissant la variable d'environnement
set SDCMD_CONTINUE=ON (Windows)
export SDCMD_CONTINUE=ON (Linux, bash)
il est possible de forcer la CLI à ignorer les échecs et à poursuivre le traitement avec la commande suivante du fichier. Si ces variables sont définies, la CLI essaie d'enregistrer prod_2 même si l'enregistrement de prod_1 échoue.
La CLI enregistre les commandes traitées et la sortie obtenue par les commandes dans stdout. Cette sortie peut facilement être redirigée vers un fichier pour être analysée par un autre script. En ce qui concerne l'exemple
002 regsw “item=prod_1” “version=1.0” “path=/products/prod_1” “procedures=/products/proc_1” “comment=product_1 for department #1” Commande traitée... SDCMD<A000000> : OK 004 regsw “item=prod_2” “version=1.1” “path=/products/prod_2” “procedures=/products/proc_2” “comment=product_2 for department #100” Commande traitée... SDCMD<A000000> : OK
La CLI enregistre les commandes lues et les définitions des paramètres telles que la CLI les a interprétées. Le numéro figurant au début de la commande indique la ligne du fichier de commandes ou cette commande a été détectée.
Toutes les commandes valides de la CLI sont disponibles depuis l'interface de traitement par lot.
|
Copyright © 2013 CA.
Tous droits réservés.
|
|