Un Protocole de transport unique et non
sécurisé
Illustration 97 : Couche
Transport
Le script actuel ne propose qu'une porte d'échange
entre les différentes plateformes : le mode FTP. De plus, les
comptes et mots de passe ainsi que les noms de machines et les
répertoires sont stockés dans un fichier Csv non crypté.
L'arrivée d'une nouvelle plate-forme dans le SI suppose, en cas de
participation aux échanges, la modification de ce script et
l'alimentation des fichiers de « paramétrage ».
Une architecture orientée services est avant tout une
architecture de médiation permettant d'assurer
l'interopérabilité au niveau des données mais aussi au
niveau des techniques de transport telles que : HTTP, HTTPS, SOAP +
WS-Security, SMTP, SMTPS, FTP, SFTP, RMI, etc ...), tout en sécurisant
les échanges.
Pour cela, l'ESB joue un rôle de médiateur entre
les différents systèmes, grâce à ses composants
internes. Au moment de la génération du message, les
consommateurs ne sont pas connus à l'avance. Le bus doit donc être
souple, c'est à dire permettre à plusieurs systèmes
hétérogènes de communiquer sans que le processus ne soit
décliné autant de fois qu'il y a de technologies dans le SI. La
spécification WS-Security (OASIS) vient renforcer la
sécurité des échanges de messages.
Dans le cas présent, la cardinalité devrait
être multiple, et le canal devraient, si possible, être
sécurisé (SFTP au lieu de FTP tout au moins).
Un processus qui s'arrête
trop tôt
_
Illustration 98 : Diagramme de séquence de la
distribution
Actuellement, si un consommateur n'est pas disponible, alors
le message (le fichier) est systématiquement mis en quarantaine, ce qui
implique une action manuelle de la part d'un technicien d'exploitation. De
plus, si une nouvelle application doit entrer dans le processus d'alimentation,
cela suppose également un paramétrage spécifique et des
modifications à plusieurs niveaux des scripts actuels. Ceci peut
être source d'erreur et ne semble pas très
« agile ». De plus, le processus actuel ne sait pas
à quel moment tel ou tel fichier a été
intégré. Il n'y a pas de retour du consommateur au superviseur
quand un fichier a été consommé, ni lorsque que tout ou
partie de ces enregistrements présentent des erreurs de codification.
Aujourd'hui, les dernières branches du processus sont manuelles.
Les Données
L'organisation des données au sein d'un fichier Csv
fragilise l'agilité du système, puisque tant pour l'extraction,
que pour les N programmes de transformation et de chargement (ou
d'intégration), il faudra opérer des adaptations plus ou moins
coûteuses. De plus, la mise en lot des données de plusieurs tiers
ne facilite pas le suivi unitaire, cette notion de lot n'étant pas
réellement identifiée au niveau du Fournisseur.
Les règles de transformation ne sont pas connues de
façon centralisée car elles sont réparties sur autant de
systèmes Clients distants. Les mesures d'impact en cas de modification
n'en sont pas aisées. Pour illustrer cette difficulté
supplémentaire, nous pouvons citer le problème auquel nous avons
dû faire face en début d'année : le nombre de
positions (5 caractères numériques) qui permet d'identifier le
code tiers n'était plus suffisant, au autrement dit :
« la boucle était bouclée ». Il a fallu se
rapprocher de chaque Chef de projet pour connaître la longueur et le type
de code Tiers dans chaque application, puis se lancer dans une phase de recette
complète pour mesurer l'impact de l'utilisation alphanumérique
des 5 positions de ce code. Plusieurs semaines ont été ainsi
nécessaires pour commencer à avoir certains retours sur un
dossier pourtant jugé « urgent ».
Les agrégations de données sur des
entités comme le tiers, pour lesquels il existe des tables de
transcodification sur certaines applications, sont rendues très
délicates : nulle-part, de façon centralisée, nous ne
pouvons connaître l'ensemble des identifications d'un tiers. Invoquer des
services sur des systèmes différents dans le but de
réaliser un processus transverse (exemple : Suivi des montants des
livraisons par Tiers) devient une chose difficile.
Le vocabulaire utilisé aujourd'hui n'est pas uniforme
(chaque application consommatrice désigne l'adhérent selon son
métier : « Fournisseur collecte »,
« Adhérent »,
« Coopérateur », « Eleveur »).
La codification peut être propre à l'application (on l'a vu
précédemment via une transcodification), ou identique ou presque.
Quelques transformations (le sous-compte par exemple dans l'application
Céréales est amputé du premier chiffre) sont parfois
utilisées. Ces règles ne sont pas connues de façon
centralisée.
| 
