Le socle technique : files de travaux, composants, environnement, impression

Sous les modules métier se tient un socle que personne ne demande et dont tout dépend : une file de travaux de fond, un système de composants, un moyen de sortir les secrets de la base, et une imprimante qui sort une étiquette sans passer par le navigateur.

Vingt-sept modules communautaires le composent. Ils n'ont pas d'écran métier, et ce sont eux qui tombent en premier.

Résumé

Neuf modules traitent la file de travaux de fond : le noyau avec ses canaux, ses fonctions et ses tâches, les lots de travaux, l'exécution sans processus dédié, la planification par action planifiée, un profileur, le contrôle des abonnements aux notifications, l'import de fichiers CSV en arrière-plan, et deux modules de test.

Cinq modules traitent les composants et les connecteurs : un système de composants alternatif aux modèles, son système d'événements, le cadre générique de connecteurs, un onglet Connecteurs sur la fiche produit, et deux modules de test.

Six modules traitent la configuration hors base : le socle qui sort les réglages de la base vers un fichier d'environnement, le chiffrement des identifiants par environnement, les serveurs de messagerie, leur variante pour un service de messagerie commercial, les paramètres système, et leur combinaison avec le chiffrement.

Sept modules traitent l'impression serveur : le socle qui déclare des imprimantes et des serveurs d'impression, son extension imprimante d'étiquettes, l'envoi d'un rapport par courriel, l'impression d'étiquettes ZPL II, le socle d'impression automatique avec son volet étiquettes, et la déclaration des serveurs d'impression hors base.

Deux modules enfin ajoutent une automatisation des actions sur les modèles à discussion, avec son reporting d'activités et de clics, et un socle IoT avec ses appareils, groupes et systèmes.

L'essentiel

• Une file de travaux de fond avec canaux, tâches et lots.
• Un import CSV en arrière-plan.
• Un cadre générique de connecteurs vers des systèmes externes.
• La configuration sortie de la base vers un fichier d'environnement.
• Les identifiants chiffrés par environnement.
• Des imprimantes déclarées côté serveur, pas côté poste.
• L'impression d'étiquettes ZPL II.
• Une automatisation des actions avec son reporting de clics.

Ce que ces modules ajoutent à l'instance

Les menus : File d'attente des tâches avec ses canaux, fonctions, tâches et lots ; Connecteurs ; Paramètres ▸ Technique ▸ Paramètres ▸ Configuration serveur ; Paramètres ▸ Impression en cours avec ses imprimantes, serveurs, rapports et pièces jointes ; Paramètres ▸ Impression en cours ▸ ZPL II Labels ; une application Automatisation et une application IoT.

La file de travaux de fond

Un ERP qui envoie trois mille courriels, recalcule un cache de prix ou synchronise un catalogue ne peut pas le faire dans la requête de l'utilisateur. La file de travaux est la pièce qui déplace ce travail hors de l'écran — et la seule qu'il faut surveiller tous les jours.

queue_job (version 18.0.3.4.1, LGPL-3) fournit cette file : des canaux qui limitent le parallélisme par type de travail, des fonctions de tâche qui déclarent ce qui est différable, et des tâches avec leur état, leurs tentatives et leur trace d'erreur. queue_job_batch ajoute les lots de travaux — suivre trois mille tâches comme une seule.

Deux modules changent la façon dont la file tourne :

• queue_job_cron_jobrunner exécute les tâches sans processus dédié, par le mécanisme d'actions planifiées. C'est le mode de déploiement le plus simple, et le moins performant.
• queue_job_cron permet de lancer une action planifiée comme une tâche de file — l'inverse : la planification reste native, l'exécution passe par la file.

queue_job_profiler profile l'exécution d'une tâche, et queue_job_subscribe contrôle quels utilisateurs sont abonnés aux notifications de tâche — sans lui, une file en erreur inonde la boîte d'un administrateur.

base_import_async (version 18.0.1.0.0) importe un fichier CSV en arrière-plan : l'import natif d'Odoo tient dans la requête, donc tombe au-delà de quelques milliers de lignes. Celui-ci découpe le fichier en tâches.

test_queue_job et test_queue_job_batch sont des modules de test : ils n'ont rien à faire en production.

Les composants et le cadre de connecteurs

component (version 18.0.1.0.5, LGPL-3) ajoute un système de composants : une façon d'organiser du code métier sans passer par des modèles Odoo. component_event y ajoute un système d'événements — un module déclenche un événement nommé sans savoir qui y réagira, et d'autres s'y abonnent.

