Ce projet a été commencé en 2017, installé en début 2018 et comprend 3 parties :

1. Installation d'un serveur Wazo (basé sur Asterisk),
2. Liaison Wazo / Odoo,
3. Création d'un tableau de bord (mini-CTI*) pour :
   • Visualiser les personnes présentes, les appels en cours,
   • Effectuer des transferts d'appel,
   • Changer la règle d'appel entrant.

[*] CTI : Computer Telephony Integration

Voici mes actions effectuées en autodidacte :

• Découverte de l'univers VoIP,
• Installation et paramétrage de Xivo/Wazo avec des tutoriels,
• Tests de différents logiciels VoIP (Jitsi, Yate, CSipSimple)
• Création d'un prototype avec tableau de bord :
  • Affiche les appels en cours,
  • Réalisé avec du polling sur les serveurs,
• Recherche d'informations sur les téléphones SIP (physiques),
• Recherche et choix de librairies Websockets Python (client et serveur),
  • Comparaison modèles threads/async,
• Implémentation d'un serveur multi-threadé en Python,
• Analyse du code Odoo pour :
  • Reprendre et adapter la gestion des configurations au démarrage,
  • Reprendre et adapter la gestion des logs (un logrotate avec module logging),
  • Reprendre et adapter la gestion des interruptions/arrêts,
• Découverte des API Wazo :
  • Authentification,
  • APIs REST pour lire/écrire dans Wazo,
  • Notifications via Websockets,
• Participation aux forums Wazo :
  • Découverte de quelques bugs,
  • Questions, suggestions,
• Installation kvm, avec les conseils précieux d'un ami,

1 - Architecture générale

1. Liaison standard Asterisk / SIP trunk,
2. Liaison standard Asterisk / SIP phone,
3. Liaison standard web Odoo,
4. Appels REST pour lire/écrire dans Wazo,
5. Wazo envoie au serveur CTI les notifications des événements,
6. Appel unique au démarrage de serveur CTI : récupération de la liste des users Odoo et de leur ligne associée,
7. Présence des users odoo via le module 'presence_sip' ; fonctionne tant que la page odoo est ouverte,
8. Affichage de la page web du serveur CTI : tableau de présence,
9. 2 actions :
   • Le serveur CTI envoie aux clients des maj du tableau (appels, status…),
   • Le client envoie au serveur CTI les ordres de transfert d'appel et de changement d'accueil,
10. Recherche du nom correspondant à un numéro de téléphone (sur appel entrant),
11. Click2dial : appel d'un client depuis sa fiche Odoo.

2 - Installation d'un serveur Wazo

Le serveur Odoo existant déjà chez ce client, j'ai installé Wazo et mon mini-CTI sur un autre serveur physique, via kvm.

3 - Liaison Wazo / Odoo

Utilisation de modules OCA pour la téléphonie (base_phone, asterisk_click2dial) qui permettent :

• De définir les liaisons entre Odoo et Asterisk (url, login, password),
• D'appeler un client depuis sa fiche Odoo en 1 clic,
• D'ouvrir la fiche client quand un appel arrive.

4 - Création d'un tableau de bord (mini-CTI)

Il s'agit d'avoir en une page web un maximum d'informations sur la téléphonie et les présences.

Toutes les mises à jours sont faites en "temps réel" via les Websockets. Il y a une gestion de reconnexion automatique si le serveur est temporairement indisponible. L'idée est que l'utilisateur affiche cette page au démarrage de l'ordinateur et n'y touche plus de toute la journée.

Interface

Voici des copies d'écran :

• Ecran défaut : liste des lignes téléphoniques, présence Odoo,
• Sonnerie appel entrant,
• Appel entrant en cours, possibilité de transfert,
• Appel entrant en cours, choix de transfert,
• Sonnerie appel interne,
• Appel interne en cours, possibilité de transfert.

Architecture

