EIA- Exemples Echanges Inter Applicatifs

Ce chapitre présente des exemples de paramétrage de messages XML :

• message entrant STATUT complexe.

• message entrant commande commerciale

• message sortant STATUT complexe (mixage de plusieurs transactions sortantes).

Trois fichiers d’export correspondant chacun à un exemple et contenant les données décrites dans ce document sont également disponibles auprès de l’équipe assistance ISIA :

• 0840_EX_EIA_StatutEN.Z : message entrant STATUT complexe

• 0840_EX_EIA_CdeLigEN.Z : message entrant commande commerciale

• 0840_EX_EIA_StatutSO.Z : message sortant STATUT complexe

Ces fichiers doivent être importés dans DIAPASON en utilisant un traitement standard d’importation.

Remarques :

Les fichiers d’export doivent être copiés dans le répertoire « /tmp » et être importés à partir de ce répertoire.

Après importation, la version XML « DOC » doit être créée.

Les modèles XML importés (commençant par « T_ ») doivent être transférés dans la version « DOC ».

Les correspondances XML (commençant par « T_ ») portant sur ces modèles doivent être générées.

Les types de messages entrant (commençant par « T_ ») portant sur ces modèles et ayant comme mode de traitement « 0 » (Correspondances XML) doivent être générés.

Les types de réception portant sur les types de messages commençant par « T_ » doivent être créés.

Les règles d’identification portant sur les types de messages commençant par « T_ » doivent être générées avec l’action « Régénération Identification ».

Les documents sur transactions sortantes (commençant par « T_ ») portant sur ces modèles doivent être générés.

Chaque fichier d’export contient également le contenu de la session d’exportation utilisée pour le générer afin d’avoir une liste de toutes les données nécessaires à chaque exemple. Ces session d’exportation sont :

• T_Statut : message entrant STATUT complexe

• T_CdeLig : message entrant commande commerciale

• T_StatutSo : message sortant STATUT complexe

Message Entrant STATUT Complexe

Objectif

Le message XML en entrée à pour but de récupérer un état de déclarations de fabrication à partir duquel DIAPASON devra effectuer des actions particulières. Ces actions n’étant pas nécessairement des actions internes DIAPASON et pouvant être différentes suivant le contenu de certaines balises, le traitement de ce message sera effectué par une requête DIALOG.

A ce stade il faut :

• Définir le modèle XML servant de support au traitement du message.

• Définir la ou les correspondances nécessaire à la récupération des données

• Définir le type de message à associer

• Définir la règle d’identification permettant de faire le lien entre le message et le type de message à traiter

• Définir le type de réception

Il est impératif de suivre la séquence des opérations sus-citées afin de mener à bien le paramétrage.

Définition du modèle XML

La phase de création du modèle passe par la création de l’entête depuis la GFG des « Modèles XML » disponible dans la branche « Modèles Développement » de l’explorateur applicatif « Echanges Inter-Applicatifs ».

La structure du modèle XML peut rapidement être définie par le biais de la fonction « Initialisation Structure » accessible depuis la GFG des entêtes de modèles XML.

Lorsque la structure du modèle est finalisée, il est alors possible de le transférer en exploitation de façon à pouvoir enchaîner sur la phase suivante : La définition des correspondances.

Définition des correspondances

La phase de définition des correspondances permet de faire le lien entre le contenu des balises du message et les données manipulables par DIAPASON (variables (XML, SCR, …), listes de requêtes (REB ou REN)). Cette phase est sensible car elle nécessite une analyse du message lui-même pour arriver à déterminer combien de correspondances vont être nécessaires au traitement du message. L’exemple choisi présente une structure simple avec un « panier » de lignes décrivant un statut propre à chaque déclaration de fabrication. La particularité de ce message provient de la balise « Information » destinée à décrire des informations différentes dans une structure générique (Type et Référence). De cette structure il en ressort que deux correspondances seront nécessaires pour la récupération des données d’une ligne « LigneStatut » du panier « PanierStatut ».

Dans notre exemple nous définirons une correspondance sur des variables et une correspondance sur une liste REB.

• Exemple de Message XML

• Détail du paramétrage des correspondances :

La correspondance 1 permet de décrire les informations d’une « lignestatut ». Les valeurs seront récupérées dans des variables .

La correspondance 2 permet de décrypter chacune des informations pouvant être décrites dans la balise Information. Chaque information décrite sera récupérée dans une liste REB avec pour structure un champ Type et un champ Référence.

