Certains d'entre nous ont utilisé, avant que Moodle ne développe son offre de web services l'adaptation de notre regrété Patrick Pollet (wspp).
Cette proposition d'API de web services avait des avantages :
- Fourniture d'un WSDL complet sur la description d'API
- Des signatures de fonction plus flexibles (*)
Et des inconvénients :
- La WSDL était contextuelle au site. Il faut la modifier pour chaque nouveau domaine
- Uniquement SOAP, ce qui impose d'avoir une implémentation cliente SOAP côté controlleur
- Exotique dans sa construction reposant sur un framework tiers (OKTech - solide cependant, mais qui arrive en concurrence de la stratégie standard de web services de Moodle 2)
Le problème de maintenance de WSPP et son approche ancienne me conduisent à développer une nouvelle couche complémentaire de web services dont le but est :
- De compléter certaines carences sur des primitives utiles qui correspondent à des cas d'usages avérés, mais situés (en responsabilité) dans des composants du core.
- De garantir une flexibilité totale des APIs, notamment en ce qui concerne les identifiants des objets métiers.
(*) L'API WS de Moodle couvre une bonne partie des besoins de manoeuvre des données dans Moodle. Le problème avéré de l'API standard est de ne compter le plus souvent que sur les ID internes de Moodle pour identifier les objets (cours, catégorie, roles, etc.). Ceci impose aux systèmes tiers de commande d'avoir eux même à gérer la double correspondance entre leur identifiants métiers locaux et des ID numériques de base de données internes (ce qui n'est franchement pas une bonne idée), alors que Moodle a déjà prévu en général (idnumber) d'entretenir lui-même cette correspondance.
La construction de cet ensemble de façade de sevices (implantée dans le composant tiers admin/tool/sync) appliquera les principes suivants :
- Si une fonction WS standard effectue le traitement, alors l'alternative réutilisera le traitement standard
- Pour tout identifiant d'objet métier (utilisateurs, cours, catégorie, cohorte, role, etc.) chaque paramètre d'identité sera doublé d'un paramètre de source (voir l'exemple ci-dessous) permettant de choisir la source de l'identifiant.
- Tous les identifiants disponibles doivent être implémentés comme source
- La fonction effectue tous les contrôles de validité et de vérification de disponibilité des objets identifiés
Exemple :
fonction originale :
enrol_manual_enrol_users($enrolments)
permet d'inscrire des étudiants, mais uniquement à partir des id numériques internes de role, cours et user.
Une première fonction déduite de ce modèle :
tool_sync_enrol_user_enrol($roleidsource, $roleid, $courseidsource, $courseid, $useridsource, $userid, $method, $timestart, $timeend, $suspend)
roleidsource, courseidsource et useridsource accepteront les différents identifiants possibles pour les objets métier concernés :
- roleidsource : id, shortname
- courseidsource : id, idnumber, shortname
- useridsource : id, idnumber, username, email
Le but de cette adaptation est de rendre plus simple le développement côté ERP et de permettre à ce dernier de travailler directement avec ses références internes, sans avoir à gérer la maintenance d'une correspondance non pertinente et risquée à maintenir.
Les avantages de l'implémentation WSPP doivent être conservés autant que possible :
- Préserver l'invocation SOAP (Le moteur de WS standard de Moodle nous offre la couche SOAP)
- Publier la WSDL, si possible auto adpatative sur le domaine d'exploitation du Moodle.