Le serveur CTI est écrit en python, multi-threadé :

• Client websocket pour la connexion Wazo (récupération informations lignes et groupes, notifications d'appels, transfert d'appel, changement de groupe),
• Serveur websocket pour gérer les présences Odoo,
  • Avec création d'un module Odoo spécial pour envoyer les présences des utilisateurs Odoo,
• Serveur web pour diffuser la page html du tableau de bord,
• Serveur websocket pour communication directe avec les tableaux de bord clients,
  • Dans la page web du tableau de bord, création de code javascript pour gérer :
    • Les mises à jour (notifications appels, présence Odoo, état des lignes),
    • Les actions utilisateurs (transfert d'appel, changement d'accueil).

5 - Améliorations prévues

• Gestion de la présence : les personnes connectées à Odoo veulent pouvoir préciser si elles sont vraiment joignables, comme dans les messageries instantanées ("Ne pas déranger", "Sorti déjeuner", "Reviens dans xx minutes"...),
• La colonne "Etat" qui indique l'état du téléphone tel que le voit Asterisk, n'est pas pertinente pour des téléphones filaires. Elle n'affiche l'état "Branché" ou "Débranché" en direct uniquement pour les soft-phones (ex CSipSimple pour android). Or le client n'a que des postes filaires. Donc, il faudra soit la masquer, soit faire en sorte qu'elle ne gêne pas la colonne de présence Odoo,
• Permettre de faire des transferts directs ou des transferts avec communication interne.

Pour ce projet, il s'agit de générer des documents PDF dans OpenERP/Odoo en respectant un workflow complexe.

Par défaut, l'impression OpenERP v7 fonctionne encore avec les fichiers OpenOffice sxw ! Mais à partir de la version 4.3 (mi-2014), LibreOffice ne peut plus générer de fichier sxw.

De plus, avec Odoo v8, c'est un toute nouvelle architecture d'impression, basée sur des templates QWeb (à base de html, CSS et de règles spéciales). Le gros désavantage est que seuls des développeurs peuvent modifier ces templates, sans éditeur wysiwyg.

Donc, j'ai dû créer une autre architecture d'impression pour répondre à ces problèmes et gérer un workflow complexe. Elle est développée sous forme de modules Odoo.

Voici mes actions effectuées en autodidacte :

• Tests de construction complète d'un document LibreOffice via pyuno, mais la lenteur était rédhibitoire,
• Tests de appy.pod,
• Gestion de communication entre scripts avec différentes version de Python :
  • Python2 (OpenERP) / Python3 (Libreoffice).

Architecture générale

L'ensemble de l'architecture d'impression est en 2 parties :

1 - Tout d'abord, création du modèle au format odt

1. Créer le contenu habituel avec styles : textes, paragraphes, tableaux,
   • ajouter des champs standards pour les données qui seront remplies par appy.pod,
2. Ajouter les règles appy.pod :
   • Les règles de construction sont définies dans des commentaires standards,
   • Les règles de construction sont définies en "pseudo-python",
   • Ces règles permettent de créer ou masquer des paragraphes, des lignes de tableau ou des sections,
3. Créer le fichier 'modèle.odt'.

Les utilisateurs peuvent modifier ce modèle, il suffit que le développeur vérifie la cohérence du contenu et des règles pour appy.pod.

Voici un exemple de document contenant des champs et des règles pour appy.pod :

2 - Ensuite, en production, le processus complexe est exécuté

1. Démarrage du processus par la réception dans Odoo d'un fichier 'input.xml',
2. Récupération de toutes les données nécessaires dans la base de données,
3. Construction des cartes OSM spéciales,
4. Construction du dictionnaire de "contenu variable" :
   • Données Odoo,
   • Cartes,
   • Données de 'input.xml',
5. Génération du fichier 'complet.odt' par appy.pod avec :
   • Le modèle,
   • Le contenu variable,
