Evolution #23000
Evolution #12330: Source d'Item différente de posh-profil
Formaliser un webservice de récupération des ressources
0%
Description
Sur le même modèle que l'init ARENA, car l'alimentation par les connexions utilisateurs est difficile à gérer
Limité aux PIA-only, car difficile de prévoir les posh-profils des établissements
Historique
#1 Mis à jour par Renaud Dussol il y a environ 6 ans
OK sur principe
on verra côté technique (connexion à la base)
éventuellement utiliser le WS de xdesktop déjà existant
#2 Mis à jour par Renaud Dussol il y a environ 6 ans
- Sujet changé de Réaliser un init posh-profil pour les PIA à Réaliser une synchro posh-profil pour les PIA
#3 Mis à jour par Christophe LEON il y a plus de 5 ans
- Statut changé de Nouveau à A étudier
#4 Mis à jour par Renaud Dussol il y a plus de 5 ans
L'idée globale sera plutôt de formaliser un modèle WS qui puisse faire transiter les infos aussi bien de poshprofil que de eportail (ou éventuellement, d'une autre source)
Le but ultime étant de pouvoir se passer du xdesktop comme fournisseur WS (ou de garder un "squelette xdesktop" uniquement pour la fonction fournisseur)
Le ou les fournisseurs WS suivraient ce modèle
Idéalement, ce modèle WS serait calqué sur le même schéma que ceux d'ARENA (ressources, favoris, messages)
On pourrait alors avoir un seul client WS dans edispatcher qui prendrait le fournisseur en paramètre d'entrée : ARENA, poshprofil, eportail ou autre...
#5 Mis à jour par Renaud Dussol il y a plus de 5 ans
- Sujet changé de Réaliser une synchro posh-profil pour les PIA à Formaliser un webservice de récupération des ressources
- Tâche parente mis à #12330
#6 Mis à jour par Renaud Dussol il y a plus de 5 ans
- Priorité changé de Normal à Haut
#7 Mis à jour par Renaud Dussol il y a presque 5 ans
Suite à notre discussion aux J-envole, je note en vrac mes réflexions :
le plus standard serait de faire un REST qui répondrait au format suivant :
/typesource/uid/serveur
Ex :
/poshprofil/rdussol/0060087M
ou
/arena/rdussol/proxy-dmz
(ou bien arena/rdussol/internet si on décide de normer les noms des zones)
ou
eportail/rdussol/0060087M
La réponse serait du json avec des paires clé:valeur, qui correspondraient aux champs de la table url (avec quelques infos des tables app et catégorie) de edispatcher
pour arena :
({categorie:"Scolarité du second degré", categorie_arenaid:123456, application:"BEE", application_arenaid:123456, url:"https://id.ac-nice.fr/commun/index.jsp", libelle: "Commun", urlCT:"/commun/index.jsp", resArena:"Scolarité du 2nd degré-sepSIGATsep--sepSIGATsep-/commun/index.jsp", arenaid:123456, host:"id.ac-nice.fr:443"}, {...},...)
pour poshprofil ou eportail :
({etablissement:0060087M, categorie:"Mes Services", application:"nextcloud", url:"https://esterel.ac-nice.fr/nextcloud", libelle: "Nextcloud", host:"esterel.ac-nice.fr"}, {...},...)
A voir si l'on prévoit un service identique pour les favoris et les messages
(On pourrait même prévoir un rest pour la synchro globale : /arena/all, et même un export des données du App Manager)