Shunting
Introduction
L’expérience de XXXX a permis de démontrer que des composants et fonctionnalités de Matching et Routing sont similaires en maintenance et fonctionalités, La révision 2.0.0 du modèle XXXX a donc permis de créer un nouveau composant, le Shunting.
Le Shunting sera donc la gare de triage de FCT que ce soit depuis une communication externe ou même à l’interieur d’un scénario.
Example: Deux messages sont récupérés d’un même dossier mais le traitement est différent en fonction des données
Example: Le traitement en deux sous branches d’un message XML par exemple vers EDIFACT et vers X12.
L’idée sera d’utiliser cette fonction à l’interieur d’un scénario uniquement en cas de besoin de triage.
Example: En fonction d’une donnée interne au message, il est envoyé à un client A ou B
Shunting
C’est la table primaire du Shunting, elle autorise jusqu’à 5 clés de filtrage basiques appelées SHUNTER_KEY. Ceci ne signifie pas qu’il ne sera pas possible de filtrer au dela de 5 clés, mais plutôt que ces 5 clés représentent un filtrage plus rapide. L’IHM de FCT sera utilisée avec la fonctionnalité de Generic Codes afin de customiser le nom des clés en fonction de l’utilisateur.
Example: Chez XXXX, nous avons Sender, Receiver, ShipcompCode, TradingPartner et MessageCode
La priorité a pour but d’augmenter les performances du Shunter car il est possible qu’un channel transmette plusieurs type de messages, il est donc préférable de mettre en priorité 1, les messages les plus nombreux selon les statistiques afin d’éviter trop de calcul inutile.
En toute bonne gare de triage, cette table aura le plus de liens avec les autres. Elle sera centrale au modèle. Il sera donc possible de passer d’un Channel à un Scenario, d’une Data à un Stage ou d’une Data à un Channel.
Rules
Cette table est basée sur le principe de clé/valeur. C’est une extension de Shunting afin d’ajouter de nouveau mode plus avancés. L’idée est de pouvoir créer de nouvelles briques d’identification, pas toujours forcément nécessaires mais utiles dans certains cas.
Example: des règles de type EDIFACT afin de vérifier une valeur précise à l’interieur d’un fichier IN
Example: des règles de type REGEX appliquées sur le nom du fichier IN
Pour qu’un Shunting soit validé, il faudra que l’intégralité des rules liées le soit aussi. La priorité y sera aussi gérée mais d’une façon différente du Shunting. Il sera ici question de définir en priorité 1, les règles qui sont vraies le moins souvent possible. De cette façon, la première rule non valide permettera d’invalider le Shunting lié.