Le fichier /etc/fdn/adsl/wf.cfg

Ce fichier est le fichier qui décrit toutes les actions pilotées par le workflow pour l'ADSL. Sur le monde de fonctionnement du workflow et les fichiers de configuration associés, voir ici.

Pour l'ADSL, le workflow pilote deux activités principales: la souscription et la résiliation d'une ligne. La souscription peut venir d'un des trois sites de souscription: celui des futurs adhérents, celui de Neuronexion, ou celui de MetaConsult. Les résiliations ne peuvent venir que de l'application web de gestion des adhérents. Ces deux activités principales sont représentées par deux tâches: depl-adsl et resil-adsl.

Le déploiement d'une ligne ADSL

Le déploiement d'une ligne ADSL, modélisé par la tâche depl-adsl, est une tâche de type serial. Elle enchaîne les étapes suivantes:

elig est une tâche qui va contrôler que la ligne est effectivement éligible à l'offre demandée. La tâche planifie un job via plutar et se met en attente d'un évennement. Quand le job plutar réussira, l'évènement sera produit, qui réveillera la tâche. Si l'éligibilité est positive la tâche se termine bien, sinon elle échoue. Il faut alors reprendre à la main. Ce cas ne devrait normalement pas arriver, puisque l'éligibilité est testée lors de la souscription. Cependant, le site de souscription n'est pas très robuste, et il est assez facile de lui faire prendre des vessies pour des lanternes: il fait le test d'éligibilité au début de l'inscription, mais la commande n'est enregistrée qu'à la fin, on peut s'amuser à altérer le numéro de téléphone entre temps. Si le test d'éligibilité échoue, ce sera probablement à cause de ça. L'attente ne peut pas durer plus de 24 heures, puisqu'en cas d'échec l'éligibilité est re-testée toutes les heures, au maximum 24 fois.

fas est une tâche qui se place en attente d'un évènement. Cet évènement est produit quand on clique sur le bouton « Valider » de la page de validation des FAS d'une ligne. Ça permet de suspendre le déploiement jusqu'à ce qu'on ait bien reçu tous les papiers utiles. Les FAS ne sont pas forcément réglés à ce moment là, ils peuvent par exemple être prélevés sur le compte bancaire du futur adhérent. L'attente pour cette tâche peut être longue, au moins quelques jours (le temps que la poste fasse son travail), parfois plusieurs semaines voire plusieurs mois. Si la tâche attend depuis plusieurs mois, ça peut valoir le coup de refaire un test d'éligibilité à la main sur la ligne.

radius est la tâche qui va réserver une adresse IP pour la future ligne et créer un compte radius. Elle ne doit pas échouer. Elle peut, parfois, se mettre en attente. Le seul cas connu est quand il n'y a plus d'adresses IP libres dans la base.

cdetd est la tâche qui va générer la ligne de commande à transmettre à TD pour cette ligne ADSL. La ligne est stockée en base, et est marquée comme non expédiée. La tâche se met en attente d'un évènement qui dit que la ligne a été convenablement transmise. Quand l'automate envoie-td.pl jouera, il placera dans un fichier de commande toutes les lignes en attente et transmettra ce fichier à TD. Ensuite, TD nous fera parvenir un fichier .arfic qui indique que notre fichier de commande a été reçu. L'automate d'analyse des réponses de TD lancera alors tous les évènements utiles pour débloquer les tâches concernées. Cette attente ne devrait pas exéder quelques heures, puisqu'on envoie des fichiers à TD plusieurs fois par jour.

wait_ar_td est la tâche d'attente de l'accusé réception de TD. TD doit nous faire parvenir, pour chaque commande, une information disant que la commande en question est prise en compte et est en cours de traitement, ou au contraire qu'elle a été jugée invalide et a donc été rejetée. L'automate d'analyse des fichiers transmis par TD se chargera de provoquer l'évènement qui débloquera la tâche. Si l'AR est positif la tâche se termine bien, sinon elle échoue.

wait_cr_td est la tâche qui attend le compte rendu d'exécution de la commande. TD est succeptible d'envoyer plusieurs compte rendus intermédiaires pendant la vie d'une commande, par exemple pour indiquer des retards. À chaque fois qu'un compte rendu est reçu, l'évènement correspondant est généré. Tant que la tâche reçoit des compte rendus intermédiaires, elle en prend note, prévient l'adhérent, les annule, et se remet en attente. Si elle reçoit un compte rendu définitif positif elle se termine bien. Si elle en reçoit un négatif, elle échoue.

