Généraliser et remonter la gestion des flux
L'outil de gestion des flux de Decathlon permet de visualiser et régénérer le traitement de commEvents pour l'envoi de données.
L'objectif est de faciliter la maintenance des échanges de données entre OFBiz et l'applicatif externe. Que ce soient les flux entrant ou sortant. Deux possibilités :
- La gestion de envoi et réception de flux de manière asynchrone
- La reception d'un flux créé le commEvent avec le content associé, sans traitement ultérieur
- Le traitement d'un flux entrant se fait dans un second temps pour logger les erreurs et permettre l'analyse.
- La génération d'un flux sortant se fait classiquement
- L'envoi du flux sortant, peut etre précédé d'un service de contrôle validant la donnée envoyée.
- La gestion de flux synchrone :
- L'execution de l'envoi se fait de manière synchrone, un commEvent et content est créé pour logger l'envoi et permettre son réenvoi
- Le log de la reception se fait directement post traitement, à l'instar de l'envoi.
L'outil ne doit pas gérer l'ensemble des commEvent OFBiz. Il faut donc définir un discriminant pour les commEvent à suivre. L'outil permet de gérer ce commEvent :
- Recherche un flux * Replanification d'un flux sans modification
- Replanification avec modification (régénération de content)
Le flux généralisés, supportés sont :
- les mails à suivres avec PJ (génération de PJ sur un content)
- flux ftp
Avoir un service d'alimentation d'un mail à suivre/ftp à générer. Avoir un job de traitement des commEvent simplifié. Pour planification de leur envoi (ou voir si les jobs standards font le taf)
Tâches :
-
Description globale de la tâche -
Definition des cas d'usages -
Définition de nouveaux types de commEvent -
Définition cas d'usage mail (idées de flux à suivre, autour d'une commande)
-
-
Reprise des écrans -
Recherche de commEvent sous-type créés -
Liste des commEvent et content associés
-
-
Services -
écriture de service de création de commEvent -
écriture de job de traitement de commEvent -
écriture de service de replanification de commEvent
-
Pad (brouillon collaboratif) du ticket:
https://pad.libre-entreprise.org/p/nereide_communautaire_113
17 septembre 2019 : Le besoin exprimé par Pierre est plus simple que celui implémenté chez Decathlon :
Logger les appels WS et leur retours de certains services dans des commEvents afin d'avoir des quantités chiffrés d'erreur, et de produire des analyses cas par cas.
L'idée : de manière spécifique définir un service qui sera branché en écoute sur le serviceEngine (ou en seca sur les services à analyser) qui va :
- Vérifier (dans le cas
serviceEngine
) le fait que ce service est paramétré parsystemProperty
pour être loggé - Créer un commEvent en enregistrant
- Dans un content les paramètres d'entrées de service sérialisés.
- Dans le status du commEvent : le code retour succès ou erreur
- Dans un autre content les données retournées préfixé du code retour exact, et éventuellement du header
- Dans le contactMechIdTo : une référence vers un contactMEch de type
webService
indiquant le endpoint contacté - Dans le partyIdFrom l'acteur émetteur de l'appel
- Dans le partyIdTo l'acteur destinataire (identifié du header et du sens de l'appel in/OUT)
Cela fait on peut logger de manière paramétrable les services désirés. Les données sauvegardées sur le commEvent permettent son rejeu, à coder de façon spécifique... Reste a voir si c'est remontable/justifiable auprès de la communauté.