6. Transformation 'complet.odt' --> 'complet.pdf' par LibreOffice (via pyuno),
7. Signature numérique du fichier 'complet.pdf' (via un outil externe),
8. Génération d'autre fichier 'output.xml',
9. Vérification du fichier 'output.xml' par XSLT (via un outil externe),
10. Zip des fichiers générés ('complet.odt', 'complet.pdf', 'output.xml') : 'complet.zip',
11. Ajout du fichier 'complet.zip' en pièce jointe dans Odoo,
12. Et pour finir, ces générations complètes doivent pouvoir être faites en direct par l'utilisateur et en automatique via un cron : il faut prévoir que les erreurs éventuelles soient bien affichées ou logguées et que le cron ne soit pas bloqué.

Pour 2 projets différents, j'ai travaillé sur des liaisons entre OSM et Odoo.

Pour cela, il m'a fallu apprendre en autodidacte les sujets :

• Leaflet et ses APIs,
• L'organisation du client Javascript Odoo :
  • Gestion complète d'un contenu spécial (carte OSM),
  • Appel des commandes pour lancer d'autres actions (ex : ouverture d'une fiche client),
• L'architecture générale d'OSM,
• Le système de coordonnées utilisées par OSM,
• Le système de nommage des tuiles OSM et la transformation coordonnées GPS <--> Tuile OSM,
• L'API de géolocalisation Google.

1 - Intégration OSM dans Odoo

Géolocalisation

J'ai dû intégrer la géolocalisation (API Google) pour calculer automatiquement les coordonnées des contacts Odoo en fonction de leur adresse.

Voici un exemple de fiche contact Odoo avec des champs spéciaux ("Longitude" et "Latitude") qui ont été définis automatiquement lors de l'enregistrement de l'adresse postale :

Cartographie

Une fois les coordonnées calculées, il est possible de visualiser les contacts avec des POI sur une carte OSM :

• Les images des POI sont définies par une combinaison de valeurs (ici "Etiquette" et "Classement"),
• Il est possible de filtrer suivant plusieurs critères ("Etiquette", "Classement" et nom),
• Un clic sur un POI affiche un popup qui reprend les informations principales du contact,
• Dans ces informations, il y a aussi un lien ("Fiche") : un clic ouvre la fiche correspondante dans Odoo.

2 - Récupération de tuiles

Lors de la construction des documents Odoo, il a fallu construire différentes cartes basées sur les tuiles OSM.

L'idée générale est : à partir de 1 ou plusieurs points GPS, il faut récupérer les tuiles permettant de construire une image contenant ces points, ainsi que des informations supplémentaires (pictos, légendes...).

Les variantes sont :

1. Avec plusieurs points, il faut une image au format 16:9,
2. Avec un seul point qui sera le centre de l'image et un zoom imposé,
3. Avec un seul point qui sera le centre de l'image et une distance minimale définie par l'utilisateur,

Toutes les opérations graphiques sont faites avec la librairie Pillow : gestion des offscreens, dessin, ouverture d'image, enregistrement d'image. La récupération des tuiles est faite avec la librairie Requests, afin de gérer des éventuels timeouts.

Principe de base

• Chaque variante définit :
  • Le rectangle GPS à récupérer et le zoom en fonction de ses contraintes,
  • Le rectangle final de l'image (en pixels),
• Le rectangle GPS à récupérer et le zoom sont transformés en numéros de tuiles OSM, puis chaque tuile est récupérée et assemblée dans un offscreen (le "fond de carte"),
• Chaque variante dessine dans l'offscreen les différents éléments (points, pictogrammes, légendes...),
• Chaque variante découpe l'offscreen suivant le rectangle final et enregistre l'image correspondante.

Dans les images suivantes :

• La première est la version "debug" (affichage des points demandés et des rectangles calculés),
• La deuxième est la version finale,
• Le quadrillage vert indique les tuiles OSM,
• Les "x" rouges indiquent les points demandés,
• Le rectangle bleu indique le découpage pour obtenir l'image finale.

