dnum-mi / referentiel-applications-specs

spécifications canel
0 stars 0 forks source link

[FluxApplication] #45

Closed Metazel closed 1 year ago

Metazel commented 1 year ago

Champ "intermédiaire" : peut-on l'appeler "application de transport" ou "intergiciel" (ma préférence) ?

Est-ce qu'un champ "nature de l'échange" serait utile :"synchrone, asynchrone," pouvant être complété par "push (comme pour les systèmes d'alerting/notification), pull (invocation d'api)"?

Est-ce qu'un champ "format" du flux serait utile : "json, xml, txt, csv" ?

Est-ce qu'un champ "mecanime d'authentification" entre systèmes serait utile (je suis pas specialiste @hassan)?

Question : un flux est-il forcément entre deux systèmes applicatifs? Comment gérer la méconnaissance qu'on a d'un flux entre une application maitrisée chez nous et une application X (dont on ne connait pas le nom) gérée par une entité organisationnelle externe (ex. IGN, ou une entité affiliée au MIOM mais sur lequel on ne connait pas les applications ex. ANTS ou ANTS)?

Question : la partie donnée(s) véhiculée(s) par un flux. Gère-t-on l'information dans CANEL2 ou collecte-t-on nous l'information à partir du catalogue de données?

ymlesaux commented 1 year ago

Champ "intermédiaire" : peut-on l'appeler "application de transport" ou "intergiciel" (ma préférence) ? Ce terme est repris du modèle de DAG. Peu importe le terme du moment qu'il fait sens pour tous les utilisateurs, et qu'il est identique dans tous les media.

Est-ce qu'un champ "nature de l'échange" serait utile :"synchrone, asynchrone," pouvant être complété par "push (comme pour les systèmes d'alerting/notification), pull (invocation d'api)"? La notion d'asynchronisme requiert un composant intermédiaire. Soit il s'agit d'un composant managé, et il est alors précisé dans le champ "intermédiaire", soit il s'agit d'un composant applicatif, et il devrait apparaitre explicitement. Donc, pas convaincu. Pour la question sur les "push/pull": cela permettrait de préciser le sens de circulation des données, dans la mesure où le sens de la connexion (applications source et cible) est technique (qui initialise la connexion) - A discuter

Est-ce qu'un champ "format" du flux serait utile : "json, xml, txt, csv" ? Dans l'absolu, oui, mais bof: cela fait sens dans le cas d'une interface pour préciser le format attendu, mais dans le cas d'un flux, je suis moins convaincu.

Est-ce qu'un champ "mecanime d'authentification" entre systèmes serait utile (je suis pas specialiste @hassan)? Un peu comme au-dessus, cette information est intéressant pour une interface, et moins pour un flux.

Question : un flux est-il forcément entre deux systèmes applicatifs? Comment gérer la méconnaissance qu'on a d'un flux entre une application maitrisée chez nous et une application X (dont on ne connait pas le nom) gérée par une entité organisationnelle externe Je n'ai pas compris la différence entre ANTS et ANTS :) Plus sérieusement, la remarque est pertinente. As tu une proposition ?

Question : la partie donnée(s) véhiculée(s) par un flux. Gère-t-on l'information dans CANEL2 ou collecte-t-on nous l'information à partir du catalogue de données? D'après ce que j'ai cru écrire, le champ Identifiant de la donnée permet de collecter une donnée issue d'un référentiel de données. Mais en attendant, on pourrait y mettre un nom. Je ne crois pas avoir mis de contrainte sur ce sujet.

ymlesaux commented 1 year ago

Pris en compte dans FluxApplication.md