connector (version 18.0.1.0.2) est le cadre générique de construction de connecteurs vers un système externe. Il est important de comprendre ce qu'il ne fait pas :

Le cadre de connecteurs ne connecte lui-même aucun système. Il fournit la file de synchronisation, les événements et les classes de base — correspondances, liaisons, adaptateurs — que des modules concrets viennent compléter. Installé seul, il ajoute un menu Connecteurs et rien dedans.

Les connecteurs concrets vers des boutiques ou des moteurs de recherche ne sont pas dans ce dépôt : ils vivent dans des dépôts séparés, avec leur propre rythme de portage. connector_base_product prépare un onglet Connecteurs sur la fiche produit, masqué jusqu'à ce qu'un connecteur concret y mette quelque chose.

test_component et test_connector sont des modules de test — leur résumé de manifeste dit explicitement de ne pas les installer.

L'import de fichiers par sessions est traité dans interfaces et échanges.

Sortir la configuration de la base

Une copie de la production pour recette emporte avec elle les mots de passe des serveurs de messagerie, les clés d'API et les comptes techniques. C'est ainsi qu'une base de test envoie de vrais courriels à de vrais clients, ou dépose de vraies factures sur une plateforme.

server_environment (version 18.0.1.0.0, LGPL-3) répond à ce problème : il sort certains réglages de la base vers un fichier d'environnement lu au démarrage, consultable sous Paramètres ▸ Technique ▸ Paramètres ▸ Configuration serveur. La base de recette lit son propre fichier, donc ses propres comptes.

• mail_environment applique le principe aux serveurs de messagerie entrants et sortants, et mail_environment_google_gmail à un service de messagerie commercial nommément désigné.
• server_environment_ir_config_parameter l'applique aux paramètres système.
• data_encryption chiffre les comptes et identifiants par environnement, et server_environment_data_encryption combine les deux approches.

Le choix entre les deux est une décision d'exploitation : le fichier d'environnement sort la valeur de la base, le chiffrement la laisse en base mais illisible sans la clé. Le premier protège d'une copie de base, le second d'une lecture de base.

Le même mécanisme sert au compte technique de la facturation publique, traité dans Chorus Pro.

L'impression côté serveur

base_report_to_printer (version 18.0.1.4.1, AGPL-3) déclare des imprimantes et des serveurs d'impression sous Paramètres ▸ Impression en cours, avec le comportement par rapport. Il dépend d'une bibliothèque Python externe de dialogue avec le système d'impression du serveur.

La différence entre imprimer côté poste et côté serveur est celle entre un PDF téléchargé que l'opérateur ouvre et envoie, et une étiquette qui sort de l'imprimante à côté de lui quand il valide. Dans un entrepôt, c'est la différence entre vingt secondes et deux.

• base_report_to_label_printer ajoute la notion d'imprimante d'étiquettes, distincte de l'imprimante de documents.
• base_report_to_printer_mail permet d'envoyer un rapport par courriel depuis la même configuration.
• printer_zpl2 (version 18.0.1.0.2) ajoute l'impression d'étiquettes ZPL II, avec son référentiel sous Paramètres ▸ Impression en cours ▸ ZPL II Labels.
• printing_auto_base (version 18.0.1.3.2) est le socle de l'impression automatique — imprimer sans clic, à un événement —, et printing_auto_label_printer l'applique aux imprimantes d'étiquettes.
• server_env_printing_server déclare les serveurs d'impression hors base, par fichier d'environnement.

Le langage d'étiquettes ZPL II est celui d'un fabricant dominant d'imprimantes thermiques : c'est ce qui permet d'envoyer une étiquette comme un flux de commandes, et non comme une image — donc nette, rapide, et sans décalage.

L'impression des étiquettes de transport est traitée dans étiquettes et colis.

Automatisation et IoT

automation_oca (version 18.0.1.0.4, AGPL-3) fournit une application Automatisation : des configurations d'automatisation sur les modèles à discussion, avec leurs filtres, leurs étiquettes, et un reporting des activités et des clics.

Le reporting de clics est ce qui distingue cette automatisation des actions automatisées natives : elle ne se contente pas de déclencher, elle mesure si le destinataire a réagi. C'est une automatisation de relation, pas de traitement.

iot_oca (version 18.0.1.0.1, AGPL-3) fournit un socle IoT communautaire : une application IoT avec ses appareils, leurs groupes, leurs étiquettes et les systèmes auxquels ils appartiennent. C'est un socle — il ne parle à aucun appareil précis.

Limites connues

