Analyse protools

# Analyse protools # Les protocoles et les enquêtes ## Différents modes d'enquêtes et différents services à orchestrer * web => Platine (convergé ménage/entreprises/SSM). A priori pas d'utilisation de colleman. * enquêteur(face-a-face et/ou téléphonique) => Sabiane / opale et éditique pour les FA (via beatles). descriptif de l'UE pour l'enqueteur. * courrier/mail => (meshuga passe plat entre nous et éditique ou spoc) A destination de l'enquêté (envoi d'une communcation d'ouverture [vous allez être sollicité par l'enquêteur ; ou voici vos identifiants web ] ou relance ). Plannifié par la matrise d'oeuvre. ## Différentes plannifications (est-ce le bon terme?) * simple * par vagues successives (la même UE est interrogée plusieurs fois) ### Point particulier des réintérrogations La constitution de la liste des UE à remettre en réintérrogation sera faite par kraftwerk. Protools orchestrera des enquêtes * Ménages * Entreprises * **TODO:** issues des SSM (est-ce qu'on peut tous les faire entrer soit dans une case 'ménage', soit dans une case 'entreprise?') Un travail est en cours pour modéliser un ou plusieurs types d'unités enquêtées (UE). Protools devra pouvoir, transformer ces UE (liste fixée et connue) pour les communiquer via les API des applications existantes. ## Moteur d'exécution Suite à l'analyse initiale il a été décidé d'utiliser le moteur Flowable pour exécuter des processus décrits par des fichiers BPMN ( https://fr.wikipedia.org/wiki/Business_process_model_and_notation ). Un même BPMN décrivant un protocole pourra être utilisé pour lancer plusieurs enquêtes, chacune avec son fichier de contexte. ### Le fichier de contexte **TODO:** Que contient il? infos de la campagne; infos pour l'éditique infos pour opale Aujourd'hui, 2 fichiers de contexte différents : https://gitlab.insee.fr/preparation_collecte/protools/documentation/-/tree/main/Mod%C3%A8le%20de%20donn%C3%A9es%20-%20Contexte WebSimple et téléphoneSimple xml: le contexte. ods : analyse champ par champ de l'api où ce champ est mobilisé. 1. Un fichier pour une collecte web : infos platine/colleman + toutes les variables pour l'envoi d'un mail ou d'un courrier. 2. fichier téléphone : tout pour sabiane + opale. On a besoin, au moment du chargement du contexte d'une validation que ce contexte contient bien toutes les informations nécessaires au protocole décrit par le BPMN. Note ACDC : Décrire de façon macro. Ex: CAMME2023 on a les entrants => Mail d'ouverture; réintérro => Leur envoyer juste un mail. On ne donne pas les variables qui permettent d'envoyer un courrier. On a les infos macro (dates d'ouverture d'enquête)... Aucun lien avec ACDC dans un 1er temps. ### Les BPMN * Les BPMN seront dans un premier temps écrits à la main par quentin/audrey. et chargés dans protools via l'imh. * Certains éléments du contexte impacteront l'exécution du BPMN (ex: durée ou moment d'exécution paramétré pour un timer). Ex: au 13 avril, se connecter à Moog, récupérer ceux qui n'ont pas répondu et leur envoyer un mail avec meshuga. * Tous les BPMN générés par bpmn.io sont gérés par flowable. Par contre il faut ajouter ensuite les délégates à la main. * Ya il de la configuration qui doit être faite dans l'IHM ou tout passe il par le contexte? (à priori non, tout serait dans le contexte). Je lance un process [BPMN+contexte]. Il y a un ID dans le contexte. Protools vérifie qu'il n'y a pas déjà un process en cours avec cet ID; si c'est le cas ==> Erreur. * Modélise-on la gestion des erreurs dans le BPMN? A priori oui à quelle granularité. ### Les tâches à orchestrer - Appels d'API - Intégration de fichier (ex: contexte ; éventuellement de BPMN). Entre ces tâches, des données intermédiaires devront pouvoir être stockées dans le contexte de l'application. ex: Un appel à une API renvoie un JSON qui sera utilisé plus loin dans le protocole pour générer le 'body' d'un apptre appel d'API. #### Initialization d'une campagne ## Orchestration **TODO:** Reste il des cas où des applis communiquent directement entre elles ? * BEATTLES -> REM * REM -> Nautile (car hors de notre périmètre) * OPALE -> SABIANE (pour les affectations des UE aux enquêteurs) * Sabiane -> Meshuga (pour faire les envois de lettre avis et relances à la demande de l'enquêteur [non planifié]). * Platine -> Meshuga (courrier ou mail pour réinitiialisation de mot de passe) Relances : Ne concerne que le web. On interroge platine à une date (ou après une durée donnée). On interroge platine pour savoiur s'il faut relancer. Fin : Un endpoint doit être ajouté à sabiane/platine pour nous indiquer que l'UE est 'finie'. A une date donnée protools va interroger ces endpoits pour savoir si l'ue est finie. Ensuite deux possibilités: soit protools passe les résultats à kraftwerk (on peut les récupérer via des appels à pilotage&questionnaire) ou kraftwerk va chercher ces résultats. **A spécifier. Le retour de collecte reste flou. En particulier sur la remise en réintérrogation** ## Stratégie doit on faire un POC sur une enquête simple. Par exemple l'enquête TIC qui a un protocole Web+téléphone avec bascule tel->Web Pour l'instant on voyait 3 BPMN : 1 un échantillon web 2 un échantillon téléphone 1 et 2 ==> 2 collectes en parallele dans protools 3 : les téléphones qui n'ont pas répondu partent en web ==> Bascule entre des phases (BPMN) différents. On a trois 'process' terminés dans protools qui correspondant à 3 listes d'UE dans REM (3 étant une sous partie de 2). Protools n'a pas de lien entre ces listes. Comment est déclenché kraftwerk? Un 4e BPMN qui prendrait en contexte ces lites d'UE?? Ce découpage en BPMN successifs n'est pas mal pour une enquête CAMME qui est une enquête qui ne s'arrête jamais. Cela évite un BPMN infini. # Utilisateurs Utilisateurs de protools IHM : - Maitrise d'oeuvre - Ménage : CPOS/CPIE ; - Entreprise : ? Utilisateurs d'ACDC: Concepteurs d'enquête (celui qui décide de la stratégie et du protocole de l'enquête). C'est un binôme avec le CPOS mais ce sont des utilisateurs différents. ## Bêta testeurs Identifier un/des CPOS & CPIE qui pourront nous faire des premiers retours. ## Informations pertinentes **TODO:** que doivent ils pouvoir voir dans l'IHM Protools? 1 : Avancée du BPMN 2 : Erreurs 3 : Rapport final ? Quel format? Quelles infos pertinentes? => On va attendre les retours des premiers utilisateurs ## Actions possibles via l'IHM protools **TODO:** Quelles sont les actions manuelles des utilisateurs? - Créer un nouveau processus & Charger le contexte de ce processus ensuite les déclenchements dépendent des dates configurées dans le contexte - Tâches manuelles type 'feu vert' comprises dans le BPMN - ex: dernière tâche avant de clore : suppression des données sur les plateformes. - Liste des actions possibles sur une UE 'en erreur' : - Les actions sont elles UE par UE ou globales? - Relancer la/les tâche en erreur - Annuler l'UE - Permet on de recharger une UE dans REM (suite à une correction) ? Est-ce atomique? opération sur plusieurs UE en même temps? Peut on interrompre globalement l'exéction du sous-process de toutes les UE en cours de traitement ? ## Gestion des droits - Tous les 'utilisateurs' protools ont le droit de démarer un nouveau processus. Ces utilisateurs ont un des rôles authorisés pour KC. - On a rôle KC par domaine (ménage/entreprise/ ssm?) - Tous ces utilisateurs voient tous les BPMN et peuvent démarer des processus avec ces BPMN. - Les utilisateurs 'ménages' (CPOS/CPIE) voient et peuvent interragir avec toutes les enquêtes ménages. - Au lancement du process le domaine est choisi en fonction du rôle de l'utilisateur ; s'il a plusieurs rôles une combobox doit lui permettre de choisir le domaine à utiliser. - Idée : un découpage par domaines (ménage, entreprise, ssm : cette info est disponible dans le fichier de contexte. Attention à l'éventuelle incohérence avec le role/choix de l'utilisateur). Les utilisateurs ayant ce rôle ont tous les droits sur les processus de ce domaine. SSM : Comment se déroulera l'authentification? Est-il possible d'avoir une authentification totalement externe insee? fonctionnement en bearer? (demander à benoit). # gestion des erreurs : ## Infos à affichier **Il faut faire une maquette** ## actions possibles Actions possible des utilisateurs: - UE refusée par une appli (ex: COLEMAN; ex BEATTLES... d'ailleurs si beattles appelle directement REM, comment il informe protools qu'une des UE est pourries? 1: que doit on faire d'un pt de vue métier? d'un point de vue technique?) - métadonnée (contexte protools) refusé par une appli - pb infra ==> Quelles actions possibles? Comment informer l'utilisateur? Peut on reprendre 'en cours' de route? ==> Doit on faire une maquette? Quid du POC déjà fait dans le cadre du stage de mailine? Tout passe il par l'utilisateur ou ya il une politique de rejeu? est-ce configurable? dans le contexte? dans le bpmn? Si on repasse par l'utilisateur, à quelle étape/granularité? Deux niveaux : tan qu'on est au niveau général, on peut remonter facilement à l'utilisateur (ex: on n'a pas réussi à créer le contexte dans platine) ==> Retry puis pause du processus et attente action utilisateur. Quand on est au niveau du sous-process (de l'UE) : c'est plus compliqué. Sur une UE en erreur, peut on la remettre dans le circuit après correction du problème? possibilité de relance utilisateur sur les UE en erreur. Attention : le sous-process peut avoir une certaine durée (en mois). Du coup comment peut on remonter les erreurs au fur et à mesure à l'utilisateur pour qu'il puisse les relancer? Attention aux dates (ne pas relancer après la date d'échéance). # IHM Plan d'action : 1 Liste des infos à afficher 2 Liste des actions utilisateur (y compris sur les cas d'erreur). TODO : Quentin/Audrey 3: Maquette TODO: informatique # Communication entre les différents services Gestion des reboots / reprises ==> Transactions Presta d'architecture ; spring-integration (fabrice) messagequeue En gros : Comment gère on pbs de com entre appli? Le cas où une appli reboot... politique de rejeu; Appels synchrones / asynchrones reprise au milieu d'une série d'appels APO ... ==> On va demander à fabrice s'il a la disponibilité pour faire un POC Spring integration. # Pb des appli en DMZ interne -> DMZ : OK DMZ -> Interne ; interdit pb : coleman est en DMZ ; protools sera en DMZ pour être appellable par les SSM ; opale, REM, sabiane ... ne le sont pas Voir l'API GATEWAY : C'est en instruction coté CEI. ==> Voir avec benjamin : Quelle solution a été retenue? Quel est le calendrier? Y a il des contraintes ou des devs à faire pour pouvoir l'intégrer? Est-ce acceptable de partir sur une V1 où protools est en interne? (donc avec protools interne qui pourra accéder à colleman en dmz). La contrainte du passage de protools en DMZ est liée à l'utilisation de protools pour une enquête SSM (horizon T2 2024). # Chaine de tests Doit on mettre en place une chaine complète pour pouvoir tester? si oui env dédié? qui s'en occupe? Aujourd'hui les QF2 sont déjà utilisées pour des TTP et sont dédiées aux tests des utilisateurs. On n'a donc pas vocation à y faire des tests pendant notre développement ou notre recette. Les QF1 des applis sont utilisés pour les tests de chaque appli et ne sont pas garantis d'être stables. ==> Il nous manque un environnement d'intégration / dev-recette qui soit stable, réputé fonctionnel. QF3? quand protools sera mis à disposition des utilisateurs pour qu'ils l'essaient, cela sera fait en QF2. 1. Sur quel env doit on se branche? 2. Est-ce qu'il y a possibilité de mettre en place un nouvel environnement dédié à l'intégration de la chaine orchestrée par protools? **TODO:** Demande à Geoffroy et Sébastien # Commuauté documentation dans symphonie Créer un doc unique Doc centralisant les orientations (archi; choix bpmn; besoins...). # Prérequis au lancement des dev **TODO (GEOFFROY / QUENTIN):** - Liste des API avec lesquelles protools va interragir + diagramme de séquence - Liste des codes d'erreurs possibles de ces API et traitement à faire - Données échangées avec ces API - Conversions à faire - notion d'urgence ou de priorité du besoin de telle API **TODO (informatique)**: - API exposée par protools (actions utilisateur ou de l'IHM) - choix sur la gestion des transactions (demander un poc à fabrice) - Choix sur les tests unitaires (rien à voir avec la partie tests d'intégration) **TODO (quentin)** - Fichier de contexte - BPMN - Mode de remontée des erreurs ; actions possibles - Préparer les cas de recette métier ## Références ACDC : https://hackmd.io/@tDubois/acdc https://hackmd.io/@JeanJean/SJI041Ub9 https://demo.hedgedoc.org/QMXKlb1SSPGNE7Limp1DAA# https://demo.hedgedoc.org/THxeWdZcQU6XNBRGax7keQ# https://hackmd.io/1I3yYqUZTyOA0Y9xN1MoiQ https://demo.hedgedoc.org/a2gjF_sYQGyj-Fa_DkyHYQ retours de fabrice sur la gestion des transactions & spring-integration : https://hackmd.io/Q_cZo5zzRXyIjWj9lTjMuw https://hackmd.io/XMsUAQ8wRMqDBmXZODPLLQ