Simplifier la gestion de projets
Un projet multi-membres permet à un même projet d'écrire des données chez plusieurs membres sans avoir besoin de créer un projet spécifique pour chacun des membres.
Sans le projet mutli-membre, un prestataire technique qui développe une passerelle avec un autre système d'information doit demander à son client de :
- mettre en place un projet d'écriture en API,
- configurer le projet d'écriture,
- associer le prestataire à ce projet.
Si par la suite, un nouveau membre Apidae souhaite bénéficier de la même passerelle, il lui faut créer son propre projet, le configurer et associer le prestataire technique à ce nouveau projet. Le prestataire technique devra à son tour configurer un projet spécifique pour ce nouveau client.
Dans le cas d'un projet multi-membres, le prestataire technique créé le projet. Par la suite, il suffira aux nouveaux clients de "s'abonner" à ce projet sans plus de configuration ni d'un côté, ni de l'autre.
Par exemple
Un office du tourisme développe une interface de saisie simplifiée des évènements avec son prestataire technique.
Trois autres offices du tourisme souhaitent eux aussi bénéficier de cette interface, ils s'abonnent au projet. Le prestataire technique obtient immédiatement le droit d'écriture sur le territoire des trois offices. Les Trois offices du tourisme peuvent bénéficier immédiatement de la nouvelle interface.
Quelques points à connaître
Le projet a-t-il vocation à s'étendre ?
Un projet en API d'écriture ne peut pas être converti en un projet mutli-membres après sa création. Il faudra se demander si le projet à vocation à s'étendre à d'autres membres avant la création du projet, ou prévoir de changer de projet au moment de l'extension.
Attention, si le projet change au moment de son extension, il faudra modifier les développements pour prendre en charge un projet multi-membre, une étape que le prestataire technique pourra facturer.
Auteur de la donnée
L'auteur de la donnée peut être défini au niveau du projet dans la configuration technique. Dans ce cas là, l'auteur est toujours le même quel que soit le membre chez qui il écrit. L'auteur sera alors issu du membre qui a créé le projet, mais la responsabilité éditoriale incombe au membre chez qui les données sont écrites. En fonction des données qui seront écrites, il peut être judicieux de passer par une phase de validation des données.
En utilisant une identification par SSO, l'utilisateur est identifié nominativement. L'écriture peut alors être effectuée directement avec le nom de l'utilisateur réel. Dans ce cas là, l'auteur dépend obligatoirement du même membre que celui qui reçoit les données, il utilise seulement un autre moyen pour écrire des données dans Apidae.
Brouillon ou validation directe
Comme pour un projet d'API en écriture classique, la validation de l'écriture d'une donnée dans Apidae peut-être faite, en fonction de la configuration du projet :
- du côté du prestataire technique au travers des API en écriture,
- du côté Apidae avec validation du membre.
Dans le cas d'une validation au sein d'Apidae, les nouvelles données seront soumises sous forme de brouillon jusqu'à validation des demandes d'écriture.
Commentaires
0 commentaire
Vous devez vous connecter pour laisser un commentaire.