Project

General

Profile

Evolution #23000

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

Formaliser un webservice de récupération des ressources

Added by Renaud Dussol over 2 years ago. Updated about 1 year ago.

Status:
A étudier
Priority:
Haut
Assigned To:
Target version:
-
Start date:
02/06/2018
Due date:
% Done:

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

History

#1 Updated by Renaud Dussol over 2 years ago

OK sur principe
on verra côté technique (connexion à la base)
éventuellement utiliser le WS de xdesktop déjà existant

#2 Updated by Renaud Dussol over 2 years ago

  • Subject changed from Réaliser un init posh-profil pour les PIA to Réaliser une synchro posh-profil pour les PIA

#3 Updated by Christophe LEON almost 2 years ago

  • Status changed from Nouveau to A étudier

#4 Updated by Renaud Dussol almost 2 years ago

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 Updated by Renaud Dussol almost 2 years ago

  • Subject changed from Réaliser une synchro posh-profil pour les PIA to Formaliser un webservice de récupération des ressources
  • Parent task set to #12330

#6 Updated by Renaud Dussol almost 2 years ago

  • Priority changed from Normal to Haut

#7 Updated by Renaud Dussol about 1 year ago

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)

Also available in: Atom PDF