Chacune de ces tâches est succeptible d'échouer. Quand une tâche échoue, la tâche principale est bloquée: elle reste à attendre la bonne fin de la tâche en question, qui ne risque plus de survenir. Le menu de déblocage des tâches sert précisément dans ce cas là: les cas de blocage les plus raisonnables y sont prévus (commande rejetée par TD, par exemple). En pareil cas, après avoir été modifier ce qu'il faut dans le commande (en modifiant les propriétés de la tâche principale), quand on demande à débloquer le déploiement, ça va marquer comme annulées toutes les tâches depuis cdetd, et ça va relancer la dernière tâche utile.

Un autre cas de blocage, plus ennuyeux, est quand une des sous tâche n'arrive pas à démarrer. C'est le cas, par exemple, quand elle reçoit un paramètre qui est jugé invalide par la configuration. Ce cas est détecté par la page de déblocage des tâches sous le nom endofphantom: en effet la tâche principale se retrouve à attendre la bonne fin d'une tâche fille qui n'existe pas, n'ayant pas réussi à se lancer. Ce cas correspond clairement à un bug. Soit à un bug dans le configuration (syntaxe trop restrictive dans la configuration); soit à un bug dans une des tâches qui aura positionnée une valeur anormale pour un paramètre. Ce cas ne peut pas se débloquer automatiquement: il faut aller regarder à la main ce qui coince, corriger le bug, puis remettre en marche. La remise en marche se fait en deux temps: annuler l'évènement attendu par la tâche principale (qui doit s'appeler EOT-), puis envoyer un évènement à la tâche principale qui lui fait croir que la tâche fille précédente vient de se terminer. Par exemple si la tâche qui échoue à se lancer est wait_ar_td, la tâche précédente est cdetd. Si le numéro de téléphone de la ligne concernée est 0123456789 alors sont identifiant unique est TD/0123456789 (voir le fichier de configuration /etc/fdn/adsl/tables.cfg pour voir comment on trouve que cdetd se dit TD), l'évènement signalant que la tâche se termine est FEOT-TD/0123456789 (pour Fake End Of Task, on indique bien que c'est une reprise sur erreur, et pas une vrai fin de tâche).

Chronogramme d'un déploiement

Voilà l'enchainement de taches, d'échanges de fichiers, et d'évèvements, qui correspond au déploiement sans erreur d'une ligne ADSL.

Les évènements, qui sont numérotés 1 dans l'exemple (supposant que c'est la première commande de FDN) sont en fait numérotés, en général, avec l'identifiant de l'objet correspondant en base de données.

La tâche cdetd crée un enregistrement en base contenant l'ordre à transmettre à TD. tenvoie-td.pl enverra cet enregistrement. C'est le numéro de cet enregistrement qui sera utilisé dans les évènements relatifs: ARFIC-nnn, ARTD-nnn et CRTD-nnn. Quand on reçoit un fichier .arfic, il accuse réception de toutes les commandes d'un fichier: le système va produire un évènement par ligne dans le fichier de départ, de manière à produire tous les ARFIC-nnn attendus. C'est nécessaire parce que quand la tâche cdetd se met en attente elle n'est pas en mesure de dire dans quel fichier partira sa commande.

Tâche principale             Sous tâches               	Automates	TD
depl-adsl:D/0100000000
   <- init
			     elig:E/0100000000
   			     	<- init
			     	<- ELIG-1           	plutar
			     	<- end
   <- EOT-E/0100000000
			     fas:F/0100000000
			     	<- init
			     	<- FAS-0100000000   	appli-web
			     	<- end
   <- EOT-F/0100000000
			     radius:R/0100000000
			     	<- init
			     	<- end
   <- EOT-R/0100000000
			     cdetd:TD/0100000000
			     	<- init
			                             	envoie-td.pl
						     	send_ftp.pl
									Recoit fichier
						                     	Renvoit .arfic
						     	recv_ftp.pl
			     	<- ARFIC-1	     	automate.pl
			     	<- end
   <- EOT-TD/0100000000
   			     wair_ar_td:AR/1
   			     	<- init
			     						Envoit un .ar
							recv_ftp.pl
				<- ARTD-1		automate.pl
				<- end
   <- EOT-AR/1
   			     wait_cr_td:CR/1
			     	<- init
									Envoit un .cr
							recv_ftp.pl
				<- CRTD-1		automate.pl
				<- end
   <- EOT-CR/1
   <- end
Activités de la tâche principale

La tâche principale, essentiellement, ne fait rien. En tous cas, elle ne participe pas du tout au déploiement de la ligne. Elle fait essentiellement trois choses: mettre à jour les dates qui apparaissent sur le site de suivi de commande; envoyer des mails à l'adhérent; et envoyer des mails au bureau.

La première activité de la tâche principale, pendant son init est d'aller fouiller en base de données pour remonter toutes les informations utiles. Elle ne reçoit en paramètre que quelques informations, qui sont contrôlées, tout le reste étant reprise de la base de données.

Il y a, a peu près, autant de phases indiquées sur le site de suivi que de sous tâches (le lien étant évident à faire). À chaque fois que la tâche principale reçoit un évènement EOT-xxx, elle met à jour la date correspondante. Elle envoit également un mail à l'adhérent lui indiquant que cette étape là est franchie (avec le bureau en copie).

Quand une sous-tâche échoue, ou tout simplement quand quelque chose se passe mal, c'est la tâche principale qui est chargée d'alerter. Pour une sous-tâche qui échoue, elle ne le voit pas, et donc ne dit rien (il faut le détecter autrement), mais elle sait prendre en compte le re-démarrage après correction de l'erreur.

Dans l'exemple précédent, supposont que la commande a été rejetée par TD pour une raisons quelconque (genre offre innexistante). La tâche wait_ar_td échoue parce qu'elle reçoit un AR négatif. Avant de se mettre en échec, elle envoit un évènement CRNOK à la tâche principale. La tâche principale envoit un mail à l'adhérent pour lui que ca merdoie et qu'on traite. Elle nous envoit aussi un mail, avec les codes d'erreur correspondant. La situation est alors bloquée.

Une fois la situation bloquée, quelqu'un du bureau creuse la question, trouve que le code offre est invalide, et va corriger ça dans les propriétés de la tâche principale. Ensuite il débloque la tâche de déploiement. Le déblocage va dégager la tâche wait_ar_td, puis dégager la tâche cdetd, puis envoyer à la tâche principale FEOT-R/0100000000. Ça provoque l'envoit d'un mail (à l'adhérent et au bureau) disant que le déploiement repart après déblocage manuel. Une nouvelle tâche cdetd est alors lancée.

