Techniques d'intégration du SI dans les briques applicatives
17 Janvier 2019
Vincent Bonamy
Pascal Rigaux
Techniques d'intégration du SI dans les briques applicatives
Plan
Introduction
Exemples de cas d'usages avec Apogée
Intégration faible
D'un point de vue théorique
D'un point de vue technique
Intégration forte
D'un point de vue théorique
D'un point de vue technique
Propositions
Conclusion
Introduction
Une des valeurs ajoutées de nos applications métier ESR == intégration au SI, et notamment au SI 'étudiant'.
La généralisation de CAS, Shibboleth, Ldap, Supann permet d'avoir un référentiel standardisé pour l'authentification et l'identification :-)
Pour des raisons techniques et/ou fonctionnelles ce référentiel d'authentification/identification ne suffit pas toujours ; une interaction spécifique entres les briques logicielles est alors requise.
Exemples de cas d'usages avec Apogée
Gestion du compte informatique de l'étudiant.
Etre averti de l'inscription d'un étudiant dans Apogée
Récupérer les informations nécessaires à la création de son compte (email, nom, prénom)
Possibilité de retrouver ces comptes dans cette application de gestion de comptes
Resynchronisation des comptes en cas de modification
Affichage des notes d'un étudiant
Etre averti d'une nouvelle note
Récupérer la note
Cartes Multi Services
Etre averti que l'inscription est validée/payée
Récupérer les informations d'inscriptions
Pouvoir retrouver les cartes dans cette application sur des critères liés à l'inscription (ufr, année, ...)
Etc.
Intégration faible
D'un point de vue théorique
On récupère à l'instant t la donnée pour l'utiliser et l'afficher directement.
Le requêtage à l'instant t peut aussi permettre de faire une recherche plus globale sur la base Apogée.
Avantages : intégration simple et rapide.
Inconvénients : intégration limitée
pas de recherche complexe entre Apogée et données de la base applicative
ou/et problèmes potentiels de performances voir de disponibilités.
Intégration faible
D'un point de vue technique
On fait une requête SQL/SOAP/REST pour récupérer l'information voulue (ex: notes de l'utilisateur) et les afficher.
On fait une requête SQL/SOAP/REST pour récupérer de's informations en fonction de paramètres de la requête.
Ces résultats sont ensuite consolidés avec les informations issues de la base de données de l'application.
Intégration forte
D'un point de vue théorique
On synchronize 'régulièrement' les données dans la 'base de données' de l'application.
Régulièrement = tous les x temps, ou encore à chaque 'mouvement' (~ notion de trigger).
Avantages :
possibilités de recherche, affichage, interactions optimales
solution robuste
intégration dans la même application d'autres briques applicatives (ldap, harpege, sifac, ...) par le même procédé n'impacte pas non plus la disponibilité, stabilité, performance
Inconvénients : synchronisation régulière à coder et réaliser -> consommateur de cpu, réseau, disque, ...
Intégration forte
D'un point de vue technique
Requêtes SQL/SOAP/REST via un CRON like pour récupérer toutes les informations qui peuvent être utiles.
~ Trigger like sur Apogée pour signifier un changement sur une entité (étudiant) à l'application.
-> C'est l'application qui récupère ce dont elle a besoin (pull et pas push)
Requêtages / affichages en utilisant les données synchronisées en local (en base de données).
Conclusion
pas de solution ultime parfaite, suivant les besoins, les intégrations faible à forte ont chacunes leurs avantages/inconvénients
Faire simple mais souple
Se rappeler que PC-SCOL, Apogée, applications esup, etc. ne sont chacune qu'une brique parmi d'autres
-> une application de gestion de comptes intègre apogée, mais aussi harpege, ...