Variante 1 : plusieurs points, image 16:9

Une image 16:9 contenant tous les points. L'image doit faire au maximum 4 tuiles de coté (soit <= 1024px).

Exemple 7 points autour de la place du Capitole :

Exemple 8 points : ajout d'un point plus éloigné (N7) :

Exemple 10 points : ajout de 2 autres points : Jean Jaurès, Bellegarde (les ateliers de Toulibre) :

Variante 2 : un seul point au centre de l'image et une distance minimale imposée

Une image 16:9 centrée sur un point qui affiche au minimum 350m autour du centre (en horizontal seulement).

Dans la carte debug suivante, vous pouvez voir que le rectangle cherché n'est pas carré, alors qu'on demande une même distance en largeur et hauteur : cela est dû à la la projection Mercator, pour la latitude de la France.

Variante 3 : un seul point au centre de l'image et une distance minimale définie par l'utilisateur

Une image carrée de 925px, centrée sur un point.

Le zoom des tuiles est choisi pour afficher une distance minimale en mètres dans ces 925px (rayon autour du point central).

Exemple Distance défaut

Rayon défaut : 100m, rayon obtenu : 199m

Exemple Distance 50m

Rayon demandé : 50m, rayon obtenu : 99m

Exemple Distance 500m

Rayon demandé : 500m, rayon obtenu : 799m

Exemple Distance 2000m

Rayon demandé : 2000m, rayon obtenu : 3197m

Souvenirs, souvenirs...

C'est un ensemble de 3 logiciels (écrits entre 1988 et 1995 !) :

• Générateur,
• Solveur,
• Post-traitement.

Malheureusement, aucun de ces logiciels ne fonctionne aujourd'hui. Il ne reste que des documents papiers et les manuels utilisateurs en PDF.

Les 2 premiers ont été écrits lors de mes études de mécanique, alors que je n'avais encore jamais eu de cours d'informatique ! Le premier en Pascal procédural. Pour le second, j'ai appris la programmation objet en lisant un maximum d'articles et de livres, puis j'ai mis en pratique en Pascal Objet et MacApp 2.

Voici mes actions effectuées en autodidacte pour les 2 premiers logiciels :