• La file de travaux est un composant d'exploitation, pas une case à cocher : il faut un processus qui l'exécute, une surveillance des tâches en erreur, et une politique de reprise.
• L'exécution sans processus dédié est le mode le plus simple et le moins performant : elle convient à quelques dizaines de tâches, pas à quelques milliers.
• Sans contrôle des abonnements, une file en erreur inonde la boîte d'un administrateur — et finit par être ignorée.
• Le cadre de connecteurs ne connecte aucun système : installé seul, il ajoute un menu vide. Les connecteurs concrets vivent dans d'autres dépôts, avec leur propre rythme de portage.
• Cinq modules de ce lot sont des modules de test (test_queue_job, test_queue_job_batch, test_component, test_connector, et le volet démonstration associé) : leur manifeste dit de ne pas les installer.
• Le fichier d'environnement et le chiffrement ne protègent pas de la même chose : le premier d'une copie de base, le second d'une lecture de base. Les combiner demande un module de plus.
• L'impression serveur dépend d'une bibliothèque Python externe et d'un système d'impression installé sur le serveur : ce n'est pas un paramétrage, c'est une installation.
• Les READMEs de neuf modules de ce lot sont réduits à leur catégorie : ce sont les menus et les manifestes qui en disent la portée.
• Le socle IoT ne parle à aucun appareil : il décrit des appareils, il ne les pilote pas.

Identité technique

Les vingt-sept modules viennent de cinq dépôts OCA, branche 18.0 — queue, connector, server-env, report-print-send, automation et iot —, désormais tous documentés ici. Vingt sont en AGPL-3, sept en LGPL-3. Les dépendances : base, base_sparse_field, base_import, mail, web, product, link_tracker, google_gmail, et la bibliothèque Python pycups pour l'impression serveur.

Voir aussi les briques techniques du serveur et exposer une API depuis Odoo.

Questions fréquentes

Qu'est-ce que queue_job et pourquoi tant de modules en dépendent ?

C'est la file de travaux de fond d'Odoo Community : des canaux qui limitent le parallélisme, des fonctions différables, et des tâches avec leur état et leurs tentatives. Plus de quarante modules communautaires en dépendent, parce qu'un envoi massif, une synchronisation ou un recalcul ne peuvent pas tenir dans la requête de l'utilisateur.

Faut-il un processus dédié pour exécuter la file ?

Pas obligatoirement : queue_job_cron_jobrunner exécute les tâches par le mécanisme d'actions planifiées, sans processus dédié. C'est le déploiement le plus simple et le moins performant — il convient à quelques dizaines de tâches, pas à quelques milliers.

Le module connector connecte-t-il Odoo à une boutique en ligne ?

Non. C'est un cadre : il fournit la file de synchronisation, les événements et les classes de base, mais aucun système concret. Installé seul, il ajoute un menu Connecteurs vide. Les connecteurs concrets vers une boutique ou un moteur de recherche vivent dans d'autres dépôts, avec leur propre rythme de portage.

Comment éviter qu'une base de recette envoie de vrais courriels ?

Avec server_environment et mail_environment : les serveurs de messagerie sont décrits dans un fichier d'environnement lu au démarrage, pas en base. La copie de production pour recette lit son propre fichier, donc ses propres comptes — souvent aucun. C'est la protection la plus simple contre un envoi accidentel.

Peut-on faire sortir une étiquette sans téléchargement ?

Oui, avec base_report_to_printer et base_report_to_label_printer : les imprimantes sont déclarées côté serveur, et le rapport part directement. printing_auto_base va plus loin : l'impression se déclenche à un événement, sans clic. L'ensemble suppose une bibliothèque Python externe et un système d'impression installé sur le serveur.

Se faire accompagner

Ce lot est celui qu'on ne voit pas dans un cahier des charges et qui décide de la tenue d'une instance. Une file de travaux sans surveillance, c'est trois mille courriels qui ne sont jamais partis et personne pour le savoir. Une configuration en base, c'est une recette qui écrit en production.

Nous posons donc la file avec sa surveillance et ses abonnements dès la mise en service, et la configuration hors base avant la première copie pour recette — dans cet ordre, parce que l'incident arrive toujours avant qu'on y pense. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Les briques techniques du serveur Odoo
• Exposer une API depuis Odoo

En résumé

Sous les modules métier se tient un socle que personne ne demande et dont tout dépend : une file de travaux de fond, un cadre de connecteurs, un moyen de sortir les secrets de la base, et une imprimante qui sort une étiquette sans navigateur. Vingt-sept modules le composent. Parlons de votre exploitation.