Modèle de données
- Former user (Deleted)
- Former user (Deleted)
- Former user (Deleted)
Exemple d'une interface présentant des données pouvant être consommées par AppScho
Cette page tente de décrire de façon succinte les données minimales nécessaires au bon fonctionnement d'AppScho. Cette liste représente un sous-ensemble des données qui peuvent être fournie par l'ERP d'un établissement, et peut donc être complétée en fonction du besoin.
Le format recommandé pour ces échanges est le JSON à travers HTTP. Pour une interface aussi "simple", nous préférerons une interface REST à un modèle complexe RPC tel que SOAP.
Veuillez noter que pour chaque élément renvoyé par vos systèmes d'information, il est nécessaire de fournir un ID unique afin de permettre à AppScho d'identifier correctement les modifications.
Si cet ID est manquant ou n'est pas unique, vous pourrez rencontrer des problèmes liés aux notifications présentées à vos utilisateurs.
Authentification utilisateurs
Deux possibilités s'offrent à nous ici :
Utiliser un système d'authentification géré par l'outil établissement.
Ici, l'utilisateur concerné est intrisèquement identifié par le token d'authentification généré et fourni par l'outil établissement.
Authentifier l'utilisateur côté AppScho et faire en sorte que l'outil établissement fasse confiance aux requêtes faites par AppScho.
Dans ce cas, les requêtes à l'API contiendrait l'identifiant de l'utilisateur concerné en paramètre.
Vous pouvez retrouver des détails sur certaines méthodes d'authentification supportées dans la section dédiée de cette documentation.
Informations utilisateurs
Une fois l'utilisateur connecté, nous avons la possibilité de récupérer des informations sur sa personne et son profil au sein de l'établissement. Les données essentielles étant les suivantes :
le prénom
le nom
D'autres données annexes et / ou composites peuvent être fournies dans cette réponse, par exemple :
la photo
le programme d'inscription
la promotion
le profil de l'utilisateur (pouvant conditionner l'affichage de l'application - à définir avec vos partenaires projets AppScho) .Valeurs possibles :
student
teacher
staff
alumni
une liste de groupes desquels l'étudiant fait partie (cette liste de groupes est utilisée par les systèmes de push d'iOS et Android, de ce fait, ils doivent rester des ID simple (lettre, chiffres, et tirets)
{
"firstname": "Antoine",
"lastname": "POPINEAU",
"picture": "https://server.school.com/xxx.png",
"program": "Master in Management",
"promotion": "2019",
"profile" : "student", "groups":
[
"master",
"master-management",
"promotion-2019"
]
}Audiences
En plus des groupes renvoyés à travers les informations utilisateurs (voir ci-dessus), il est nécessaire de nous mettre à disposition la liste intégrale des groupes disponibles (afin de les afficher aux administrateurs de la plateforme My AppScho. Ces groupes doivent posséder un nom commun ainsi qu'un ID (qui est celui renvoyé pour l'utilisateur) :
[
{
"id": "master",
"label": "Etudiants en master"
},
{
"id": "master-management",
"label": "Etudiants du master en management"
}
]Bibliothèque
Nous pouvons afficher les prêts et les réservations des étudiants dans vos bibliothèques.
Prêts
Pour les prêts, vous pouvez fournir un flux comprenant une liste d'éléments avec les champs visibles ci-dessous. Les champs obligatoires sont :
id (doit être différent pour chaque élément)
title
renewable
return_by
[
{
"id": "string",
"title": "string",
"subtitle": "string",
"author": "string",
"return_by": "2019-return_by08-24T14:15:22Z",
"library": "string",
"renewable": true,
"renew_url": {
"kind": "webview",
"url": "/context/1234/renew"
}
}
]Réservations
Pour les réservations, vous pouvez fournir un flux comprenant une liste d'éléments avec les champs visibles ci-dessous. Les champs obligatoires sont :
id (doit être différent pour chaque élément)
title
available
Notes
Ici, nous devons récupérer une liste d'éléments pour un étudiant. Les champs sont :
un identifiant unique (obligatoire)
un titre (obligatoire)
une note
une description
un coefficient
le nombre de crédits obtenus
le nombre de crédits total
des éléments enfants (pour avoir une hiérarchie de notes)
Ces examens peuvent être organisés en une hiérarchie permettant le classement en années, semestres, groupes, etc. Nous recommandons de limiter au possible la profondeur hiérarchique afin d'optimiser l'usage sur mobile (par exemple Année > Semestre > Matière > Examen).
Emploi du temps
L'emploi du temps consiste en une liste d'événements comprenant les informations obligatoires suivantes :
un ID unique pour l'événement
le nom de l'événement
la date et heure de début
la date et heure de fin
L'ID unique à renvoyer avec l'événement nous est utile afin de déterminer si un événement a été modifié (nous comparons les champs pour les événements possédant le même ID). Il est donc important que cet ID ne change pas lorsqu'un événement est modifié.
Le format pour les dates renvoyées importe peu tant que celui-ci est précis (avec fuseau horaire).
Chaque événement peut aussi, si disponibles, inclure les informations suivantes :
le nom de la salle où se situe l'événement
le nom du professeur
une description plus complète de l'événement
un lien vers une plateforme LMS
un lien de visioconférence
la couleur hexadécimale que doit prendre l'évènement dans le planning
Alertes Personnalisées
Nous récupérons ici une liste d'alertes. Chaque alerte possède un ID unique, un titre ainsi qu'une description. Elles seront affichées directement sur le tableau de bord de l'application.
Absences
Une liste d'absences comprenant, au minimum, les données suivantes :
le nom du cours concerné
la date et l'heure de l'absence
un booléan indiquant si l'absence est justifiée ou non
Optionnellement, une absence peut contenir les attributs suivantes :
la justification de l'absence
Annuaire
L'annuaire peut avoir une ou deux interfaces différentes.
L'interface indispensable concerne la recherche. Un paramètre fournit la chaîne de caractères recherchée, encodée pour être contenue dans une URL (et donc pouvant contenir des espaces). Par exemple
/directory/search?term=antoine%20popineau. Cet endpoint doit renvoyé une liste d'entités répondant au critère de recherche, par exemple :
Documents
La liste de documents doit être organisée de manière similaire aux notes, à savoir une hiérarchie de descripteurs de documents, qui sera répliquée dans l'application de l'utilisateur.
Chaque niveau peut contenir des enfants (dans ce cas, le niveau en question est un dossier). Si un noeud de l'arbre ne contient aucun enfant, il s'agit un document et doit donc contenir des information supplémentaires décrivant le document en question. Un point important est à noter : le document doit être téléchargeable à travers HTTPS directement par le terminal mobile, cela signifie une de deux choses : celui-ci est accessible publiquement, sans authentification, ou être authentifié directement à travers des paramètres fournis dans l'URL du document.
Il est possible d'indiquer, à travers un attribut spécifique (ici filename) le nom que doit avoir le fichier une fois téléchargé, dans la mesure du possible.
Paiements
La fonctionnalité Paiements affiche deux types d'informations :
une liste de "situations" permettant d'afficher au moins un solde
une liste de paiements et leurs états respectifs
Ces informations peuvent être renvoyées dans un seul appel ou deux appels différents, en fonction de ce qui est plus pratique côté établissement.
Un élément de situation doit contenir les éléments suivants :
ID unique
Titre
Description
Solde (positif ou négatif)
Un élément de paiement doit contenir les éléments suivants :
ID unique
Titre
Description
Montant
Booléen indiquant si le paiement a été réalisé
Booléen indiquant si le paiement a échoué
Date de paiement
Suivi administratif
Le suivi administratif présente une liste d'étapes que l'étudiant doit remplir (généralement, des document à renvoyer et qui doivent être vérifiés et affiche le status de ceux-ci ainsi que des éléments explicatifs (PDF et/ou vidéo) sur le processus.
Nous pouvons récupérer ces informations grâce à un modèle similaire à celui-ci :
Prochains passage des transports en commun
Nous tentons généralement de récupérer ces informations directement depuis des API temps réel fournies par les sociétés de transports en commun locales à vos établissements, si celles-ci existent. Nous pouvons également, si nécessaire, utiliser des API que vous auriez développé afin de récupérer ces mmes informations.
Les données à renvoyer doivent prendre la forme d'une liste de passages à venir pour un ou plusieurs arrts autour de votre campus, contenant les informations ci-dessous :
Nom de la ligne
Nom de l'arrêt
Direction
Horaire de passage (complet avec date, heure, et fuseau horaire)
Couleur de fond du logo de la ligne
Couleur du texte du logo de la ligne
Coordonnées GPS de l'arrêt
Menus des restaurants
Cet exemple de modèle de données peut etre ignoré si vous souhaitez qu'AppScho intègre les restaurants et menus publiés dans l'Open Data du CROUS : liste de restaurants et liste des menus
Si, en revanche, vous désirez mettre à disposition vos propre données, ce modèle doit etre respecté.
La récupération des menus des restaurants se déroule en trois étapes :
La liste des campus / CROUS
La liste des restaurants par Campus
Le menu pour chaque restaurant
Liste des Campus (ou CROUS)
Cette étape sert à présenter l'utilisateur avec un menu de sélection pour passer d'un "groupe" de restaurant à l'autre. Ces groupes représentent généralement des campus ou des régions.[
Chaque ID ici sera utilisé dans les requetes suivantes afin d'interroger la liste des restaurants par groupe.
Liste des restaurants par groupe
Cet appel doit retourner la liste des restaurant pour un groupe donné (la manière de transmettre l'ID du groupe dépendra de l'implémentation et est laissé à la discrétion de l'éditeur).
Chaque restaurant doit comporter les éléments suivants :
Un ID unique identifiant le restaurant
Un nom
Une photo (optionnel)
Une adresse (optionnel)
Des coordonées GPS (optionnel)
Un commentaire (optionnel)
Une indication de l'état actuel d'ouverture du restaurant
L'état d'ouverture du restaurant par jour de la semaine et par tranche horaire (de lundi à dimanche, pour le matin, midi et le soir)
Menu pour un restaurant
Pour un restaurant donné (identifié par son groupe et son ID unique), son menu doit pouvoir etre interrogé, retournant, pour chaque jour, pour différentes périodes, des sections (par exemple, entrée, plat et dessert) contenant des éléments.