Lutece : guide intégrateur
Paramétrer un processus de gestion de demande
Pour illustrer un processus de gestion de demande avec Lutèce, nous allons nous appuyer sur le projet de mise en place d'un guichet permettant de centraliser un ensemble de demandes et de types de demandes (qui peuvent être sur des sites distants ou bien sur le même site).
Exemple :
- un formulaire est un type de demande (plugin-form, plugin-appointment pour une demande de rendez-vous)
- une réponse au formulaire est une demande
Ce cas d'utilisation répond au besoin où les gestionnaires doivent interagir avec les utilisateurs Front-Office sur leurs demandes.
Le Guichet est un simple portail permettant à l’usager :
- d’accéder aux différentes démarches administratives en ligne de la ville de Paris via des téléservices,
- de remplir ses demandes en plusieurs fois en enregistrant éventuellement des brouillons,
- de retrouver l'historique de ses demandes dans un espace personnel,
- d’être informé de l'état d'avancement de l'instruction de ses demandes.
L’accès à la majorité de ces services est soumis à authentification au moyen d’un compte que l’usager aura préalablement créé en ligne.
Le diagramme suivant résume l'exemple ci-dessus :
La partie front-office se présente sous cette forme à l'usager :
Architecture
Il est possible de coupler ces composants avec tout type d'authentification, l'idéal étant d'utiliser un module d'authentification permettant à l'usager de ne se connecter qu'une fois (SSO), pour pouvoir naviguer d'un téléservice à un autre.
Il est souvent plus intéressant de séparer les fonctionnalités entre plusieurs instances de Lutèce, pour faciliter les opérations de maintenance, l'évolution des composants, l'arrêt ou la mise en place d'un nouveau service n'ayant pas d'impact sur ceux déjà en place.
Dans l'exemple ci-dessous, le schéma présente la création de diverses instances qui ont été nécessaires à la réalisation d'un site de demandes avec suivi. Ce projet utilise à la fois des plugins standard et paramétrables comme les formulaires (plugin form) et des plugins développés pour des besoins particuliers. Il est tout à fait envisageable d'intégrer d'autres plugins pour répondre à d'autres besoins, comme par exemple le plugin appointment pour intégrer une demande de rendez-vous dans son portail d'accès.
Etude de cas : mettre en place une plate-forme d'appels à projets
La présente étude de cas porte sur une plate-forme d'appels à projets réalisée dans le cadre du dispositif « Paris Jeunes ». Elle couvre à la fois la partie dépôt des dossiers en ligne par les candidats et l'instruction des dossiers par les gestionnaires et les différents jurys.
Interface candidat
Le candidat doit pouvoir accéder au dépôt et au suivi de son ou ses dossiers par le biais d'un compte unique authentifié , commun à l'ensemble des dispositifs et qu'il peut se créer lui-même.
Il doit pouvoir créer un ou plusieurs dossiers de candidature, les visualiser dans leur état en cours ou validé, les compléter ou les supprimer.
La saisie des dossiers doit pouvoir se faire par étape, avec une sauvegarde d'un dossier à l'état brouillon à chaque étape. Ce brouillon doit être accessible pour être complété lors d'une connexion ultérieure.
Les dossiers pouvant comprendre des pièces jointes lourdes (documents audio ou vidéo), le téléchargement de ces documents doit pouvoir se faire au fil de l'eau et non au moment de la validation finale. De plus l'interface de chargement doit présenter une jauge de progression permettant à l'utilisateur de suivre la bonne réalisation du téléchargement.
La gestion du compte utilisateur doit prévoir : l'activation du compte pour retour d'email, gestion du mot de passe perdu par procédure de réinitialisation à partir d'une URL temporaire.
Interface de gestion
Les gestionnaires ont accès à l'ensemble des dossiers validés par les candidats. Ils peuvent demander des compléments d'informations aux candidats, rejeter des dossiers ne remplissant pas les conditions d'éligibilité. Ils peuvent télécharger pour un ou plusieurs candidats un dossier sous forme d'un fichier d'archive contenant un document PDF contenant l'intégralité des informations du candidat et l'ensemble des pièces annexes comme les œuvres à juger.
Interface Jury
Les membres du jury appartiennent à différentes commissions et disposent d'un compte d'accès pour visualiser tous les dossiers des candidats concourant dans leurs commissions. Ils peuvent télécharger pour chaque candidat un dossier sous forme d'un fichier d'archive contenant un document PDF contenant un extrait des informations du candidat et certaines pièces annexes comme les œuvres à juger.
SOLUTION MISE EN ŒUVRE
Interface candidat
L'interface candidat est architecturée autour des plugins suivants :
• MyLutece pour l'authentification
• CRM pour la gestion de la création des dossiers, de la gestion des dossiers en cours et du suivi des dossiers validés.
• FormEngine comme moteur de formulaire à étapes. Chaque formulaire correspondant à un des dispositifs est un module de Formengine. Il serait possible d'uiliser le plugin-form pour un cas de formulaire sans validation intemrédiaire entre les étapes, par simple paramétrage.
Interface gestionnaires
Les dossiers validés sont transférés dans le plugin Directory qui permet leur suivi par un workflow et toutes les opérations d'édition et d'extraction. Le transfert est réalisé par des Web services REST mettant en œuvre le module OutputWS de FormEngine et le module REST de Directory.
Interface Jury
L'interface Jury est réalisée par un plugin spécifique qui interroge la base des dossiers gérée par Directory à l'aide de webservices REST et filtre les dossiers en fonction du rôle de l'utilisateur.
ÉLÉMENTS SPÉCIFIQUES
Les éléments spécifiques à la plate-forme sont les trois formulaires FormEngine et l'interface de consultation des dossiers du jury. La charge de réalisation de ces éléments a été de 8 jxh par formulaire et 12 jxh pour l'application de consultation.
ÉLÉMENTS GÉNÉRIQUES
Liens documentaires de référence :
http://dev.lutece.paris.fr/plugins/plugin-formengine/fr
http://dev.lutece.paris.fr/plugins/module-formengine-outputws/fr
http://dev.lutece.paris.fr/plugins/plugin-directory/fr
http://dev.lutece.paris.fr/plugins/plugin-workflow/fr
Liens documentaires vers guides d'intégration :
http://wiki.lutece.paris.fr/lutece/jsp/site/Portal.jsp?page=wiki&page_name=howto_rest&view=page
SCHÉMA GÉNÉRAL D'INTÉGRATION
Configuration du pom.xml
Pour créer un site de suivi de demandes, un assemblage de plugins est nécessaire, certains obligatoires pour les fonctionnalités de base, d'autre en option pour augmenter le nombre de fonctionnalités du site.
Composants obligatoires
| Composant | Description |
|
Core |
Composant coeur |
|
plugin-crm |
"Client Relation Management" : Ce composant permet de réaliser la centralisation des types de ressources et des ressources |
|
plugin-rest |
Ce composant permet d'établir des communications avec les sites externes par la représentation architecturale REST. Voir le Guide de développement Lutece - chapitre Créer des Web Services Rest pour plus d'information. |
|
module-crm-rest |
Ce composant permet de recevoir des communications externes pour le plugin-crm, en l'occurrence pour une mise à jour des ressources, pour un envoie d'une notification d'une ressource. |
|
plugin-mylutece |
Ce composant permet d'avoir une gestion des utilisateurs en Front-Office du site Guichet Unique, ce qui est nécessaire pour regrouper un ensemble de ressources pour un utilisateur donné. |
|
module-mylutece-xxx |
Le plugin-mylutece ne peut fonctionner seul. Il faut également un module d'authentification MyLutece. Un exemple de module simple est le module-mylutece-database. |
|
library-httpaccess |
Cette bibliothèque permet de réaliser des opérations par Web Service. |
|
library-signrequest |
Cette bibliothèque fournit une API pour définir des services d'authentification de requêtes HTTP. En d'autres termes, elle est utilisée pour avoir une sécurité sur les communications entre les diverses applications par Web Service REST. La library-httpaccess en est dépendante. |
Composants optionnels
| Composant | Description |
|
module-mylutece-notification |
Ce composant permet aux utilisateurs MyLutece d'avoir une boîte au lettre générique qui leur permet de recevoir des notifications venant de l'application ou bien venant d'autres utilisateurs MyLutece. |
|
module-mylutece-rest |
Ce composant permet aux applications externes de récupérer les informations d'un utilisateur (ex : nom, prénom, email, etc...). |
N.B.: Vous pouvez bien entendu ajouter d'autres plugins, comme par exemple le plugin-html, pour la création de contenu.
Vous retrouverez un exemple de POM en Annexe 3
Configuration des fichiers properties et des fichiers XML des plugins
Pour configurer les divers plugins, il faut surcharger les fichiers de properties (avec seulement les propriétés à modifier) dans le dossier WEB-INF/conf/override/plugins/, et les fichiers XML des plugins dans les dossiers WEB-INF/conf/plugins/ et WEB-INF/plugins/
Les fichiers des plugins sont à configurer pour qu'ils puissent entrer en interaction, notamment pour la communication des webservices.
Les fichiers crm_context.xml, crm-rest.xml, crm.properties, httpaccess.properties, mylutece.properties, mylutece-rest.xml sont également à configurer.
Exemple du fichier crm_context.xml (configuration de la clé privée) :
<!-- SignRequest -->
<bean id="crm.hashService" class="fr.paris.lutece.util.signrequest.security.Sha1HashService" />
<bean id="crm.requestAuthenticatorForWS" class="fr.paris.lutece.util.signrequest.HeaderHashAuthenticator" >
<property name="hashService" ref="crm.hashService" />
<property name="signatureElements" >
<list>
</list>
</property>
<property name="privateKey">
<value>change me</value>
</property>
</bean>
<bean id="crm.requestAuthenticatorForUrl" class="fr.paris.lutece.util.signrequest.RequestHashAuthenticator" >
<property name="hashService" ref="crm.hashService" />
<property name="signatureElements" >
<list>
</list>
</property>
<property name="privateKey">
<value>change me</value>
</property>
</bean>