Correspondance « LigneStatut » :

➡️ Entête de correspondance

➡️ Détail de correspondance :

Chacune des variables XML est associée directement à une balise fille de la balise de départ « LigneStatut ». Chaque correspondance est traitée dans l’ordre défini.

Particularités :

Un bloc de mise à jour complémentaire a été défini sur la variable XML.SI_GenRefArt et consiste à tester la valeur de XML.SI_GenRefTypeArt afin d’affecter la variable XML.SI_GenRefArt.

Une formule est rattachée sur la variable XML.SI_Date dont la valeur sera déduite des trois balises <Jour>, <Mois> et <Annee>.

• Correspondance « Information » :

➡️ Entête de correspondance :

➡️ Détail de correspondance :

Chacun des champs de la liste REB est associé à une balise fille de la balise de départ « Information ».

Principe de traitement des correspondances :

Chacune des correspondances définies devra faire l’objet d’une génération. Le traitement d’une correspondance équivaut à l’exécution d’un programme PROGRESS qui lui est propre.

Dans le cadre d’un message complexe, le traitement des correspondances se fera par le biais des fonctions DIALOG « XML-LECCOR » et « POUR CHAQUE COR-XML ». L’exemple ci dessous montre la structure de la requête REB destinée à traiter ce message : La requête initialise un liste « LisDecFab » à partir des correspondances précédemment définies.

• Requête DIALOG de Lecture du Message

Remarques :

Il n’est pas nécessaire d’effectuer la lecture du message en tout début de requête.

