L'outil de workflow développé pour et par FDN se base sur un fichier de configuration complexe et détaillé pour déterminer les traitements à faire pour les tâches.
Ce fichier de configuration est écrit pour correspondre à la bibliothèque FDN::Common::Config. Il a donc la syntaxe d'un fichier .ini avec quelques petits ajouts.
Le principe est relativement simple. Chaque tâche est décrite dans une section. Il existe trois type de tâches: les tâches atomiques, qui sont les plus simples; les tâches séries, qui enchaînent plusieurs sous-tâches, et les tâches parallèles, qui lancent plusieurs sous-tâches en parallèle et attendent la fin de toutes les sous-tâches pour se terminer.
La configuration d'une tâche indique son type, et le mode de calcul de la clef unique d'identification de la tâche.
[resil-adsl] type = serial keycalc = &FDN::Adsl::Wf::faire_clef_telephone
La méthode de calcul de la clef CAT indique de prendre comme clef unique une concaténation de tous les paramètres obligatoires de la tâche. Il faut mieux l'éviter, ça fait souvent des clefs idiotes et trop longues (la longueur maximale d'une telle clef est de 20 caractères).
La fonction de calcul de la clef reçoit en paramètre le type de tâche pour laquelle elle calcule la clef (ici resil-adsl) et l'ensemble des paramètres de la tâche. Elle retourne la clef unique.
La description d'une tâche donne également la liste de ses paramètres d'entrée, dans la clef @in. Pour chacun de ces paramètres d'entrée une clef indique s'il est obligatoire ou pas, et la syntaxe qu'il doit respecter.
@in = machin @in = truc machin = mandatory:^\d+$ truc = optional:.*
Cet exemple indique que le paramètre machin est obligatoire, ne doit être composé que de chiffres, et doit en contenir au moins un; et que le paramètre truc est optionnel et que sa syntaxe n'est pas importante. En pareil cas il n'y a pas d'intérêt particulier à mentionner le paramètre dans la configuration.
@out = resultat resultat = mandatory:.*
En symétrique de @in il existe @out qui permet de contraindre les propriétés de la tâche lorsqu'elle se termine. Dans l'exemple précédent on indique qu'à la fin de la dernière exécution de la tâche, il doit exister une propriété resultat, dont on pourrait contraindre la syntaxe. Si cette propriété n'est pas présente, ou ne répond pas à la syntaxe indiquée, la tâche est considérée comme ayant échouée (même si elle dit le contraire).
Les contraintes sur les paramètres en entrée et en sortie sont très pratique en phase de debug: ça plante clairement, franchement, et ça le dit dans les logs. Par contre, en utilisation « industrielle », c'est nettement plus handicapant: si une sous-tâche échoue à se lancer parce que des paramètres en entrée sont invalides, on se retrouve dans un état très instable, et qu'il faut aller rattraper plus ou moins à la main dans la base de données.
action = &FDN::Adsl::Wf::resilier_ligne_adsl
La clef action indique le nom de la fonction perl chargée d'exécuter la tâche. Le module perl correspondant sera chargé en temps voulu, ainsi que ceux qui auront été précisés sur la ligne de commande.
Pour les tâches de type serial ou parallel, la clefs @launch indique la nature des tâches filles, et l'ordre dans lequel il faut les lancer. Pour les tâches de type atomic cette notion n'a évidemment pas de sens. L'ordre est supposé être sans importance pour les tâches de type parallel.
La convention de nommage des paramètres fait qu'il ne peut pas y avoir deux tâches du même type dans la descendance d'une tâche donnée.
@launch = a_lancer @a_lancer-in = $variable => var1 @a_lancer-in = const => var2 @a_lancer-out = result => resultat-ss-tache
Dans l'exemple précédent on indique que la première tâche fille à lancer est de type a_lancer (qui doit être décrit dans une section portant ce nom-là ailleurs dans le fichier de configuration). Pour lancer cette tâche, le système fabriquera ses paramètres d'entrée comme indiqué. C'est-à-dire que la variable variable prise dans les propriétés de la tâche mère sera présente sous le nom var1 dans les propriétés de la nouvelle tâche fille à son lancement. Elle aura également une propriété du nom de var2 dont la valeur sera const. À la fin de l'exécution de la tâche fille, sa propriété result sera recopiée dans les propriétés de la tâche mère sous le nom resultat-ss-tache.
Cette mécanique est quasiment la seule permettant de faire communiquer deux tâche. Le passage d'un paramètre constant est pratique, par exemple, pour utiliser la même tâche dans deux contexte différents. Par exemple dans un cas elle doit envoyer des mails et dans l'autre non.