AGILIX : architecture des échanges entre AGIL et ACE

Généralités

Introduction

Cette documentation décrit l’architecture des échanges entre AGIL et ACE, échanges basés sur l’utilisation de TradExpress.

Les flux d’informations ont deux sens :

  • d’Agil vers ACE (GCE2AGIL),
  • d’ACE vers Agil (AGIL2GCE).

Schéma de principe

Données échangées

GCE2AGIL

Domaine Thème
Produit Articles
Produit GAMMES
Produit GENCOD
Produit Modèles
Produit Propriétés articles
Produit Propriétés modèles
Produit Traductions
Stocks Stocks
Tables référence Magasins
Tables référence Modes de paiement
Tables référence Taux de TVA
Tables référence Unités
Tarifs Prix de vente de référence
Tarifs Prix de vente spécial centrale
Tarifs Prix de vente spécial promo
Client Interface client mode 1

AGIL2GCE

Domaine Thème
CLIENT Fiche client et contact (création de client/contact, création de carte, activation de carte et désactivation de carte)
TICKET Tickets de vente
TRESORERIE Trésorerie vente, client, tiroir

D’ACE vers AGIL

Principes

Règles d’extraction

Déclenchement du processus

Une procédure planifiée dans ACE est à l’origine du processus, tout s’enchaine ensuite par attente de témoins.

Fréquence
Paramétrable :
  • vraisemblablement une fois par jour, en soirée pour les données de base,
  • A fréquence plus élevée mais toujours pilotée par le planificateur ACE pour les mouvements de stocks,
  • éventuellement en cours de journée, à la demande, initiée d’un menu d’ACE.
Rôles des applications, dans l’ordre de réalisation
1. ACE :
  • Une file batch doit être réservée aux extractions GCE2AGIL, un contrôle préalable est réalisé sur la tbl de date de dernière extraction pour s’assurer qu’un traitement d’extraction n’est pas déjà en cours. Si c’est le cas, la procédure n’effectue pas d’extraction.
  • Extraction des mises à jour à envoyer à AGILserver® avec génération d’un fichier contenant les sections d’échange au format AGIL nommé : gce2agilaaaamijjhhss.ech sur un répertoire d’échange dédié.
  • En fin d’extraction, dépôt d’un fichier témoin paramétré (gce2agilaaaammjjhhmiss.go) dans le même répertire que les fichiers ECH et ce après constitution totale et « libération » du fichier ECH.
2. TradeXpress :
  • Installé sur le serveur d’ACE ;
  • En attente d’un témoin de déclenchement de la descente d’ACE vers AGIL (gce2agil*.go) ;
  • Pour chaque fichier .GO rencontré déplacement du fichier et du fichier .ECH correspondant dans un répertoire de travail.
  • Transport des fichiers .ECH du serveur ACE vers le serveur AGIL sur le dossier d’arrivée sous un nom temporaire puis renommé en .ECH en fin de transfert
  • En fin de transfert ftp correct du fichier .ech, TradeXpress génère et envoie un fichier AGIL.GO.
  • Monitoring de ces évènements dans TradeXpress.
3. AGILserver® :
  • En attente du témoin de déclenchement de l’intégration (AGIL.GO) dans le dossier d’arrivée de l’interlocuteur
  • Mémorisation des fichiers .ECH à traiter dans l’ordre alphabétique (ie dans l’ordre de la date et heure les noms de fichiers étant identiques aux date/heure près).
  • Renomme le fichier .GO en .WRK
  • Processus classique d’intégration d’ AGILserver® : traçage de l’intégration dans la trace, suivi dans le rapport d’activité.
  • Renomme le fichier .WRK en .OK

Précision 1 : TdX peut transférer vers AGIL un agil.go ou des fichiers ech (ceux-ci sont nommés différemment) même si un agil.wrk existe. La liste des ech à traiter a déjà été constituée, les nouveaux ech le seront au prochain traitement, quand AGIL verra le fichier agil.go.

Précision 2 : Un problème se pose si plusieurs séquences (ech, go) sont en attente dans le répertoire TdX (Le serveur a été arrêté ou la liaison interrompue). Par défaut TdX ne gère pas l’ordre de transfert. De plus en cas d’erreur de transfert sur un fichier, les fichiers suivant peuvent être traités avant que l’administrateur ne corrige l’erreur.

