Projet

Général

Profil

Evolution #23000

Evolution #12330: Source d'Item différente de posh-profil

Formaliser un webservice de récupération des ressources

Ajouté par Renaud Dussol il y a environ 6 ans. Mis à jour il y a presque 5 ans.

Statut:
A étudier
Priorité:
Haut
Assigné à:
Version cible:
-
Début:
06/02/2018
Echéance:
% réalisé:

0%

Distribution:

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)

Formats disponibles : Atom PDF