Socle ADV, demonstration technique

Chaque action montre le chemin reel de la requete : navigateur, puis Traefik, puis Node, puis PostgreSQL.

Ouvrir l'ecran metier
non teste

1. Ouvrir un passage sur un mail

cree un message et un passage

2. Ecrire la sortie d'un agent

passage

3. Ecrire la commande et ses lignes

4. Relire et produire

avec la cle ECRAN

5. Ce qu'il y a dans la base

Le chemin de la derniere requete

Lance une action a gauche pour voir la chaine se remplir.

Reponse brute

rien pour l instant

Tout ce que l'API sait faire, et rien d'autre

Un appelant ne peut faire que ce qui figure dans cette liste. C'est ca, un contrat : une porte par usage, et chacune dit ce qu'elle declenche derriere. Power Automate n'a jamais connaissance des tables, il connait des routes.

MethodeRouteCleCe que ca declenche derriere
GET/api/santeaucuneun select 1, pour verifier que la base repond
POST/api/passagesfluxune ligne dans message, puis une dans passage
POST/api/passages/:id/sortiesfluxune ligne dans sortie_agent, et le cout cumule sur passage
POST/api/passages/:id/commandesfluxcommande et ligne, dans une transaction : tout ou rien
GET/api/passages/:idecranlecture jointe de passage, message, sortie_agent, commande, ligne
GET/api/passagesecranles 50 derniers passages, avec le nombre de commandes
GET/api/passages/:id/fichierecranfabrique le CSV depuis la base et le garde dans fichier
GET/api/commandesecranla liste pour l'ecran metier
GET/api/commandes/:idecranune commande, ses lignes, et les libelles du catalogue
PATCH/api/commandes/:idecranecrit commentaire, commente_par et l'horodatage
PATCH/api/lignes/:idecranecrit le commentaire d'une ligne
POST/api/correctionsecranune ligne dans correction, avec un motif pris dans une liste fermee
GET/api/articlesecranle catalogue articles
GET/api/tablesecranle compte et les dernieres lignes de chaque table
Pourquoi c'est plus sur qu'un acces direct a la base.
La cle du flux ouvre quatre portes en ecriture. Elle ne peut pas lire la liste des clients, ni exporter, ni supprimer une ligne, parce qu'aucune route ne le permet. Un identifiant PostgreSQL, lui, ouvre la base entiere : toutes les tables, lecture et ecriture, y compris l'effacement.

Et cette cle finira visible dans la configuration du flux. La question n'est donc pas de savoir si elle sera lue un jour, mais ce qu'on peut faire avec quand elle l'est.

Et si on change les tables ? La demonstration

Les deux voies ci-dessous ecrivent dans la meme table. A gauche, ce qu'un flux aurait fige dans un de ses noeuds le jour ou il a ete construit. A droite, un appel d'API. Lance les deux : elles marchent toutes les deux.
Renomme ensuite la colonne, de deux facons. Avec adaptation du contrat : le flux casse, l'API tient. Sans adaptation : les deux cassent, ce qui montre que l'API n'a rien de magique. Ce qui la sauve, c'est qu'il n'y a qu'un seul endroit a corriger.

Voie 1 · le flux ecrit du SQL en direct

Le nom de la colonne est ecrit en dur dans le noeud du flux.
pas encore lance

Voie 2 · le flux appelle l'API

Le flux envoie { nom, ville }. Il ignore tout des colonnes.
pas encore lance
Ce n'est pas magique, et il faut le dire. Quand on renomme la colonne, l'API aussi doit etre adaptee : une ligne de contrat a changer. Le bouton rouge le prouve : si on renomme sans adapter le contrat, l'API casse exactement comme le flux.

La difference n'est pas qu'il n'y a rien a faire. C'est le nombre d'endroits ou le faire, et la facon de s'en apercevoir.

Cote SQL direct : autant d'endroits que de noeuds dans autant de flux. On les retrouve de memoire, rien ne previent, il n'y a ni compilation ni test, et l'erreur apparait en production sur une vraie commande.

Cote API : un seul endroit, dans du code versionne, relu et deploye une fois. Les appelants, eux, n'ont rien change du tout. C'est pour cela qu'une base que dix flux interrogent en direct est figee des le deuxieme flux, alors qu'une base derriere un contrat reste modifiable.