Règles de reprises sur incident
  • ACE :
    • Après correction du problème sur l’élément de procédure concerné, le traitement peut être relancé en mode reprise. Les données sont ajoutées en append du fichier d’échange avec suppression simultanée du flag depuis la table guide des mises à jour
    • Le traitement peut être éventuellement entièrement relancé et ce après réinitialisation manuelle de la table de dernière extraction et la suppression du fichier .ech généré initialement.
  • TradExpress :
    • En cas d’erreur lors d’un transfert, l’administrateur édite le journal système, corrige l’erreur (cas d’un mauvais paramétrage) et lance une reprise
  • AGILserver® :
    • Il s’agit du processus classique de gestion des rejets : les éléments de l’ech ne pouvant être intégrés sont « mis de côté » dans des fichiers rejet. Ceci est consigné dans la trace d’ AGILserver® , et l’intégration interlocuteur apparait en erreur dans le rapport d’activité.
    • Les fichiers rejets peuvent être réintégrés après correction du problème ayant provoqué le rejet.

D’AGIL vers ACE

Principes

Ce processus est séparé en 4 phases :
  1. Extraction des données de la BDD d’ AGILserver® vers la table temporaire dans la BDD d’ACE. Cette phase est assurée par une instance de TradeXpress, installée sur le serveur AGILserver® . On appellera cette instance « TradeXpress AGIL » ;
  2. Validation par procédure SQL des données suite à leur insertion dans la table temporaire d’ACE ;
  3. Extraction des données sous forme de fichier d’intégration pour ACE. Cette phase est assurée par une instance de TradeXpress, installée sur le serveur ACE. On appellera cette instance « TradeXpress ACE » ;
  4. Intégration dans ACE.
Ce processus sera utilisé :
  • Avec une fréquence relativement espacée : concerne la remontée des ventes et de la trésorerie. Exemples possibles : toutes les heures, 2 fois par jour, une fois par jour et éventuellement à la demande ;
  • Avec une fréquence éventuellement élevée : concerne la remontée dans ACE des clients créés/modifiés dans AGIL.

Le fonctionnement est le même quelque soit la fréquence et le type d’information transportée : ces deux sous-types de flux correspondent à 2 interlocuteurs d’ AGILserver® .

On part donc du principe que :
  • Le nombre d’interlocuteurs correspondants aux sous-flux entre AGILserver® et ACE peut être supérieur à 2 ;
  • Le nombre d’éléments à transporter est figé aux 6 sections d’échange suivantes : CUSTOMER, CUSTOMER_NEW_CARD, CUSTOMER_ENABLED_CARD, CUSTOMER_DISABLED_CARD, CUSTOMER, VENTE et TRESORERIE.
  • Les ventes doivent être extraites avant la trésorerie : il faut donc penser à les ordonner en conséquence dans la fiche interlocuteur d’ AGILserver®
Le nombre d’interlocuteurs à paramétrer en remontée correspond en fait aux couples contraintes (types de données, fréquence) des échanges envisagés dans le contexte du client. On identifie à l’heure actuelle 2 interlocuteurs :
  • Interlocuteur 1 : pour la remontée des ventes et trésorerie, fréquence espacée ;
  • Interlocuteur 2 : pour la remontée des informations client, fréquence élevée.

Les paragraphes ci-dessous détaillent l’extraction d’ AGILserver® vers ACE, quelques soient les données transportées.

Afin de préserver le traçage dans AGIL de l’existence, de la durée et de la bonne ou mauvaise exécution des extractions interlocuteur, l’extraction de l’interlocuteur est déclenchée par présence du fichier témoin de déclenchement (AGIL.go).

Le processus d’extraction interlocuteur à proprement parlé est géré par « TradeXpress AGIL » (sélection des données à extraire, écriture dans la table temporaire d’ACE, historisation des données extraites), AGIL reprenant ensuite la main pour terminer l’écriture de sa trace à la fin du flux (voir précisions ci-dessous).

Schéma

Règles d’extraction

Déclenchement du processus

Le flux correspondant aux ventes et trésorerie est déclenché par TradExpress AGIL qui dépose un fichier témoin de déclenchement (AGIL.go) dans le répertoire de départ de l’interlocuteur suivant une planification en cohérence avec celle indiquée sur le paramétrage de l’interlocuteur AGIL.