• Participation à la création d'un mini-tableur (sans formules), pour saisir les données,
• Création une visualisation 3D filaire,
• Transposition informatique des formules mécaniques de calcul de structure (d'après bibliographie),
• Gestion de matrices en Pascal Objet (création de matrices locales et assemblage dans des matrices globales),
• Création d'un algorithme de renumérotation de points (pour optimiser la largeur de bande des matrices globales),
• Transposition d'un code fortran d'inversion de matrice en Pascal Objet.

Le troisième logiciel (Post-traitement) a été écrit lors du projet de fin d'études du Mastère en Systèmes Informatiques (1992).

Voici mes actions effectuées en autodidacte pour le troisième logiciel :

• Etude de design, conception d'UI,
• Définition d'une hiérarchie d'objets,
• Implémentation d'un algorithme du peintre pour vue 3D avec faces cachées,
• Définition et Implémentation d'un algorithme de dessin d'isovaleurs pour éléments triangle et quadrangle.

L'idée de base était de permettre à des ingénieurs structure d'effectuer "rapidement" des calculs sur des petites structures, sans passer par les gros logiciels de l'époque (ASELF, NASTRAN), qui pouvaient nécessiter une liste d'attente pour s'y connecter.

1 - Apprentissage du développement sous MacOS

J'avais découvert la programmation avec le Basic. En 1986, au début de mes études de mécanique, j'ai pu acheter un Macintosh 512/800 et j'ai commencé à le programmer en basic pour faire des calculs de mécanique.

Au cours d'un stage, j'ai croisé une personne qui créait sa société de développement de logiciels mécanique pour Macintosh ! Nous avons travaillé ensemble pour créer des logiciels, toujours en Basic.

Mais il est rapidement apparu qu'il fallait créer de "vrais" logiciels Mac, avec menus, fenêtres, dialogues... alors que le runtime Basic avait beaucoup de limitations.

Nous avons donc appris le Pascal ainsi que la programmation de Mac OS par nous-mêmes, pour avoir des fonctionnalités de base :

• Gérer une boucle d'événements,
• Gérer des fenêtres (création, activation, update, déplacement, agrandissement...),
• Gérer le dessin d'une grille dans une fenêtre,
• Gérer le scroll de cette grille, avec les titres et numéros de lignes fixes,
• Gérer une sélection de cellules dans la grille,
• Gérer la saisie de valeurs dans les cellules.

Les ouvrages de référence : "Inside Macintosh", une série d'une dizaine de volumes, en voici 3 :

Un autre ouvrage pour l'apprentissage :

• Vous pouvez découvrir comment était gérée la mémoire : avec des handles (pointeurs de pointeurs),
• Ces handles nécessitaient des traitements particuliers : blocage/déblocage pour pouvoir les utiliser,
• Les structures de données de l'OS étaient totalement transparentes ! on pouvait aller lire et écrire dans tous les records gérés par l'OS ! (exemple du DialogRecord et du WindowRecord),
• Pour finir, un exemple de la fameuse "boucle d'événements" gérée manuellement.

2 - Générateur

A partir de la structure de base (mini-tableur), nous avons permis la saisie des différents éléments (points, barres, poutres, blocages, chargements). D'autres personnes ont travaillé sur la mise en place d'outils de génération automatique de points/éléments (par translation, extrusion, maillages...).

Une fenêtre spéciale permet d'avoir une représentation en 3D filaire. Pour cette vue 3D, nous avons créé notre librairie : à cette époque (1988-1995), OpenGL n'existait que pour les stations de travail (Sun, Apollo, IBM...), mais il y avait quelques articles pour défricher le dessin 3D sur micro-ordinateurs.

Bien sur, les contraintes mémoire et CPU étaient immenses : il fallait limiter le logiciel à quelques centaines/milliers de points/éléments.

Voici quelques pages issues d'un exemple guidé :

Et quelques pages du manuel utilisateur :

3 - Apprentissage de la Programmation Objet et MacApp 2

Avec l'expérience de l'écriture du générateur, il m'est apparu que la programmation procédurale ne convenait pas pour ce genre de logiciels avec interface graphique. De plus, entre 1988 et 1990, il y a eu l'annonce puis l'arrivée des premiers NeXT ! Cela a été la découverte de la programmation objet et j'ai décidé de m'y mettre.

Sur Mac OS, à partir de 1990, on pouvait utiliser un framework objet "MacApp 2", écrit en Pascal Objet. J'ai décidé de l'utiliser pour les futurs développements, notamment le solveur.

Des informations complètes sur ce framework :

MacApp : part 1

MacApp : evolution

4 - Solveur

Bien sur, je n'ai pas écrit un solveur éléments finis de zéro ! Il y avait déjà une littérature importante, décrivant les principes théoriques et la mise en pratique. Certains ouvrages contenaient même des exemples de code (surtout en fortran).

Je suis parti d'un code fortran (du livre "Une présentation de la méthode des éléments finis" de Gouri DHATT et Gilbert TOUZOT) qui gère la résolution d'un système matriciel. Ce code est important car il peut gérer des matrices énormes : il intègre un système de "découpage" des matrices pour qu'un ordinateur puisse effectuer l'inversion de matrices, sans avoir toutes les données en mémoire vive.

Cela correspondait parfaitement aux besoins pour notre logiciel, car Mac OS n'avait pas de système de mémoire virtuelle à cette époque.

Même si j'avais un exemple de code fortran, il me restait beaucoup de travail :

• Analyser et transposer ce code fortran en Pascal Objet,
• Créer un algorithme de renumérotation (pour réduire la largeur de bande de la matrice globale),
• Générer la matrice locale de chaque élément,
• Assembler les matrices locales dans une matrice globale,
• Intégrer les blocages et les chargements dans la matrice globale,
• Lancer l'inversion de la matrice globale,
• Finaliser les calculs,
• Stocker les résultats,
• Créer une interface utilisateur pour afficher la progression des étapes.

Voici quelques pages de mon rapport de stage qui expliquent les principes du solveur et le principe de la renumérotation :

Et voici l'interface du solveur : une grosse fenêtre de progression qui détaille toutes les étapes du calcul :

Avez-vous noté les indications de temps de calcul ?

Oui, vous avez bien lu : pour une structure de 77 points et 60 quadrangles, il fallait 1 minute pour la plus rapide des machines 680x0 et jusqu'à 12 minutes pour la plus lente ! Avec les premiers PowerPC, cela tombait à 17s !

5 - Post-traitement

Il a été écrit lors du projet de fin d'études du Mastère en Systèmes Informatiques (1992).

Recherches pour ergonomie/design

Avant de commencer le développement, il m'a fallu faire des recherches pour l'ergonomie et le design, afin de trouver un "workflow" intéressant.

Finalement, j'ai repris un principe défini par NeXT : l'inspecteur dans une fenêtre flottante.

Voici quelques pages du rapport de stage, qui décrivent ces recherches :

Par rapport au Générateur, le Post-traitement a une visualisation 3D plus évoluée :

• Les élements triangle ou quadrangle sont "pleins" : il faut mettre en place un algorithme de dessin 3D avec faces cachées,
• Mais en plus, le dessin des éléments triangle et quadrangle doit représenter des courbes isovaleurs :
  • Pour le triangle, chaque isovaleur sera simplement une droite,
  • Pour le quadrangle, chaque isovaleur sera une hyperbole.

Vu la complexité et l'importance du dessin des isovaleurs pour les éléments quadrangle, j'ai décidé de prendre l'algorithme simple et rapide du peintre pour le calcul des faces cachées. Même si quelques rares cas étaient mal dessinés (erreur des faces cachées), le principal était d'avoir les courbes isovaleurs précises mais cela augmentait fortement les temps de calcul des images (environ 1 minute pour une centaine d'éléments sur un Mac 680x0).

Logiciel réalisé

Voici des extraits du manuel utilisateur du logiciel réalisé.

Le menu Représentations (tableaux, puis graphiques) :

Les explications de l'inspecteur :

Les paramètres des tableaux :

Les paramètres des graphiques :

Et quelques pages issues de l'exemple guidé :

Voici un des exemples complexes de l'époque : la simulation d'un freinage sur une jante moto :

6 - Conclusion

A partir de 1993, les 3 logiciels étaient prêts pour être commercialisés.

En 1994, les premiers Macintosh avec processeurs PowerPC sont arrivés : j'ai porté le solveur en natif PowerPC et les gains de temps de calcul étaient impressionnants !

Et une grosse reconnaissance : Apple a créé un document à propos des logiciels de calcul et Elefan en faisait partie.

Sur la 3ème page du sommaire, Elefan est cité entre Matlab et Mathematica !

Malheureusement, Apple commençait à rencontrer des difficultés financières et la plupart de nos clients potentiels lançaient des migrations de Mac vers Windows. Cela nous a obligé à arrêter les développements de ce logiciel.

Les ennuis d'Apple ont été tels qu'elle a failli arrêter complètement, ou être rachetée par Sun, ou essayer de remplacer Mac OS 7 par BeOS... Finalement, en décembre 1996, Apple rachète NeXT, Steve Jobs revient, lance l'iMac, Mac OS X... mais c'est une autre histoire !