Concepts du connecteur

Le framework pour développer des connecteur est découplé en composants interagissant ensemble. Chacun d’eux peut être utilisé ou non dans une implémentation.

Un exemple d’implémentation est le Connecteur Odoo Magento.

Ce document les décrit d’un point de vue haut-niveau et donne des pointeurs vers des « how-to » plus concrets ou de petits tutoriels.

Événements

Les événements sont des points d’accroche dans Odoo sur lesquels on peut brancher des actions. Ils sont basés sur le motif de conception « Observateur ».

L’idée de base est de déclarer un Event, par exemple on_record_create. Grâce à ceci, chaque connecteur a la possibilité d’abonner une ou plusieurs fonctions sur l’événement. La création de l’enregistrement doit alors exécuter on_record_create, qui va déclencher toutes les fonctions abonnées.

Le même événement peut être partagé entre plusieurs connecteurs, facilitant ainsi leur implémentation. Par exemple, le module connector_ecommerce qui est une extension du framework avec des capacités courantes pour le e-commerce, ajoute ses propres événements dédiés au e-commerce.

Un développeur de connecteur est principalement intéressé par :

  • abonner une nouvelle fonction à un événement (voir connector.event.Event)

  • désabonner une fonction d’un événement (voir connector.event.Event.unsubscribe())

  • remplacer une fonction consommatrice par une autre (voir connector.event.Event)

  • filtrer les événements par modèle, de sorte qu’une fonction abonnée ne soit déclenchée que pour l’événement d’un modèle particulier

Queue de jobs

Cette section résume le principe des queues de jobs, qui s’articule autour de quelques classes, dans les grandes lignes, les Job sont exécutés par un Worker qui les stocke dans une JobsQueue.

Les jobs son stockés dans le modèle QueueJob.

Les workers sont stockés dans le modèle QueueWorker. Un WorkerWatcher crée ou détruit de nouveaux workers quand de nouveaux Registry sont créés ou détruits, et signale si les workers sont en vie ou non.

Les jobs sont affectés à un worker dans la base de données par une tâche récurrente (cron). Le worker charge en mémoire tous les jobs qui lui sont affectés, dans la JobsQueue. Quand un worker s’arrête, il est supprimé de la base de données, de façon que les jobs soient libérés et affectés à un autre worker.

Si plusieurs processus Odoo sont en marche, il y a un worker par processus, mais seuls ceux qui sont des CronWorkers traitent les jobs dans la queue, pour éviter d’encombrer les processus HTTP.

Un développeur de connecteur est principalement intéressé par :

  • Déporter un job (voir le décorateur job())

Session

Une ConnectorSession est un conteneur pour les classiques cr, uid, context utilisés dans Odoo. Maintenant il contient l’Environment Odoo dans self.env. Nous les utilisons au sein des connecteurs.

Backend

Un Backend est une référence à un système ou service externe à OpenERP.

Un backend est défini par un nom et une version. Par exemple Magento 1.7.

Une référence peut avoir un parent. L’instance Magento 1.7 est fille de Magento.

Les classes ConnectorUnit sont inscrites dans les backends. Ceci permet de récupérer une classe inscrite dans le backend. Si aucune classe n’est trouvée, elle est cherchée dans le backend parent.

Il est toujours accompagné d’une sous-classe concrète du modèle connector_backend.

Un développeur de connecteur est principalement intéressé par :

Environnement

Un Environment est le périmètre à partir duquel nous allons faire des synchronisations.

Il contient un Backend, un enregistrement d’une sous-classe concrète du modèle connector_backend, une Session et le nom du modèle avec lequel travailler.

Un développeur de connecteur est principalement intéressé par :

ConnectorUnit

Les ConnectorUnit sont des classes modulables utilisées pour la synchronisation avec des systèmes externes.

Le connecteur définit des classes de bases que vous pouvez trouver ci-dessous. Notez que vous pouvez aussi définir vos propres ConnectorUnits.

Mappings

La classe de base est connector.unit.mapper.Mapper.

Un mapping convertit un enregistrement externe en un enregistrement Odoo et inversement.

Il prend en charge :

les mapping directs

Le champ a est écrit dans le champ b.

Les mapping par méthode

Une méthode est utilisée pour convertir un ou plusieurs champs en un ou plusieurs autres champs, avec transformation éventuelle. Il peut être filtré, par exemple appliqué uniquement lorsque l’enregistrement est créé ou quand les champs source sont modifiés.

Sous-mapping

Un sous-enregistrement (ligne d’un bon de commande) est converti grâce à un autre Mapper

Synchroniseurs

La classe de base est connector.unit.synchronizer.Synchronizer.

Un synchroniseur définit le flux de la synchronisation avec un backend. Il peut correspondre à un import ou un export, une suppression de quelque chose, ou n’importe quoi d’autre. Par exemple, il peut utiliser les mappeurs pour convertir des données entre les deux systèmes, les adaptateurs de backend pour lire ou écrire les données sur le backend et les binders pour créer le lien entre eux.

Adaptateurs de backend

La classe de base est connector.unit.backend_adapter.BackendAdapter.

Un adaptateur externe possède une interface commune pour parler avec le backend. Il traduit les commandes basiques (recherche, lecture, écriture) vers le protocole utilisé par le backend.

Binders (Liants)

La classe de base est connector.connector.Binder.

Binders are classes which know how to find the external ID for an Odoo ID, how to find the Odoo ID for an external ID and how to create the binding between them. A default implementation is available and can be inherited if needed.

Bindings (Liaisons)

Ici, un « binding » signifie le lien d’un enregistrement entre Odoo et un backend.

L’implémentation proposée pour les connecteurs utilise largement les capacités de l’_inherits.

Disons que nous importons un client depuis Magento.

Nous créons un modèle magento.res.partner, qui _inherits res.partner.

Ce modèle, appelé modèle de binding (liaison), connaît les ID du partner dans Odoo, l’ID dans Magento et la relation avec le modèle backend.

Il stocke également toutes les métadonnées nécessaires à ce client venant de Magento

Point de contrôle

Un point de contrôle est un enregistrement du modèle connector.checkpoint lié à un modèle et un enregistrement. Les connecteurs peuvent en créer de nouveaux quand l’utilisateur a besoin de vérifier des documents importés.