|
Observation réduite au cas
d'utilisation
|
Observation générale (bonnes
pratiques)
|
|
Entre le moment où le tiers est créé ou
modifié, il peut parfois se passer une heure avant que le processus
d'alimentation ne commence. De plus, certaines applications
consommatrices ne traitent les fichiers que la nuit ce qui repousse à
J+1 la mise à disposition de l'information
|
Les zones tampons doivent être limitées.
Un ESB fonctionne dans un mode au fil de l'eau. Les liaisons
inter-applicatives DEVRAIENT être de type Bus (ESB).
|
|
Cette tâche d'extraction n'est pas publiée car
intégrée dans un script Python sans réelle pré et
post condition. La réutilisation est en rendue moins évidente.
|
Les services (dans le sens générique) DOIVENT
pouvoir être invoqués grâce à une interface
d'accès de la famille des Services Web.
|
|
Les tiers sont extraits en Lot et rassemblés dans un
même fichier à plat. Sans recherche manuelle, il n'est pas
possible de savoir dans quel fichier se trouve la modification de tel ou tel
tiers.
|
Xquery permet d'interroger aisément le contenu d'un
document XML. Une couche d'administration peut être construite par ce
biais. XQUERY DEVRAIT être utilisé pour les recherches dans les
documents / Base de données XML.
|
|
Si le système d'information GCAT s'enrichit au niveau du
référentiel tiers, la tâche d'extraction doit être
retravaillée afin d'intégrer les nouveautés.
|
L'utilisation de formats de balisage (XML) est moins impactante
en termes de maintenance qu'un format fichier. Le format d'échange DOIT
être construit en XML.
|
|
La copie sur le FTP n'est pas sécurisée (RFC-959).
Les comptes et mots de passe peuvent être aisément captés
sur le réseau.
|
FTP propose une version davantage sécurisée :
SFTP. De plus les protocoles SOAP, WSDL et UDDI renforçant la
sécurité. Le mode sécurisé DOIT être
préféré au mode non sécurisé.
|
|
Le fichier est très difficilement lisible sans
accès à la description formelle. Le contenu du fichier n'est pas
contrôlé avant qu'il ne soit transmis au consommateur.
|
Le contenu d'un document XML est compréhensible
grâce aux balises utilisées. Ce contenu est contrôlé
par un Schéma XML qui constitue la « grammaire » des
informations transmises. Le format d'échange DOIT utiliser XML.
|
|
La transmission est mono-protocole. Quel que soit le
consommateur, il n'est pas possible de transmettre le message d'une autre
manière qu'en FTP.
|
Un système hétérogène peut rassembler
potentiellement divers protocoles (FTP, SFTP, HTTP ...). Un des rôles de
l'ESB est de transformer des protocoles (rôle de médiation). Les
liaisons inter-applicatives DEVRAIENT être de type bus ESB.
|
|
L'algorithme d'attente est basé sur la comparaison d'une
taille de fichier photographié deux fois, à 5 secondes
d'intervalles. Dans les faits, cela fonctionne dans 99% des cas. Mais il arrive
que certains noeuds du réseau soient saturés. Dans ce cas la
photo est identique alors que le transfert de fichier n'est pas
achevé.
Cf
diagramme de séquence
|
En mode fichier : Il faudrait procéder à un
nommage intermédiaire de telle façon à ce qu'il ne soit
pas récupérable par l'automate le temps du transfert. Une fois
achevé, le renommage du fichier le rendrait visible aux yeux de
l'automate car il en retourne de la responsabilité de
l'émetteur.
En mode message le problème de se pose pas car l'ESB
garantit le bon acheminement et n'enchaîne une nouvelle tâche
qu'une fois la précédente terminée. La
spécification WS-ReliableMessaging appliquée à SOAP
garantit le bon acheminement des messages. Dans le cadre des Services, SOAP
DOIT être utilisé.
|
|
L'algorithme de test est complexe et ne concerne que le
nom du fichier, c'est-à-dire le contenant et non le contenu. Les 2
premières positions du nom, puis les 3, les 4, les 5, les 6, les 7 et
les sont comparées avec une liste de racines, stockée dans un
fichier ascii non crypté. De cette chaîne est déduite
l'application consommatrice vers qui il faut transférer le fichier. Cf
diagramme de séquence
|
Les règles de routage internes à un ESB DOIVENT
répondre à cette problématique. Le routage doit se faire
sur le contenu (CBR) et non pas sur le contenant.
|
|
L'archivage consiste aujourd'hui à copier le fichier dans
un répertoire d'historisation. Tout traitement ultérieur sur la
base de ces fichiers est purement manuel et donc sujet à erreur.
|
Les règles de routage internes à un ESB DOIVENT
répondre à cette problématique. La définition d'un
Processus métier intègre les actions correspondant aux plans
alternatifs en cas de plantage ou de rejet. Cette gestion DEVRAIT être
davantage intégrée au processus métier d'alimentation des
Tiers.
|
|
De façon générale, il n'existe aucune
statistique automatique permettant de visualiser les
« pics » de transfert, les performances des
différentes actions...
|
Les indicateurs SAM et BAM permettent d'avoir une première
idée de la réalité des échanges. Un outil BAM PEUT
être mis en place pour donner ce premier niveau d'information.
|
|
Chaque consommateur gère ses transformations. Le
vocabulaire tout comme les règles de transformation ne sont pas visibles
de façon centralisée.
|
Un format pivot permettrait de centraliser les règles de
transformation ainsi que la sémantique des informations Tiers des
applications consommatrices. C'est aussi le rôle du
« Repository » qui DEVRAIT être mis en place.
|
|
Les tiers qui n'auraient pas pu être intégrés
par une application consommatrice ne sont pas connus de façon
centralisée sans une recherche approfondie.
|
Les liaisons inter-applicatives DEVRAIENT être de type ESB
du début à la fin du processus.
|
|
La réponse du consommateur se limite à la bonne
réception ou non du fichier sur le répertoire d'accueil. Si le
consommateur n'est pas accessible le fichier est mis en quarantaine ce qui
supposera ultérieurement une manipulation du service exploitation. De
plus, ce répertoire, vu du SI, est une boite noire : après
recherche manuelle en lisant les fichiers trace, on peut savoir ce qui a
été transmis, mais il est extrêmement difficile de savoir
à quel moment un tiers lambda a été intégré
à l'application consommatrice. Se pose là un des problèmes
de mise en oeuvre d'un PRA (plan de reprise d'activité).
|
Dans un ESB le message a comme attribut une durée de vie
qui lui permet d'attendre un certain temps avant d'être
déposé dans une file d'attente dite « de fin de
vie ».
En gérant tout le processus d'alimentation via un ESB, la
connaissance des messages est réelle depuis leur création
jusqu'à leur intégration par le consommateur. Dès lors il
est plus aisé de rejouer les messages entre deux instants T dans le but
de synchroniser plusieurs noeuds du système d'information. Les liaisons
inter-applicatives DEVRAIENT être de type ESB.
|
|
Le processus est limité dans le sens où seul
l'événement de saisie utilisateur déclenche une
alimentation des applications consommatrices. Or, nous traversons une phase de
réorganisation. Dans le cas où le référentiel
Terrena deviendrait le référentiel de l'ensemble des filiales il
faudrait que les tiers puissent aussi être transmis
électroniquement (au format XML par exemple) d'une filiale par exemple
à l'application centrale qui deviendrait cette fois une application
consommatrice.
|
L'évènement déclencheur est aujourd'hui de
type timing dans le sens où c'est le temps qui fait qu'une extraction
des modifications et créations Tiers se déclenche. Le fichier,
résultant de cette extraction, est ensuite travaillé par le
processus actuel. Demain, le déclencheur pourrait être plus proche
des évènements perçus par le Système. Ainsi,
à chaque saisie d'un utilisateur, un service constituerait un message
qui serait l `élément déclencheur du processus. Cette
nouvelle porte pourrait aussi être empruntée par les filiales qui
souhaiteraient transmettre leurs informations au système central GCAT.
L'évènement déclencheur DEVRAIT être choisi parmi
les objets en lien direct avec le processus ce qui rend plus aisée
l'articulation entre plusieurs processus.
|
|
Seuls les tiers nouvellement créés ou
modifiés alimentent les applications consommatrices. Il n'est pas
possible aujourd'hui de procéder à un rafraîchissement qui
fonctionnerait à la demande (via un Web Service).
|
Un ESB offre la possibilité d'accéder aux
informations de diverses manières. Les Web Services font partie de cette
offre.
|
|
Un tiers ne se définit pas seulement par ses informations
générales, ses RIB et ses Adresses. L'ensemble des données
de sa relation commerciale et financière avec la Coopérative fait
partie de son identité. Aujourd'hui, les gestions commerciales,
consommatrices de l'interface de Tiers, n'ont pas accès à cette
vue complète.
|
Un ESB offre la possibilité d'accéder aux
informations de multiples systèmes Fournisseurs.
|
|
Le référentiel de Structure, c'est à dire
l'identification des ressources (Serveurs, répertoires,
authentification) au travers du SI est géré dans des fichiers Csv
non cryptés.
|
Un référentiel de la structure DEVRAIT être
intégré à l'architecture et être
sécurisé.
|
|
La liaison inter-applicative est de type « Point
à Point ».
|
Les liaisons inter-applicatives NE DOIVENT PAS être de
« point à point » mais DEVRAIT être de type
ESB dans le sens « un message pour N applications consommatrices
abonnées au processus ».
|
|
Le référentiel Client, c'est à dire
l'identification des tiers au travers de tout le SI n'existe pas en tant que
tel. Il est dispersé dans autant d'applicatifs qui constituent le SI.
|
Un référentiel métier DEVRAIT être
intégré à l'architecture.
|
