Processing

Introduction

Le Processing c’est le coeur de FCT. Il est né d’abord de ce qui était le Brouteur dans FCT. Il a ensuite évolué avec les années afin d’arriver petit à petit à un système complet de Processing. Il y a une tendance à confondre le Processing avec FCT, c’est normal car il contenait aussi à l’origine une fonctionnalité de Matching qui a cependant été supprimé dans les évolutions pour implémenter un composant à part entière.

Le principe de base du Processing est de pouvoir executer une ou plusieurs activités à la suite. D’un point de vue ITX, cela sera représenté par l’execution d’une ou plusieurs maps où il sera possible d’échanger des données entre chacun d’entre elle.

Example: La réception d’un fichier EDIFACT transformé tout d’abord dans un format Pivot XML puis intégré dans un backend client

Le second principe important est de garder la possibilité de réutilisabilité des activités et des scénario.

Example: Une activité d’encodage en Latin-1 disponible pour tous Example: Un scénario d’intégration de fichier EDIFACT de type IFTMBF commun à tous client

Scenario

Cette table était dans une version beta de FCT, une table de jonction entre un Assembly et un Stage et permettait la réutilisabilité d’un groupe de Stage et donc d’Action. L’évolution de FCT a permis d’affranchir l’interaction entre un Assembly et les informations fonctionnelles Partner et Message.

Un Scenario représente donc aujourd’hui un ou plusieurs Stage qui peuvent avoir des types différents. Son but est de permettre la réutilisatibité d’un process en entier pour un Partner et un Message différent.

Stage

De différent types possible, il représente une ou plusieurs Action dans un ordre défini.

Un type Primary sera obligatoire puisque ce sera le premier à être exécuté. Il sera impossible sans lui de remonter ou traiter un événement ou une transformation. Un type Standard permettera d’effectuer des traitements supplémentaires comme un traitement post communication.

Example: Le message sortant a été envoyé au client, je lance une action de mise à jour du backend

Il pourra aussi permettre des traitements parallèles.

Example: Je reçois un fichier contenant des centaines de factures qui doivent être envoyées séparément au client.

Un type Event aura pour but une gestion événementielle durant le process.

Example: Des erreurs sont détectées sur plusieurs lignes du fichier entrant. Elles sont isolées puis renvoyées à la source pour information mais le process continue son traitement.

Staction

C’est une table de jonction permettant ainsi la réutilisabilité d’Actions dans un contexte ou un ordre différent.

Action

C’est ici encore une table de jonction mais avec un but un peu plus profond. Il n’est pas seulement question de réutilisabilité mais aussi de permission. Elle permet non seulement d’utiliser une même map ITX dans des configurations différentes mais aussi d’ouvrir FCT à d’autres logiciels sans avoir à modifier le fondement du framework.

Example: Un client Satisco utilise un modèle équivalent avec ITX mais aussi avec SBI. Une action est donc aussi une action SBI.

Data

Elle est apparue lors de la révision du modèle , version 2.0.0 lors de l’étude de la problématique concernant la partie Routing. L’idée était de rassembler les fonctionalités de Matching et Routing mais pour cela nécessitait de supprimer les liens vers Processing, ITX et Communication. Cette table sera une des rare contraintes pour les développeurs car elle nécessitera certainement un format spécifique pour le framework afin de parser correctement les données et paramètres. Son but est de permettre l’identification précise d’une donnée de sortie et ainsi ne plus la lier forcément à une carte de sortie physique ITX. Nous pourrons ensuite définir un identifiant de groupe soit pour de l’envoi groupé. L’identifiant sera une clé primaire et permettra la garantie d’unicité.

Example: Le serveur d’un client n’accepte que 10 connexions en parallèles. L’envoi est donc groupé pour diminuer le nombre de connexions simultanées.

ou encore pour prévoir l’envoie de fichiers provenant de scénario différent

Example: Un client qui ne souhaite recevoir toute ses factures en même temps Example: Un marketplace qui souhaite recevoir la commande d’un client 1 et 2 en même temps

L’événementiel sera lui aussi traité via la table Data. Il sera ainsi possible de traiter une sortie en plus d’un événement.