Quelques paramètres importants

Il y a quelques paramètres clefs dans le déploiement d'une ligne. Le plus important, le seul sur lequel on doive parvois intervenir, est le paramètre cegetel que la tâche principale positionne toute seule à 0. Si on passe ce paramètre à 1 avant que la tâche cdetd ne soit lancée, alors tout le traitement vis-à-vis de TD est annulé. C'est comme ça qu'on traite le cas particulier des gens qui ont une ligne Cegetel et qui l'utilisent pour se connecter via FDN.

Il y a également deux paramètres (en entrée) login et passwd qui correspondent aux login et mot de passe radius. Normalement, ils ne sont pas renseignés, et seront renseignés pendant le déploiement (par la tâche radius). S'ils sont renseignés d'avance, la tâche radius ne fait rien. C'est utilisé par le site de souscription Neuronexion pour ne pas créer de compte radius: ils se démerdent comme des grands.

Enfin, il reste des paramètres relativement normaux, avec lesquels on ne joue normalement pas. nom est le nom du futur adhérent, utilisé pour calculer un login radius. telephone est le numérot de téléphone concerné (pas toucher, ça changerait le nom des clefs des sous tâches, et ça foutrait gravement la merde). debit est le débit demandé sur la ligne. option indique si c'est en option 1 (dégroupé) ou en option 3 (non-dégroupé). tarif indique le tarif appliqué (pour mettre le prix des FAS dans le mail). ligneid est le numéro de la ligne dans la base de données. deplid est le numéro du DEPLOIEMENT dans la base, c'est cet enregistrement qui porte les différentes dates mises à jour pour le site de suivi.