Le flux correspondant aux création/modifications de client doit être déclenché par la création ou la mise à jour du client dans la BDD d’ AGILserver® : il convient donc à AGILserver® de déclencher, dès la mise à jour du client ou de l’un de ses éléments, l’écriture du fichier témoin dans le répertoire de départ de l’interlocuteur souhaité

Cette extraction figure dans le rapport d’activité d’AGIL (donc dans la trace du moteur).

Les spécifications de ce déclenchement font l’objet d’un document dédié : SFD - AGIL - Délégation de l'extraction interlocuteur à TradeXpress.doc

Le paramétrage, fonctionnement et suivi de ce genre d’extraction fait l’objet de la fiche fonctionnelle Fiche fonctionnelle - Paramétrage des interlocuteurs AGILIX 3.76.1.pdf

Fréquence
Variable, selon le sous-type de flux :
  • Relativement espacée : concerne la remontée des ventes et de la trésorerie. Exemples possibles : toutes les heures, 2 fois par jour, une fois par jour et éventuellement à la demande ;
  • Elevée : concerne la remontée dans ACE des clients créés/modifiés dans AGIL

La suite de ce document détaille les 4 phases du processus d’extraction d’ AGILserver® vers ACE :

Extraction d’AGILserver® vers table temporaire

Rôles des applications, dans l’ordre de réalisation :
  1. AGILserver® :
    • Traçage du début de l’extraction interlocuteur ;
    • Création d’un fichier témoin de déclenchement paramétré à destination de « TradeXpress AGIL » (AGILtoGCE_iditl.GO) dans un répertoire paramétré. Ce fichier témoin contient une balise contenant le code de l’interlocuteur dont « TradeXpress AGIL » doit réaliser l’extraction (iditl est l’identifiant interlocuteur permettant d’identifier l’extraction réalisée)
  2. « TradeXpress AGIL » :
    • En attente du fichier témoin de déclenchement des traitements d’extraction, dans un répertoire paramétré (AGILtoGCE_iditl.GO) ;
    • Recherche de l’interlocuteur dont il faut réaliser l’extraction, dans le fichier témoin de déclenchement (AGILtoGCE_iditl.GO) ;
    • Sélection des données à extraire dans la table DISTRIBUTION (table temporaire DST_ITL_TMP_xx ou xx est le numéro d’interlocuteur (extrait de DISTRIBUTION).
    • Insertion des données correspondantes dans la table temporaire d’extraction avec un statut ligne « à contrôler ». Les données sont insérées dans les tables temporaires d’ACE avec un identifiant société donné en paramètre de configuration de TradeXpress AGIL
    • En cas de problème de transfert vers la table temporaire TradeXpress AGIL envoie un email sur erreur par défaut vers un destinataire Alarm.
    • Monitoring de ces évènements dans « TradeXpress AGIL » ;
    • Création d’un fichier témoin de fin, contenant le résultat de l’extraction (AGILtoGCE_iditl.OK). Ce fichier témoin contient une balise contenant le résultat de l’extraction : OK, ou KO, ainsi qu’un éventuel libellé d’erreur (n° d’évènement TradeXpress, (il s’agit d’un index dans le journal de TradeXpress concernant la copie dans les tables temporaires. Accessible uniquement par l’administrateur Tx, pas depuis la console AGIL)
    • Validation des données de la base temporaire par appel à une procédure PL/SQL de contrôle. Ce système assure que toutes les données ont été validées avant le lancement du TradeXpress CGE. En cas d’erreur TradeXpress envoie un email au destinataire Alarm. Ce traitement positionne les lignes au statut « contrôlé ». Un échec de ce traitement est remonté dans le code erreur AGILtoGCE.OK
    • Ce même statut contrôlé sera positionné par le portail de correction pour les lignes en statut KO à l’issue du contrôle fonctionnel.
    • Création d’un fichier témoin AGIL2GCE.OK contenant le code interlocuteur concerné et envoie au TradeXpress CGE ainsi qu’à AGILserver® pour confirmation de traitement.
    • Soumission du traitement « TradeXpress ACE »
  3. AGILserver® :
    • Attente, dans le dossier de déclenchement de « TradeXpress AGIL », du témoin de fin d’extraction généré par « TradeXpress AGIL » (AGILtoGCE_iditl.OK);
    • Traitement du témoin de fin d’extraction quand il arrive : écriture de la trace de fin d’extraction interlocuteur (pas de fichier log) avec prise en compte du résultat de l’extraction indiquée à l’intérieur du fichier témoin (balise contenant le résultat de l’extraction : OK, ou KO, ainsi qu’un éventuel libellé d’erreur) puis suppression du fichier témoin.
    • Historisation des données extraites de distribution dans les archives de distribution
    Validation et extraction des données de la table temporaire d’ACE
  4. « TradeXpress ACE » :
    • Lancement par « TradeXpress AGIL ». par génération d’un fichier témoin comportant l’interlocuteur et composé du nom de l’interlocuteur.GO et comportant le code de la société à traiter.
    • Les traitements de traduction sont sérialisés pour éviter les conflits d’accès
    • Transformation des enregistrements « contrôlés » de la table temporaire en fichier plat d’intégration au format attendu par ACE et mise à disposition du fichier d’intégration dans un répertoire paramétrable d’ACE (les lignes extraités sont passées au statut « à intégrer ». Le fichier est nommé : agil2gce_<no index de syslog>.ech.
  5. ACE:
    • Scan du répertoire d’arrivée du fichier par l’intégrateur mis en procédure suivant fréquence à paramétrer.
    • Intégration du fichier dans ACE avec gestion de commit « logique ». une balise 99 est intercalée entre chaque ensemble logique pour permettre une intégration ou rejet cohérent. Chaque ensemble logique comporte une balise A9 permettant de supprimer l(es)’occurrence(s)d’origine dans la table temporaire

    Tableau d’évolution du statut des lignes de la table temporaire ACE :

    Statut Description Déclencheur
    1 A CONTROLER Positionner lors de l’insertion des lignes dans la table temporaire par TradeXpres AGIL
    2 CONTROLER OK Positionner par le PL/SQL de contrôle fonctionnel des données en cas de contrôle positif
    3 CONTROLER KO Positionner par le PL/SQL de contrôle fonctionnel des données en cas de contrôle négatif
    4 A NE PAS PRENDRE EN COMPTE Positionner par le PL/SQL de contrôle fonctionnel des données si la section traitée n’est pas « significative », une occurrence de suppression (balise A9) est malgré tout générée.
    5 DONNEES EXTRAITES Positionner lors de l’extraction des lignes dans la table temporaire par TradeXpres ACE
Règles de reprises sur incident
  • ACE :
    • Après correction du problème, les données peuvent être à nouveau intégrées suivant la procédure standard de la fonction INTEG de réintégration.
  • TradeXpress :
    • Il ne doit pas y avoir de reprise de l’extraction dans TradeXpress AGIL, car l’historisation de la table de distribution ne serait pas effectuée par Agil server. Il peut y avoir une reprise du transfert ftp du fichier témoin vers TradeXpress ACE
    • Pour TradeXpress ACE, une reprise de la traduction peut être tenté en cas d’erreur (ex accès à la base de données), mais si le fichier à été transmis (pas d’erreur pour TradeXpress).
  • AGILserver® :
    • Si AGILserver® reçoit une réponse KO de TradeXpress : le résultat de l’extraction indiqué par TradeXpress dans le témoin de fin d’extraction est différent de OK => l’extraction est notée dans le rapport d’activité comme échouée, avec une alerte de niveau 2. AGILserver® historise et supprime comme d’habitude la table temporaire de l’extraction interlocuteur à la fin du processus d’extraction. Il convient de voir dans les traces de TradeXpress la raison du problème rencontré (l’index du syslog est mémorisé dans le fichier de log AGIL associé à l’extraction)
    • Si AGILserver® ne reçoit pas de réponse de TradeXpress dans le délai paramétré dans la fiche interlocuteur d’ AGILserver® : l’extraction est notée dans le rapport d’activité comme échouée, avec une alerte de niveau 1. AGILserver® ne supprime pas la table temporaire de l’extraction interlocuteur : TradeXpress peut terminer au besoin son extraction. Les éléments restent dans la table temporaire d’ AGILserver® , prêts à être refournis lors de l’extraction suivante. Il n’y a pas de d’index de syslog dans ce cas