Formules VTOM

Je rassemble ici un recueil des formules VTOM qui valent le coup d’oeil.

Attention, une formule VTOM dépend du calendrier sur lequel elle s’appuie. (jours fériés et jour chômés)

Veille du premier jour ouvre mois : By Fred

test{(aujourd'hui=1.jour.ouvr.mois-1.jour.cale) ou (aujourd'hui=dern.jour.cale.mois+1.jour.ouvr-1.jour.cale)}

Premier Lundi du mois s’il est ouvré, sinon le jour ouvré qui suit

test { (aujourd'hui=prem.lu.cale.mois et aujourd'hui=ouvr) ou (prem.lu.cale.mois=chom et aujourd'hui=prem.lu.cale.mois+1.jour et aujourd'hui=ouvr) }

version corrigée par Hervé G.

test { (aujourd'hui=prem.lu.cale.mois et aujourd'hui=ouvr) ou (prem.lu.cale.mois=chom et aujourd'hui=prem.lu.cale.mois+1.jour.ouvr ) }
ou plus "simple"
test { aujourd'hui>=prem.lu.cale.mois et aujourd'hui=ouvr et aujourd'hui-1.jour.ouvre<prem.lu.cale.mois}

premier jour ouvré du mois sauf en Janvier, et dernier jour ouvré de Décembre :

test{
(aujourd'hui = prem.jour.ouvr.mois et aujourd'hui <> janvier)
ou
(aujourd'hui = dern.jour.ouvr.annee)
}

les lendemains de jour ouvré avec les dimanches chomés et les jours fériés de france. Calendrier = Dimanche chômés + jours fériés France

test{
 aujourd'hui - 1.jour.cale = ouvr
}

2ème dimanche du mois

 test{ aujourd'hui = 2.di.cale.mois }

(voir plus) Formules VTOM

30-05-2016

Date d'exploitation VTOM ne bascule pas

Les outils pour débugger une date bloquée :
- Vérifier ce qui bloque la date : tchkdate /nom=<nom date> (ou pour avoir un rapide coup d’oeil sur l’état des dates : tlist date -v
- Analyse/Historique : rechercher sur la date pour voir quand et par quel moteur elle a basculé
Pour rappel, une date commune à plusieurs environnements n’est vraiment pas recommandée.

Deux exemples de problèmes :
- Des jobs de l’environnement A avec une date A sont à venir et attendent indéfiniment des ressources (pour x ou y raison)
  - la date ne basculera pas à J+1
  - les jobs de l’environnement B avec la date A resteront bloqués à leur état tant que la date ne basculera pas
- A l’inverse, et au hasard, ça sera le premier moteur, A ou B, qui fera basculer la date A à J+1 (pour peu que tous les jobs liés à cette date soient statués)
  - à J+1 le moteur qui n’aura pas fait basculer la date ne fera pas de treset (mise AVENIR) des jobs liés à cette date. Résultat, vous aurez des jobs à l’état TERMINE (par exemple) avec la date au 25/05 alors qu’ils n’ont tourné que, et seulement que, le 24/05
Une petite astuce pour lister les dates d’exploitation VTOM se retrouvant sur plusieurs jobs de différents environnements. (attention à bien désallouer une date affectée à un environnement non approprié mais à auncune app/job)
```
$ tlist env/date | sort -k"2,2" | awk '{print $2}'| uniq -c | awk '$1 > 1'

$  tlist jobs | sort -u -k"5,5" -k"1,1" | awk '{print $5}' | uniq -c | awk '$1 > 1'
   2 datey
   2 datex
```
Attention aussi aux dates d’exploitation différentes au sein d’un même bloc d’applications (liées entre elles). C’est possible d’avoir des dates différentes (hebdo, mensuelle par ex.) mais il faut savoir ce qu’on fait.

De base, je dirais qu’un bloc d’application devrait avoir la même date d’exploitation (attention aux copiés/collés surtout).

Petit astuce pour les lister :
```
vi env_app_date.sql
.separator /
select e.NAME, a.NAME, d.NAME
from applications a
left join environments e on a.ENV_SID = e.ENV_SID
left join dates d on a.DATE_SID = d.DATE_SID or (ifnull(a.DATE_SID,'') = '' and e.DATE_SID = d.DATE_SID)
;

vtexport -x > vtexport.xml
vthttpd -dump vthttpd.dat
sqlite3 vthttpd.dat < env_app_date.sql > apps_dateexp.txt

while read line
do 
  parent_dateexp=$(egrep "^`echo $line | cut -f1 -d" "`/" apps_dateexp.txt | cut -f3 -d"/");
  child_dateexp=$(egrep "^`echo $line | cut -f2 -d" "`/" apps_dateexp.txt | cut -f3 -d"/") ;
  if test "$child_dateexp" != "$parent_dateexp"
  then
    echo $line $parent_dateexp $child_dateexp
  fi
done < <(sed -e 's|^[        ]*<Link parent="$[^"/]*/[^"/]*$" child="$[^"]*$".*$|\1 \2|g' -e 'tx' -e 'd' -e ':x' vtexport.xml)
```
Platform.sh premières impressions

Avec platform.sh, Orange Cloud for Business nous promet pour nos applications Web :
- un PaaS performant et sécurisé (datacenters situés en France)
- jusqu’a 25% d’économies sur les couts de développements et sur le DevOps
- de permettre aux developpeurs de se concentrer sur le code et non sur la gestion du systeme
- de simplifier au maximum les workflow jusqu’à la livraison du projet
A premiere vue, c’est tres orienté Web et comme il y a un free trial de 30 jours, je vais tester ça !

Comment ça fonctionne ?

Quelques liens vers les white papers et case studies :
- Introduction
- Data Sheet
Ce qu’on pourrait retenir :
- utilise principalement le mécanisme de Git :
  - permet le versioning
  - permet la livraison entre les différents environnements avec le merging
  - permet aux équipes une meilleure communication et moins de documentation a produire (il suffit de voir les différences entre les différentes versions dans l’outil directement)
- fonctionne avec des micro-services comme conteneurs linux LXC (un peu comme Docker)
  - il suffit de référencer les services dans des fichiers de configuration (comme mysql, postgres, etc)
- basiquement, on n’a besoin que de trois fichiers pour initier notre environnement : .platform-app-yaml.html + .platform/services.yaml + .platform/routes.yaml
- l’ensemble .platform-app-yaml.html + .platform/services.yaml ressemble fortement a ce qu’on pourrait faire avec docker-compose
Rentrons dans le vif du sujet, et voyons si ça vaut le coup de s’intéresser a platform.sh.

Exemple : application simple - bonjour

L’administration des projets sur platform.sh

Je dois avouer que tout est pensé pour simplifier au maximum les actions et les configurations.

Je trouve l’interface plutôt sympathique et tres fonctionnelle.

En 4 clics, j’ai créé mon free trial account, créé mon projet “Demo Dev” avec sa branche “master” et sa branche “n-1” (pour la version n-1 par exemple). Je peux presque commencer a écrire ou déployer mon code.

Installer platform CLI pour une meilleure gestion des projets et environnements

Mais d’abord, j’installe mon environnement de dev. Je run mon image Docker Dev mais n’importe quel OS avec Git, php et vos outils de dev devrait suffire.

J’installe platform CLI
```
# install
curl -sS https://platform.sh/cli/installer | php

# configuration
# et je rentre mes informations de compte pour m'authentifier
platform
...

# Je configure mes clés ssh pour Git et acces ssh
platform ssh-keys
Your SSH keys are:
+-------+----------------------------+----------------------------------+
| ID    | Title                      | Fingerprint                      |
+-------+----------------------------+----------------------------------+
| 15718 | ssh-rsa AAAAB3NzaC1yc2EAAA | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
| 15721 | 26d53a922bbd               | xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx |
+-------+----------------------------+----------------------------------+

Add a new SSH key with: platform ssh-key:add
Delete an SSH key with: platform ssh-key:delete [id]

platform ssh-key:add
...
```
```
# Je clone mon projet sur la branch n-1
git clone git clone --branch n-1 nkoaolx5osnio@git.eu.platform.sh:nkoaolx5osnio.git demo-dev
...
```
```
# je regarde la configuration 
cd demo-dev
platform 
Welcome to Platform.sh!

Project title: Demo Dev
Project ID: nkoaolx5osnio
Project dashboard: https://eu.platform.sh/#/projects/nkoaolx5osnio

Your environments are:
+--------+--------+--------+
| ID     | Name   | Status |
+--------+--------+--------+
| master | Master | Active |
| n-1*   | n-1    | Active |
+--------+--------+--------+
* - Indicates the current environment

Check out a different environment by running platform checkout [id]
Branch a new environment by running platform environment:branch [new-name]
Make a snapshot of the current environment by running platform snapshot:create
Merge the current environment by running platform environment:merge
Sync the current environment by running platform environment:synchronize

You can list other projects by running platform projects

Manage your SSH keys by running platform ssh-keys

Type platform list to see all available commands.
```
Configuration de l’application : .platform-app-yaml.html + .platform/services.yaml + .platform/routes.yaml
Pour mon application “bonjour” :
```
|-- .git
|-- .platform
|   |-- local
|   |   |-- README.txt
|   |   `-- project.yaml
|   |-- routes.yaml
|   `-- services.yaml
|-- .platform.app.yaml
|-- index.php

index.php
<?php echo "bonjour" ; ?>

.platform.app.yaml
name: bonjour
type: php
disk: 128
web:
    document_root: "/"
    passthru: "/index.php"

.platform/routes.yaml
"http://{default}/":
    type: upstream
    upstream: "bonjour:php"

"http://www.{default}/":
    type: redirect
    to: "http://{default}/"

.platform/services.yaml
vide (pas de dépendance a d'autres services)
par défaut,  : 
mysql:
    type: mysql:5.5
    disk: 2048

redis:
    type: redis:2.8

solr:
    type: solr:3.6
    disk: 1024
```
mise a jour de l’environnement n-1

Il n’y a plus qu’a push ce qu’on a construit localement.
```
git add --all ; git commit -m "first app bonjour" ; git push
...
# on voit qu'il va plus loin qu'un simple push, il construit l'environnement et le lance comme conteneur (avec les instructions que j'ai défini dans les fichiers de configuration) 
```
Je teste et je merge sur la branch principale

platform.sh s’occupe de tout. Il créé meme une url par environnement et par projet.

Je vérifie que j’ai bien mon rendu d’appli “bonjour” sur version-projet.eu.platform.sh ==> OK !

Je merge l’environnement n-1 vers la branche master.

Et voila !

Autres applications

Il semblerait que les deux projets fournis de base soient Symfony ou Drupal pour le moment. J’ai testé deux minutes et ça semble fonctionner sans qu’on ne touche a rien.

Il n’y a plus qu’a intégrer ses Bundles et a coder.

Pour le reste, il me semble que les services proposés sont suffisants et demandent peu de configuration :
- PHP
- Python
- Ruby
- NodeJS
- Java (with integrated Maven and Ant support)
- Postgres, MySQL, Redis etc.
Conclusion

platform.sh est vraiment intéressant pour les équipes de développements d’applications web de moyenne a grande envergure.

Tous les concepts sont connus (Git, CaaS (container as service), répartition de charge du trafic automatique, automatisation des tâches avec Grunt ou maintien des dépendances de librairies avec Composer, etc).

Ca n’est donc pas une révolution. Cependant, la promesse de simplifier les actions d’administration semble tenue.

Une fois qu’on a bien compris le fonctionnement des trois fichiers de configuration - .platform-app-yaml.html + .platform/services.yaml + .platform/routes.yaml - on peut, effectivement, se concentrer sur le code et la gestion des workflows.

vtplan VTOM

vtplan - affiche la planification des applications ou traitements

# Comme on pourrait le voir dans VTOM (clique droit > planification)
vtom@9b99febd3506:/mnt/User/temp/install$ vtplan /filter TEST -a /format table /range "01-01-2016 31-12-2016"
[Du vendredi 1 janvier 2016 au samedi 31 decembre 2016 (366 jour(s))]

TEST/APP_1

    ANNEE 2016
    ==========

    J  F  M  A  M  J  J  A  S  O  N  D
---------------------------------------
 1  N  O  N  N  N  N  N  O  N  N  N  N
 2  N  N  N  N  O  N  N  N  N  N  N  N
 3  N  N  N  N  N  N  N  N  N  O  N  N
 4  O  N  N  O  N  N  O  N  N  N  N  N
 5  N  N  N  N  N  N  N  N  O  N  N  O
 6  N  N  N  N  N  O  N  N  N  N  N  N
 7  N  N  O  N  N  N  N  N  N  N  O  N
 8  N  N  N  N  N  N  N  N  N  N  N  N
 9  N  N  N  N  N  N  N  N  N  N  N  N
10  N  N  N  N  N  N  N  N  N  N  N  N
11  N  N  N  N  N  N  N  N  N  N  N  N
12  N  N  N  N  N  N  N  N  N  N  N  N
13  N  N  N  N  N  N  N  N  N  N  N  N
14  N  N  N  N  N  N  N  N  N  N  N  N
15  N  N  N  N  N  N  N  N  N  N  N  N
16  N  N  N  N  N  N  N  N  N  N  N  N
17  N  N  N  N  N  N  N  N  N  N  N  N
18  N  N  N  N  N  N  N  N  N  N  N  N
19  N  N  N  N  N  N  N  N  N  N  N  N
20  N  N  N  N  N  N  N  N  N  N  N  N
21  N  N  N  N  N  N  N  N  N  N  N  N
22  N  N  N  N  N  N  N  N  N  N  N  N
23  N  N  N  N  N  N  N  N  N  N  N  N
24  N  N  N  N  N  N  N  N  N  N  N  N
25  N  N  N  N  N  N  N  N  N  N  N  N
26  N  N  N  N  N  N  N  N  N  N  N  N
27  N  N  N  N  N  N  N  N  N  N  N  N
28  N  N  N  N  N  N  N  N  N  N  N  N
29  N  N  N  N  N  N  N  N  N  N  N  N
30  N  -  N  N  N  N  N  N  N  N  N  N
31  N  -  N  -  N  -  N  N  -  N  -  N

# Avec les dates
vtom@9b99febd3506:/mnt/User/temp/install$ vtplan /filter TEST -a /format date /range "01-01-2016 31-12-2016"
[Du vendredi 1 janvier 2016 au samedi 31 decembre 2016 (366 jour(s))]

TEST/APP_1
01-jan-2016 = NON
02-jan-2016 = NON
03-jan-2016 = NON
04-jan-2016 = OUI
05-jan-2016 = NON
06-jan-2016 = NON
07-jan-2016 = NON
08-jan-2016 = NON
09-jan-2016 = NON
10-jan-2016 = NON
11-jan-2016 = NON
12-jan-2016 = NON
13-jan-2016 = NON
14-jan-2016 = NON
15-jan-2016 = NON
16-jan-2016 = NON
17-jan-2016 = NON
18-jan-2016 = NON
19-jan-2016 = NON
20-jan-2016 = NON
21-jan-2016 = NON
22-jan-2016 = NON
... (tronqué)

# EN CSV
vtom@9b99febd3506:/mnt/User/temp/install$ vtplan /filter TEST -a /format csv /range "01-01-2016 31-12-2016"
[Du vendredi 1 janvier 2016 au samedi 31 decembre 2016 (366 jour(s))]
TEST;APP_1;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0

Priorité queue batch VTOM

<EDIT> Une option de priorité a été ajoutée depuis 5.7+ et se gère au niveau des objets Applications et Traitements. (case à cocher “Priorité” de 0 jusqu’à 127, 0 étant le moins prioritaire). Cette nouvelle fonctionnalité palie à la décision arbitraire du moteur de mettre tel ou tel job (ou application) à ENCOURS avant tel ou tel autre, mais ne remplace pas la priorité de la queue batch dans la file d’attente.

Problématique des gros environnements de production

Certains clients VTOM à forte charge d’ordonnancement voient leurs files d’attente saturées, et des traitements non prioritaires qui durent des heures bloquent le passage de traitements “rapides” (qui pourraient débloquer des chaînes bien plus prioritaires).

Priorité dans la file d’attente : principe

Tous les jobs dont le moteur a validé les contraintes (horaires, liens, ressources) passent à « EN COURS » dans VTOM selon un ordre propre au moteur. (ex. JOB_1 commence avant JOB_2 qui commence avant JOB_3 etc. quelque soit la priorité de vos queues).

« EN COURS » dans VTOM != d’en cours d’exécution sur le host.

Seuls les n premiers jobs (nombre de jobs simultanés configuré dans le queue.conf) s’exécutent réellement, le reste passe en file d’attente (souvent illimitée -1).

Dès qu’un job se termine, il libère une place et les jobs avec la queue batch la plus prioritaire se déclenchent.

Mise en place des queues prioritaires

La gestion des priorités est prise en charge suite à :
- Paramétrage du fichier vtom.ini,
- Déclaration des queues batch dans le référentiel.
Paramètre ABM_QUEUES_PRIORITY_INCREMENT dans le vtom.ini sous [BDAEMON] sont les suivants :
- DISABLED : la gestion est désactivée.
- BY_ONE : après chaque fin de Traitement, la priorité des travaux présents dans la file est incrémentée de 1. (activé par défaut)
- BY_PRIORITY : après chaque fin de Traitement, la priorité des travaux présents dans la file est incrémentée de la priorité initiale.
Ex. priorité sur la queue batch « queue_ksh » :
- queue_ksh.0 » pour les Traitements non prioritaires,
- queue_ksh.3 » pour les Traitements peu prioritaires,
- queue_ksh[.5] » par défaut,
- queue_ksh.7 » pour les Traitements relativement prioritaires,
- queue_ksh.10 » pour les Traitements prioritaires.
Remarques :
- Les Traitements ayant une priorité initiale à 10 la conservent et sont prioritaires quelque soit la priorité des autres Traitements.
- Les Traitements ayant une priorité initiale à 0 la conservent.
Solutions pour améliorer votre file d’attente
- mettre en place ce système de priorisation des queues batch <nom queue>.[0-10]
- analyser vos jobs, et éviter d’exécuter des jobs sur des clients de traitement/applicatif alors qu’ils pourraient/devraient tourner sur les clients du serveur VTOM (valorisation de ressource par exemple)
- éviter les scripts qui ne font rien d’autres que temporiser ou attendre des ressources (typiquement le job : exit 0, qui attend que telle ou telle ressource soit dispo)
  - à une époque, il était pratique d’avoir la log d’exécution sur le traitement pour connaître les heures de passage, mais maintenant avec les statistiques sélectives, on s’en passe
  - soit on remplace par un job en simulation (pas de passage dans la file d’attente), soit on essaye de positionner les ressources au niveau de l’application plutôt que du job (si c’est faisable)
- multiplier les queues d’exécution :
  - 1 queue pour les traitements techniques “rapides”
  - 1 queue pour les traitements applicatifs “longs”
rappel queue batch
- 1 file d’attente = 1 queue batch VTOM sur 1 client VTOM
- 1 client VTOM = 1 process bdaemon sur 1 machine (si plusieurs bdaemon sur une machine, ce sont des clients VTOM différents - port qui change)
- Les queues sont configurées dans $ABM/config/queues du client
  - 1 répertoire / queue :
```
$ ls -l $ABM/config/queues
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  $job$
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  $none$
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_csh
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_ksh
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_perl
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_rexx
drwxr-xr-x    2 u1vtom   vtom            256 Jun 30 2014  queue_sap
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_sh
drwxr-xr-x    2 u1vtom   vtom            256 Jun  7 2012  queue_tcsh
```
- 1 queue.conf + 1 users / répertoire :
```
$ cat $ABM/config/queues/queue_ksh/queue.conf
queue_ksh     nom de la queue
10            nombre max. de jobs en simultané
-1            nombre max. de jobs dans la file d’attente (-1 illimité)
/bin/ksh      binaire pour lancer la queue
20            obsolète
$ cat $ABM/config/queues/queue_ksh/users
any:-1:-1     on peut surdéfinir la priorité par utilisateur unix : user:nb max. parall:nb max. file
```
- 1 job en cours dans VTOM = 1 fichier dans $ABM_SPOOL (+ .env si dans la file)
```
$ ls $ABM_SPOOL
10      12      14      16      18      20      21      22      23      24      25      26      27      28      29      30      31      32
11      13      15      17      19      20.env  21.env  22.env  23.env  24.env  25.env  26.env  27.env  28.env  29.env  30.env  31.env  32.env
```
Ecrire sa queue batch VTOM

VTOM export consigne html - Docker et python

Voici mon premier Tuto en image ! soyez indulgents :) Si ça plait, j’en ferai d’autres (mieux, avec le son etc)

Ce tuto permet d’exporter les consignes VTOM et d’appréhender Docker.

J’utilise Docker pour l’environenemnt de test (voir mon tuto sur Docker : Environnement de test VTOM avec Docker )

Et python pour le code d’export des consignes VTOM.

Code et commandes utilisés :

# construire l'image à partir du DockerFile
docker built <répertoire>

# lister les images docker
docker images

# lancer un conteneur de votre image en interactif tty et en redirigeant les ports de votre machine vers le conteneur (IHM)
docker run -ti -p 30007-30008:30007-30008 <nomImage|ID>

# les instances de container qui sont en cours
docker ps

# connaitre l'adresse IP de votre machine docker (utile sous Windows)
docker-machine ip

# pour donner un nom à votre image
docker tag imageID imageName

# pour supprimer l'image
docker rmi -f monImage

# Export de la base VTOM en xml
vtexport -x > /var/tmp/vtexport.xml

import encodings
from lxml import etree
tree = etree.parse('/var/tmp/vtexport.xml')

for Instruction in tree.xpath('/Domain/Instructions/Instruction'):
		nameFileConsigne = Instruction.get('name')
		for Content in Instruction.xpath('Content'):
			f = open(nameFileConsigne +  ".html","w")
			s = Content.text
			s = s.decode('base64').decode('zlib')
			f.write(s)
			f.close

Au fait, comment j’en suis arrivé là ?!

C’est sur la demande d’un client qui voulait toutes les consignes VTOM.

J’ai vraiment galéré pour décoder les consignes qui sont encodées.

En fait, ma piste a pris le bon chemin quand j’ai fait un strings $TOM_BIN/vthttpd car j’ai vu que le web access le décodait à la volée. Et là, on voit qu’il y a du abs_zipbase64 et du base64Binary.

Autant le base64, c’était assez clair, la chaîne avait une bonne tête de base64.

Autant, je peux vous dire que j’en ai essayé des encodages pour trouver le zlib ! et j’ai perdu mon temps sur les sites de décodages du net car ils me supprimaient des caractères à chaque fois.

Heureusement que python est là !

A l’inverse, si vous voulez intégrer massivement des consignes à partir de fichiers html, c’est possible - à vos risques et périls, testez toujours en environnement de test - en encodant en (‘zlib’) puis en (‘base64’) et en intégrant un node <Instruction> dans le vtexport.xml.

import encodings
import sys
f = open("monfichier.html","r")
s = f.read()
s.encode('zlib').encode('base64')
sys.stdout.write(s)

(attention aux sauts de ligne, ils sont importants)
eJyzyTC0c8rPy8ovLVLwKc1OVVC00QcKcdkU2HmlKhSXZhYrlOTnKdgk2QW8KEq10U8CSukX2HEB
APm2EWI=

<Instructions>
...
  
    <Instruction name="MA_CONSIGNE_1" comment="ceci est un commentaire">
      <Content><![CDATA[eJyzyTC0c8rPy8ovLVLwKc1OVVC00QcKcdkU2HmlKhSXZhYrlOTnKdgk2QW8KEq10U8CSukX2HEB
APm2EWI=]]></Content>
    </Instruction>
...
</Instructions>

Pour le web access si ça vous intéresse, regarder mon tuto Web Access API VTOM :

api/instruction/getAll

Toutes les options du tengine

Une astuce de Fred, simple mais efficace, pour connaitre toutes les options possibles (du vtom.ini) de votre tengine (moteur VTOM) quand on n’a pas la documentation sous la main.

strings $TOM_BIN/tengine

Faites un grep sur le “= [” par exemple

$ strings $TOM_BIN/tengine | grep "= \["
GNSP                        = [%s]
useTz                       = [%d]
AcceptOrItems               = [%s]
AcceptAlphaStep             = [%s]
AdresseIP                   = [%s]
FQDNHostName                = [%s]
DateSystResetAll            = [%s]
AppCheckDateValue           = [%s]
JobCheckDateValue           = [%s]
JobBlockDateSyst            = [%s]
ManualRecovery              = [%s]
stats                       = [%s]
delaiWait                   = [%ds]
deplan_obj                  = [%s]
force_stats                 = [%s]
relanceAppCycliqueEnErreur  = [%s]
relanceJobCycliqueEnErreur  = [%s]
resnopla                    = [%s]
statusFailExist             = [%s]
statusFailSubmit            = [%s]
statusPileOne               = [%s]
statusPileAll               = [%s]
modeExecApp                 = [%s]
tagScript                   = [%s]
timeBexist                  = [%ds]
timeoutResGen               = [%ds]
nbJoursRattrapage           = [%d]
DelayHostVtSecure           = [%ds]
secureEngineTimeout         = [%ds]
blacklistCmd                = [%s]
useLinkBeforeEndTime        = [%d]
JobCheckAppConstraints      = [%d]
TRACE_FILE                  = [%s]
TRACE_FILE_COUNT            = [%d]
TRACE_FILE_SIZE             = [%dKo]
TRACE_LEVEL                 = [%d]
TRACE_SOURCE                = [%s]
TRACE_STDOUT                = [%s]
NbRetryDServerUnavailable           = [%d]
TimetoWaitRetryDServerUnavailable   = [%d]
appDisplayHeader            = [%s]
envDisplayHeader            = [%s]
tellClose                   = [%s]
tellDate                    = [%s]
tellFormat                  = [%s]
tellStatus                  = [%s]
- data..... array of %d %s = [
Next Cron     = [ %s (%d) ]
Next Cron     = [ none ]

VTOM version 5.8

Bravo aux équipes d’Absyss (gros clin d’oeil à mon DukeAstar) pour cette nouvelle version 5.8 ! C’est incroyable comment le produit évolue dans le bon sens (c’est à dire, le notre :O).

Les deux évolutions que j’adoooooooooore :

variables d’environnement personnalisables

Enfin !!! On peut désormais passer des variables personnalisables aux traitements.

Elles sont accessibles comme n’importe quelle variable d’environnement. LOVE

Cerise sur le gâteau, on peut utiliser les variables directement dans le champ script ou paramètre TRIPLE LOVE

unité de soumission

Alors là, chapeau.

Prenons l’exemple qu’on a tous fait : on veut purger le répertoire logs de VTOM sur tous nos clients VTOM.

AVANT :

On crée une application (ou plusieurs regroupées par plateformes par exemple) avec des myriades de jobs lançant le même script de purge sur tous nos clients.

avec la version VTOM > 5.8 :

Lorsqu’on définit un nouvel agent VTOM, on peut aussi créer une unité de soumission.

Par défaut, si on fait du 1 pour 1, on aura la même unité de soumission que l’agent définit.

Mais on peut aussi regrouper les agents dans une même unité de soumission.

J’appelle mon unité de soumission PROD_PAIE_UNIX, par exemple, afin d’y regrouper tous mes agents Unix de l’application de PAIE, pour l’environnement de PROD.

Je crée un seul job avec mon script de purge avec cette unité de soumission. Et voilà ! tous mes jobs de purges sont définis.

En mode pilotage, si on double clique sur le job, on a accès à une sorte de “suivi d’exploitation” avec les différents agents et le statut.

On double clique sur une ligne et on a les logs d’exécution de l’agent final en question.

On peut aussi faire un clique droit sur un agent spécifique et relancer le traitement uniquement sur cette machine.

What Else ?
- En plus, je trouve l’interface de plus en plus belle et rapide.
On peut vraiment paufiner les représentations graphiques (pour moi, il manque encore la possiblité de réorganiser les différents éléments graphiques à différents plans - premier plan, arrière plan, augmenter ou diminuer de plan graphique)
- ah une autre évolution que j’aime bien : on peut définir une heure de bascule sur les dates d’exploitation (exemple on veut une journée d’exploitation de 14h à 14h J+1, on n’est plus obligé de créer une application qui attend 37:59:00 !
Control-M Premiers ressentis après 2 semaines d'utilisation

Après les premiers jours de formation sur Control-M, j’étais très enthousiaste !

Je ne sais pas si c’était la nouveauté ou les possibilités natives du produit qui m’ont séduites mais, au début, j’étais conquis.

Ce que j’ai apprécié (v8 pour info) :
- le Do Action : on peut parser la log output directement, ajouter des conditions poussées, dire que le job est OK ou KO sur certaines conditions etc. etc.
- les liens : les liens sont textuels (même s’il y a une représentation graphique) ! alors c’est bien et c’est pas bien (parceque ça complique) mais je trouve ça très puissant
- les cycles : beaucoup d’options sympathiques (on peut relancer le cycle sur le début, la fin d’exécution par exemple), on peut spécifier le nombre de reruns etc.
- le module “planning” : c’est là qu’on effectue la conception et modélisation des jobs. Je trouve le module bien fait, on peut s’attribuer l’exclusivité de modification d’un folder, n’appliquer les modifications que lorsqu’on le souhaite etc.
- Les champs scripts “command line” : on peut écrire les commandes en ligne directement dans un champ texte
- les variables qu’on peut utiliser directement dans les commandline, ou dans les paramètres
- les modifications qu’on ne peut effectuer que sur le plan en cours
- module d’interface avec SAP pratique : on peut lister et sélectionner les programmes ABAP et variantes directement
Bon, le problème, c’est le reste de la semaine et la semaine d’après … Quand j’ai commencé à utiliser le produit réellement pour modéliser et régler les premiers problèmes d’exploitation.

Ca fait deux semaines que je pète un câble sur l’exploitation de control-m.

Par exemple, on ne peut pas voir le plan dans sa globalité. On ne voit que le plan du jour dans le module “Monitoring” ou les plans passés dans le module “History”, a moins de faire du “Forecast” (en gros on monte fictivement un plan à une date future donnée).

Autre exemple, on ne peut voir les log d’exécution que de la journée en cours dans le “Monitoring”. Pas moyen, non plus de voir le script en direct depuis l’outil …

Le pire reste la visualisation du plan :

Imaginez que toutes les applications de tous vos environnements VTOM se retrouvent dans un seul et même plan et que la disposition ne soit pas définie comme vous le souhaitiez (un peu n’importe comment d’ailleurs) et que les liens partent dans tous les sens.

Après deux semaines d’intense utilisation sur Control-M pour un nouveau projet (migration de TNG à Control-M), je reviens sur mes premiers instants de découverte pendant lesquels j’ai vraiment apprécié le produit.

Autant j’apprécie toujours la conception et les possibilités de Control-M, autant l’exploitation et l’utilisation quotidienne du produit est une vraie tannée (surtout que mon Control-M Desktop plante toutes les 10 minutes et présente des lenteurs vraiment contraignantes).

Au final, rien qu’on ne puisse pas faire avec VTOM si ce n’est quelques lignes de code pour gérer tel ou tel envoi de mail ou parsing de log pour pallier aux options natives de Control-M.

Bref, vive VTOM !
Port 30004 encore en LISTENING malgré l'arrêt du client VTOM

J’ai eu ce bug récemment : je stoppe le client VTOM, je le restart et plus aucune communication n’est possible.

Symptômes
- Le bstat pour connaitre le statut du client VTOM ne répond pas.
- Client à STOP dans le suivi des clients VTOM.
- netstat -ano | grep 30004 donne des ports en LISTENING alors que le bdaemon est arrêté et les process ID n’existent plus
Solution :

kill les process WerFault.exe (passer en surbrillance sur le process et vous verrez les PID donnés dans le netstat -ano)

Ca vous permetra de ne pas reboot votre serveur pour rien !

Formules VTOM

Comment ça fonctionne ?

Exemple : application simple - bonjour

L’administration des projets sur platform.sh

Installer platform CLI pour une meilleure gestion des projets et environnements

Configuration de l’application : .platform-app-yaml.html + .platform/services.yaml + .platform/routes.yaml

mise a jour de l’environnement n-1

Je teste et je merge sur la branch principale

Autres applications

Conclusion

vtplan - affiche la planification des applications ou traitements

Problématique des gros environnements de production

Priorité dans la file d’attente : principe

Mise en place des queues prioritaires

Solutions pour améliorer votre file d’attente

rappel queue batch

Code et commandes utilisés :

variables d’environnement personnalisables

unité de soumission

AVANT :

avec la version VTOM > 5.8 :

What Else ?

Symptômes

Solution :