Résiliation d'une ligne ADSL

La résiliation d'une ligne est pilotée par la tâche resilt-adsl. C'est aussi une tâche de type serial. Elle ressemble beaucoup au déploiement, mais dans l'autre sens. Elle enchaîne les sous-tâches suivantes.

resil_radius qui invalide le compte radius en l'empêchant de se connecter. Il n'est pas supprimé de la base (pour pouvoir tracer les connexions sur requête de la justice). Si aucun compte radius n'est associé à la ligne (cas Neuronexion), cette tâche ne fait rien.

free_ip qui marque l'adresse IP de l'adhérent comme libre. Elle pourra être ré-utilisée immédiatement (ce qui est plutôt triste). Si aucune adresse IP n'est associée à la ligne (Neuronexion), cette tâche ne fait rien.

stop_factu qui arrête la facturation de la ligne. Jusque-là, il n'y a rien qui doive bloquer. Ces trois premières tâches doivent s'exécuter d'une traite. L'adhérent recevra donc un rafale de 3 ou 4 mails lui indiquant tout ça.

restd envoie la demande de résiliation à TD. Pour le moment, par moyen de ne pas le faire pour les lignes Cegetel.

wait_ar_td attend l'AR de TD disant que la demande de résiliation a été reçue.

wait_cr_td attend le CR de TD disant que la ligne est effectivement résiliée.

Pour le moment cette tâche n'est pas capable de ne pas transmettre la résiliation à TD. Il faut donc traiter ce type de résiliation à la main. Ce défaut sera probablement corrigé lors du passage au protocole de commande de Neuf-Cegetel.

Il pourrait être intéressant que free_ip passe par plutar pour libérer l'adresse IP, histoire de ne pas la redonner tout de suite à quelqu'un d'autre.

Chronogramme d'une résiliation
Tâche principale		Sous-tâche			Automate		TD
resil-adsl:RE/0100000000
  <- init
				resil_radius:RR/0100000000
				  <- init
				  <- end
  <- EOT-RR/0100000000
				free_ip:FI/0100000000
				  <- init
				  <- end
  <- EOT-FI/0100000000
				stop_factu:FAC/0100000000
				  <- init
				  <- end
  <- EOT-FAC/0100000000
				restd:RTD/0100000000
				  <- init
								envoie-td.pl
								send_ftp.pl
											Recoit fichier
											Envoit fichier .arfic
								recv_ftp.pl
								automate.pl
				  <- ARFIC-2
				  <- end
  <- EOT-RTD/0100000000
				wait_ar_td:AR/2
				  <- init
				  							Envoit fichier .ar
								recv_ftp.pl
								automate.pl
				  <- ARTD-2
				  <- end
  <- EOT-AR/2
				wait_cr_td:CR/2
				  <- init
											Envoit fichier .cr
								recv_ftp.pl
								automate.pl
				  <- CRTD-2
				  <- end
  <- EOT-CR/2
  <- end

À noter que les tâche d'attente de réponses de TD sont les mêmes que pour un déploiement: on attend la réponse à une commande, c'est bien la même activité, même si la commande est différente. C'est en particulier pour ça que ces tâches sont nommées d'après le numéro de la commande TD, et pas d'après le numéro de téléphone de l'adhérent comme le reste.

Activités de la tâche principale

Comme pour une déploiement: envoyer des mails un peu partout fonction de si ça se passe bien ou mal. A priori, les cas où ça se passe mal devraient être plus rares: autant un dégroupage peut merder gravement, autant une résiliation ça ne devrait pas.

Quelques paramètres importants

Cette tâche démarre au quart de tour: la majorité des traitements sont bouclés lors de la première exécution. En effet, comme il n'y a rien de bloquant dans le système, tout va s'enchaîner d'une seule traite jusqu'à l'envoit de la commande vers TD. Du coup, si on veut intervenir à la main dans les paramètres, on ne peut le faire qu'après que la commande a été préparée (sauf à devoir passer avant le cron, ce qui n'est pas super fiable).

Il n'y a que deux paramètres en entrée de cette tâche: le numéro de la ligne dans la base de données et le numéro de téléphone. Le numéro de téléphone, c'est pour faire joli.