Le contexte de la requête est le suivant : SCR.EIA_FicRec (Nom du fichier lu pour traitement, SCR.EIA_MesIde (identifiant du message traité dans la boite au lettre du moniteur EIA).

Les variables définies sur les correspondances sont visibles dans la requête de traitement.

Les listes définies sur les correspondances ne sont pas visibles dans la requête de traitement. Pour les rendre visibles il est nécessaire d’utiliser la fonction EIA-INITIALISATION POUR LISTE = Nom liste. Cette instruction peut être utilisée de deux façons :

Après POUR CHAQUE COR-XML …. : Il y aura dans la liste autant d’enregistrements que d’occurrences sur la balise de départ rencontrées dans le message.

Dans POUR CHAQUE COR-XML …. : Il y aura un enregistrement pour chaque occurrence de la balise de départ rencontrée dans le message.

Remarque : l’exemple présente une méthode de paramétrage, il en existe d’autres possibles (utilisation de variables exclusivement, initialisation d’une liste par correspondance …).

Définition du Type de Message 

Le type de message permet de décrire le traitement à effectuer sur les messages auquel il est lié. Dans notre exemple il sera de type complexe « 9 » et indiquera la référence de la requête REB de traitement du message.

Définition Règle d’identification

La règle d’identification va permettre de faire le lien entre le message entrant et le type de message permettant de le traiter. Cette phase est primordiale surtout dans le cadre de messages ayant la même structure et étant destinés à des traitements différents. La règle d’identification doit permettre de lever les ambiguïtés ( ce qui implique que deux messages de même structure et dédiés à des traitements différents doivent avoir un signe distinctif au niveau d’un contenu de balise ).

Les différentes description de règles :

<NomBalise> : la règle est vraie si NomBalise est présente dans le message

<NomBalise>=Valeur : la règle est vraie si NomBalise est présente dans le message et que sa valeur = Valeur.

Il est possible définir la balise NomBalise par son chemin tel que : <Balise1/Balise2/NomBalise> (permet d’enlever les ambiguïtés sur des balises portant le même nom à des niveaux différents dans le message).

Exemple :

Cet exemple montre une entête de message dans laquelle les balises Emetteur et Destinataire ont une structure identique « Identif/Code/Agence/TypeCode ». Si l’on considère que tous les messages dont l’agence émettrice sont destinés à un traitement A et que tous les messages dont l’agence destinataire sont destinés au traitement B la description des règles devra se faire telle que :

Définition Type de Réception 

Le type de réception définit la manière de réception de messages. Deux types sont gérés actuellement :

• R0 : scrutation par rapport à un répertoire donné

• D0 : scrutation par rapport à une requête REB (contenant la commande système de scrutation proprement dite ) .

Dans tous les cas, la résultante est une liste standard DIALOG « WFEIALisMes » qu’il est possible de manipuler par requête de façon à établir des associations Message/Type de message en fonction de règles décrites dans la requête.

A noter : sur chacun de ces types de réception un nouveau paramètre permet d’indiquer un répertoire de stockage des messages qui, si défini, permet de copier le message à traiter de son répertoire d’origine vers ce répertoire de destination (le message est supprimé de son répertoire d’origine). Ce système évite de réceptionner n fois le même message dans le cadre d’une scrutation effectuée par le biais d’un traitement répétitif.

Récapitulatif du Paramétrage

• Modèle XML : STATUT avec comme Version « 1.00 »

• Correspondance :

  • VisChLis : Correspondance LigneStatut

  • VisInfo : Correspondance Information

• Type de Message : SI_DecXML

• Formules Utilisées

SI_DateE : Permet de récupérer la date pour une LigneStatut

• Identification : sur Balise départ STATUT, balise <No> doit être égale à « DIAP-ISIA », Type message « SI_DecXML ».

• Type de Réception : A définir

Message Entrant Commande Commerciale

Objectif

Le message XML en entrée à pour but de créer des entêtes de commande ainsi que les lignes de commandes rattachées.

A partir du message XML en entrée, il va falloir le décrire en modèle XML dans DIAPASON. A ce modèle XML, des correspondances vont être définies afin de faire un lien entre les informations transmis par le message XML et DIAPASON.

Les correspondances vont permettre de créer les commandes et lignes dans DIAPASON.

Exemple de Message XML

Correspondance « Entête de Commande »

La correspondance sur l’entête de commande démarre sur la balise « Cde » située dans « PanierCdes ». C’est la balise de départ car c’est celle qui se répète (1 à n « Cde » dans « PanierCdes »).

• Détail des correspondances

La correspondance est simple : chaque balise correspond à une variable obligatoire (numéro de commande, réseau, client, etc.), hormis les cas suivants :

• Action

La codification ne correspondant pas à celle nécessaire à DIAPASON (« CREATION » au lieu de « CRE »), une formule est utilisée sur cette balise :

CASE DIAP_VALEUR_ENTREE :

WHEN 'CREATION'

THEN DIAP_VALEUR_RETOUR = 'CRE'.

WHEN 'MODIFICATION'

THEN DIAP_VALEUR_RETOUR = 'MOD'.

WHEN 'SUPPRESSION'

THEN DIAP_VALEUR_RETOUR = 'SUP'.

OTHERWISE DO :

DIAP_ERREUR = "Code action inconnu".

END.

END CASE.

• Commercial

Le commercial n’est pas renseigné dans le message XML, mais il peut être trouvé à partir du client. Pour ce faire, les variables « SDE.CliResRef » et « SDE.CliGenRef » sont enregistrées dans 2 variables SCR par des blocs PROGRESS du type (respectivement) : SCR.CliResRef = DIAP_VALEUR_ENTREE et SCR.CliGenRef = DIAP_VALEUR_ENTREE. Sur la variable « SDE.CliComRef », on trouve le bloc PROGRESS suivant :

FIND CDClient WHERE CDClient.RefSocApp = VarRefSocApplication

AND CDClient.CliResRef = SCR.CliResRef

AND CDClient.CliGenRef = SCR.CliGenRef

NO-LOCK NO-ERROR.

IF AVAILABLE CDClient

THEN DIAP_VALEUR_RETOUR = CDClient.CliComRef.

• Gestionnaire

Le gestionnaire n’étant pas renseigné dans le message XML, il bénéficie d’une valeur « défaut ».

Correspondance « Ligne de Commande »

La correspondance sur les lignes de commande démarre sur la balise « Ligne » située dans « PanierCdes ». C’est la balise de départ car c’est celle qui se répète (1 à n « Ligne » dans « PanierCdes »).

• Détail des correspondances

• Lecture du numéro de commande

Le numéro de commande des lignes ne se trouve pas dans la balise « Ligne ». L'option « Visibilité Balise » doit être cochée sur la correspondance Balise Variable afin qu’une recherche soit lancée sur les balises « sœurs » de la balise de départ de correspondance (ne portant pas le même nom) avant de remonter dans l'arbre des balises. Dans l’exemple, la recherche de la balise « NoCde » va s’effectuer de la manière suivante :

Dans les balises filles de « Entete », car celle-ci est au niveau de la balise « Ligne », et ne porte pas la même référence. Dès que la balise est trouvée, la recherche s’interrompt. C’est donc la balise « NoCde » située dans « Entete » qui sera prise et non pas celle qui est dans « ClientFinal ».

Dans les balises filles de « PanierCdes » si elle n’a pas été trouvée.

Ce même principe est appliqué à la variable ENT-MAJ.Action.

• Lecture générique de date

La balise « Date » située dans « Livraison » peut contenir plusieurs occurrences : date de livraison (arrivée chez le client), date d’expédition (départ plate-forme logistique). Ces dates sont décryptées via une formule qui :

Lit la balise « Type » permettant de déterminer la date concernée : livraison ou expédition.

Stocke la valeur lue dans une variable XML différente selon le type

/* Lecture date et vérification intégrité jour et mois */

DIAP_VALEUR_RETOUR = DATE( <JOUR> + '/' + <MOIS> + '/' + <ANNEE> ) NO-ERROR.

IF ERROR-STATUS:ERROR

THEN DO :

IF <TYPE> = 'LIVRAISON'

THEN DO :

DIAP_ERREUR = "Date Livraison incohérente".

END.

IF <TYPE> = 'DEPART'

THEN DO :

DIAP_ERREUR = "Date Expédition incohérente".

END.

END.

/* Affectation des variables concernées suivant la valeur de la balise type */

IF <TYPE> = "LIVRAISON"

THEN XML.T_DatLiv = DIAP_VALEUR_RETOUR .

IF <TYPE> = "DEPART"

THEN XML.T_DatDep = DIAP_VALEUR_RETOUR .

Les dates à mettre à jour sont ensuite associées via une correspondance à chaque variable XML (XML.T_DatLiv et XML.T_DatDep) mise à jour dans la formule.

Récapitulatif du Paramétrage

• Modèle XML : T_CdeLig (Version DOC)

• Correspondances XML

  • T_Cde : Entête de Commande

  • T_Lig : Ligne de Commande

• Type de Message : T_CdeLig

• Formules Utilisées

  • T_Act : Permet de décrypter l’action à mener dans DIAPSON

  • T_DatLiv : Permet de récupérer la date de livraison

• Identification : Balise de départ égale à « MessageCdes » et Type de Message « T_CdeLig »

• Type de Réception : à Définir

Message Sortant STATUT Complexe

Objectif

Génération d’un message sortant complexe portant sur plusieurs transactions sortantes de type :

• Intégration de lignes de commandes commerciales

• Lancement en Fabrication

• Déclaration de Fabrication

Lors de l’intégration d’une ligne de commande commerciale, d’un lancement en fabrication ou d’une déclaration de fabrication, une transaction sortante est postée dans le moniteur EIA. Toutes ces transactions sortantes seront ensuite prises en compte lors de l’exécution d’un document de type REB/Liste permettant de générer un message XML unique.

Exemple de Message XML

Correspondance « DebutMessage »

• Description de la correspondance

Cette correspondance permet de décrire les informations générales de début de message.

Elle débute à la balise « DebutMessage » et se termine à la balise « VersionDuType ».

• Détail de la correspondance

Correspondance « LigneStatut »

• Description de la correspondance

Trois correspondances sont utilisées, chacune correspondant au type de transactions sortantes gérées.

Elles débutent à la balise « LigneStatut» et se terminent à la balise « Annee » pour les correspondances de lancement en fabrication et de déclaration de fabrication et à la balise « LibelleEtat » pour la correspondance d’intégration de ligne de commande.

• Détail de la correspondance

Pour déclaration de Fabrication :

Pour intégration Ligne de Commande

Pour lancement en Fabrication

Correspondance « Information »

• Description de la correspondance

Cette correspondance permet de décrire les informations complémentaires de la transaction sortante pour les lancements en fabrication et les déclarations de fabrication.

Elle débute à la balise « Information » et se termine à la balise « Reference ».

• Détail de la correspondance

Requête DIALOG de Génération du Message XML

• Récupération des Transactions Sortantes à Traiter

La première partie de la requête DIALOG permet d’extraire les transactions sortantes postées dans le moniteur EIA et non traitées afin de générer le message XML.

COMMENTAIRE : "Recherche des Transactions Sortantes à Traiter"

POUR CHAQUE DTD EIABLMe AVEC DTD EIABLMe.Valide = CLO.0 ET DTD EIABLMe.BLTypMes = CLO."S" ET DTD EIABLMe.BLMesTraite FAUX ET DTD EIABLMe.BLTypFor = CLO."2" ET DTD EIABLMe.BLMesProb FAUX :

SI DTD EIABLMe.BLDossier = CLO."T_Statut"

VLO.IdeBL = DTD EIABLMe.BLIdeDiap

EIA-INITIALISATION POUR TRANSACTION-SORTANTE= VLO.IdeBL AVEC ERREUR= VLO.Erreur

SI VLO.Erreur = CGL.VIDE ET ( SCR.EIA_ActInt = CLO."ACT-LCT" OU SCR.EIA_ActInt = CLO."ACT-FAB" OU SCR.EIA_ActInt = CLO."ACT-INT" )

CREATION Liste LST.TRS :

PRENDRE TRS RefTrs = SCR.EIA_TypMes

PRENDRE TRS BLIde = VLO.IdeBL

PRENDRE TRS Act = SCR.EIA_ActInt

PRENDRE TRS Ent = SCR.EntTEn

PRENDRE TRS Cl1 = SCR.EntCl1

PRENDRE TRS Cl2 = SCR.EntCl2

PRENDRE TRS Cl3 = SCR.EntCl3

PRENDRE TRS Trt = SCR.EIA_MesTrait

FIN_BLOC

FIN_BLOC

FIN_BLOC

FIN_BLOC

….

• Génération du Message XML

• Indiquer que les Transactions Sortantes sont Traitées

A la fin de la boucle « POUR CHAQUE LST TRS », avant le « FIN_BLOC », mise à jour de la liste standard WfEntSel pour pouvoir marquer, dans le moniteur EIA que les transactions sortantes ont été traitées :

COMMENTAIRE : "/* Mise à Jour Statut Traitement sur TRS */"

CREATION Liste WfEntSel :

PRENDRE WfEntSel TEn = CLO."*TRS"

PRENDRE WfEntSel Cl1 = TRS.BLIde

FIN_BLOC

Récapitulatif du Paramétrage

Modèle XML : T_DecFab (Version DOC)

• Correspondances XML

  • T_DebMes : Début du Message

  • T_DecFab : Déclaration de Fabrication

  • T_LctFab : Lancement en Fabrication

  • T_IntLig : Intégration Ligne de Commande Commerciale

• Transactions Sortantes :

  • T_DFab : Déclaration de Fabrication

  • T_LctFab : Lancement en Fabrication

  • T_IntCde : Intégration Ligne de Commande Commerciale

• Documents sur Transactions Sortantes (41)

  • T_DecFab : Déclaration de Fabrication

  • T_LctFab : Lancement en Fabrication

  • T_IntCde : Intégration Ligne de Commande Commerciale

• Document REB / Liste (8) :

  • T_GenTRS : Génération Transactions Sortantes

• Requêtes DIALOG (REB)

  • T_GenTRS : Génération Message sur Transactions Sortantes

  • T_SelTRS : Sélection de Transactions Sortantes

Remarques

Les transactions sortantes sont définies comme étant « non synchronisées » afin d’être traitées par le document T_GenTRS

Les transactions sortantes T_DFab et T_LctFab sont renseignées sur les OFs

La transaction sortante T_IntCde est renseignée sur les lignes de besoin de gestion par utilisation de la requête GIL/ISIA_I

Les documents T_DecFab et T_LctFab ne permettent pas de générer un message XML direct à partir des correspondances car la partie « Information » ne peut pas être générée.

Le document T_IntCde permet de générer automatiquement un message sortant à partir des correspondances pour les transactions sortantes d’intégration des lignes de commandes commerciales

La requête DIALOG REB/T_GenTRS utilise la séquence DIALOG « T_XML » permettant d’initialiser le numéro du message (variable XML.T_NoMessage) et le nom du fichier XML généré (variable SCR.DOC_FicEdt). Lors de l’importation de cette requête, elle tombe en erreur. Il faut créer cette séquence puis re-générer cette requête.

La requête REB/T_GenTRS traite les transactions sortantes positionnées dans le dossier « T_Statut » du moniteur EIA. Ce dossier doit être créé pour faire fonctionner ce jeu d’essai.

Le document T_GenTRS peut être lancé de façon répétitive à partir d’un job portant sur le modèle « DIAP-EDT-EIA » et utilisant un traitement paramétré sur le traitement de base « ED ».