EIA -Messages Entrants

Réception de Messages

Principe de Réception

La réception de message dans le cadre du module « Echange Inter-Applicatifs » passe par l’exécution du traitement « EIA-REC » .

Paramétrage des Types de Réception

Les types de réception permettent d’indiquer à DIAPASON la méthode de récupération des fichiers à traiter.

Les types de réception sont définis pour toutes les sociétés.

Voici la GFG de définition des types de réception :

Onglet « Définition »

• Référence Référence type de réception.

• Désignation Désignation du type de réception

• Mot Directeur Mot directeur type de réception

• Commentaire Commentaire, texte libre

Onglet « Scrutation »

• Type Type de réception à proprement parler. Les types gérés sont :

• Requête

Référence requête REB dont le but est de pouvoir piloter, selon des règles de gestion particulières, les caractéristiques de chacun des messages entrants. Le contexte de la requête est le suivant :

- WFEIALisMes : Liste des messages récupérés

- SCR.EIA_TypRec : Référence Type de Réception en cours

- SCR.EIA_FicRec : Message entrant en cours (lien avec WFEIALisMes.MesRef).

La liste standard WFEIALisMes contient tous les messages issus de la règle d’extraction (R0 ou D0) et permet de piloter toutes les caractéristiques d’un message entrant. Sa structure est la suivante :

Paramétrage du type de réception : M0

• Paramètre 0 Doit contenir le nom du serveur d’édition, correctement paramétré, correspondant au serveur de messagerie.

• Paramètre 1 Liste d’identifiants et de mots de passe qui va surcharger l’identifiant et le mot de passe renseignés sur le serveur d’édition. Il sera utile pour se connecter sur un autre compte sur le même serveur de messagerie, et même pour relever le courrier sur plusieurs comptes d’un même serveur. Dans le cas d’un serveur de service en mode OAUTH2, il s’agit de la liste des identifiants de comptes définis dans la liste des « comptes OAuth 2 ».

• Paramètre 2 Correspond au chemin du dossier de stockage des messages et des pièces jointes. Ce chemin est indispensable au serveur d’application afin qu’il puisse traiter les messages. Il doit donc correspondre à un chemin Unix qui pointe vers le dossier de stockage des messages définit sur le serveur d’Edition.

• Paramètre 3 Cette liste permet de filtrer le téléchargement des pièces jointes des nouveaux messages. Si ce champ est vide, toutes les pièces jointes seront téléchargées. Sinon, il doit contenir une liste d’extension des pièces jointes autorisées. Le séparateur de cette liste est la virgule.

• Paramètre 4 Cette liste peut contenir une liste de dossiers sur le serveur de messagerie à scruter lors de la réception des nouveaux messages. Si celle-ci est vide, le dossier défaut « Boite de Réception » sera alors scruté. Le séparateur de cette liste est la virgule. Si la valeur est « * », tous les courriers non lus seront considérés.

Les messages électroniques envoyés par Outlook au format « Texte enrichi » ne sont pas interprétés dans Diapason.

Seuls les formats « Texte brut » et « Texte HTML » sont considérés.

Identification des Messages

Principe d’Identification

L’identification d’un message entrant permet d’indiquer à DIAPASON la manière de traiter ce message. Cette phase correspond à l’association de tout message entrant avec un type de message. Les règles de traitement du message sont définies sur le type de message.

Dans le cadre d’une identification d’un format XML, il sera possible de conditionner l’association avec un type de message en testant l’existence d’une balise ou sa valeur. Dans le cadre de fichiers ascii, la condition pourra dépendre du contenu dont la localisation dans le fichier pourra être donnée selon une syntaxe précise.

Les règles d’identification sont définies pour toutes les sociétés.

Paramétrage des Règles d’Identification

Il existe deux types de règles d’identification de messages :

1. Règles d’Identification / XML

2. Règles d’Identification / Autres Formats

Règles d’Identification / XML

L’application de définition des règles d’identification / XML est accessible depuis l’explorateur et se présente sous la forme d’une GFG DIAPASON :

➡️ GFG Définition Règles d’Identification / XML

Onglet « Définition »

• Ordre :

Numéro d’ordre de traitement de la règle d’identification. Cette notion est importante car elle permet de prioriser leur exécution et ainsi d’obtenir des tests du type :

SI Règle 1 vraie

ALORS ....

SINON SI Règle 2 vraie

ALORS ..

SINON SI Règle n vraie

ALORS

SINON

• Balise Départ : Référence balise départ interne DIAPASON. Toute règle d’identification / XML est associée à une balise départ. C’est cette référence qui est le point de départ d’exécution des règles. Il est à noter que la balise départ interne correspond à un départ de modèle XML DIAPASON.

Exemple :

• Description Rè..

Zone facultative permettant de décrire une règle par rapport à l’existence d’une balise ou par rapport à la valeur d’une balise donnée contenue dans le message. Cette zone est facultative dans la mesure où la balise de départ peut suffire à différencier deux messages XML dans nombre de cas.

Syntaxe d'une règle

Une balise est désignée par son nom compris entre les signes "<" et ">".

<Bal_1>

Cette syntaxe signifie que la balise Bal_1 doit être présente dans le message.

Le fait d’écrire une telle règle signifie que cette condition est suffisante pour faire l’association avec le type de message voulu.

<Bal_1>=Valeur

Cette syntaxe signifie que la balise Bal_1 doit être présente dans le message et que son contenu est ‘Valeur’ (traduit en Progress par MATCHES ‘*Valeur*’).

Le contenu ne doit pas être entouré de quotes ou de double quotes. Les *, nécessaire au MATCHES ne sont pas à préciser non plus.

<Bal1> ;<Bal2>=FAB_LAP : le ‘ ;’ permet de cumuler les conditions. Pour que cette condition soit vraie, Bal1 ET Bal2 doivent être présentes dans le message ET Bal2 doit contenir FAB_LAP dans sa valeur.

• Société

Référence société du type de message à associer. Correspond en fait à la société de travail de l’action interne issue du type de message associé. Le schéma de gestion du multi-société étant le suivant :

• Type Message Référence type de message (définie dans la société sus renseignée) à associer aux messages répondant à la règle d’identification décrite.

• Modèle XML Zone non saisissable déduite du couple Société/Type Message renseigné.

• Version XML Zone non saisissable déduite du couple Société/Type Message renseigné.

• Ambiguïté Zone non saisissable indiquant si la règle décrite présente une ambiguïté avec une autre règle déjà définie. Les ambiguïtés peuvent être :

- une règle est déjà rattachée à la balise de départ.

- une règle repose déjà sur ce couple modèle/version XML.

La présence d’une ambiguïté n’est pas bloquante car le numéro d’ordre et la description de la règle peuvent permettre de lever l’ambiguïté. Cette information joue un rôle informatif avant tout.

Quelles actions sont disponibles ?

• Régénération Identification Cette action a pour but de déterminer de façon automatique les règles d’identification possibles à partir de la base de modèles/version XML en exploitation et de la base des types de messages définis au moment de son lancement. Elle se présente sous la forme d’un tableur en saisie se présentant comme suit :

Chaque ligne du tableur représente la définition d’une règle d’identification. A ? Zone non saisissable. Flag indiquant si il y a une ambiguïté avec une autre règle. N ? Zone non saisissable. Flag indiquant que la règle est nouvelle (non encore référencée dans la base). S ? Zone saisissable. Permet d’indiquer que l’on veut supprimer la règle. La suppression aura lieu lors de la validation du tableur. Balise Départ: Zone saisissable. Ce tableur permet de créer des règles d’identification, cette cellule reçoit la référence balise départ interne DIAPASON rattachée à la règle. Ordre: Zone Saisissable. Numéro d’ordre d’exécution de la règle d’identification lors de la phase d’identification effectuée par le traitement de réception des messages. Description Règle: Zone saisissable. Permet de définir les différentes conditions d’association au couple société/type message en fonction du contenu du message . Société: Zone non saisissable. Référence société associé au type de message. Type Message: Zone non saisissable. Référence type message rattaché à société. Modèle XML: Zone non saisissable. Référence modèle XML sur lequel repose le couple société/type message. Version XML: Zone non saisissable. Version XML du modèle rattaché au couple société/type message.

• Identification / DIALOG Cette action permet de renseigner une requête décrivant les règles d’association message au couple société/type message. Cette règle d’identification est la seule ne raisonnant pas par la notion de balise de départ et est marquée par le caractère ‘*’ dans la référence balise de départ.

Cette règle, si définie, est exécutée en fin de phase d’identification si aucune règle n’a pu déterminer d’association message / couple société/type message. Le contexte de cette règle est :

• WFEIALisMes

• SCR.EIA_FicRec

Il ne faut pas faire de CREATION LISTE WFEIALisMes dans cette requête.

Règles d’Identification / Autres Formats

Ce type de règle d’identification est dédié à l’association des messages entrants au format ascii et des couples société/type de message.

➡️ GFG Définition Règle Identification / Autres formats

• Ordre Ordre d’exécution de la règle d’identification.

• Description Règle Zone facultative permettant de décrire une règle par rapport à une valeur dans le contenu du fichier. Une syntaxe particulière permet de décrire l’emplacement (ligne, colonne) et la longueur de la chaîne de caractères à tester OU, dans le cadre d’un contenu de fichier sous forme de liste chaînée, de préciser la ligne, le numéro de mot et le caractère séparateur pour localiser la chaîne de caractères à tester. Il est aussi possible de raisonner à partir du nom du fichier Les syntaxes sont les suivantes :

FIC=Valeur Cette syntaxe est vraie si le nom du fichier contient Valeur (traduit en Progress par MATCHES ‘*Valeur*’). Il ne faut cependant pas entourer Valeur par des ‘’ ni utiliser le caractère ‘*’.

CHAINE[Ligne,Colonne,Longueur]=Valeur  Cette syntaxe permet de positionner la chaîne de caractères à tester dans un fichier dont les données sont concaténées. Cette chaîne doit contenir la valeur précisée pour que la règle soit vraie.

Ex : « CHAINE[1,1,2]=OF » pour identifier la chaine « OF,145001,ALU »

CHAINE[Ligne,Séparateur,Numéro mot]=Valeur Cette syntaxe permet de positionner la chaîne de caractères dans un fichier dont les données sont sous forme de liste chaînée. Cette chaîne doit contenir la valeur précisée pour que la règle soit vraie.

Ex : « CHAINE[1,@,1]=OF » pour identifier la chaine « OF@145001@ALU »

• Société Référence société du type de message à associer

• Type Message Référence type de message (définie dans la société sus renseignée) à associer aux messages répondant à la règle d’identification décrite.

Définition règle d’identification pour réception via messagerie

La réception de message via serveur de messagerie (type M0) impose une définition de règles d’identification particulière. Ce chapitre en décrit le principe.

Les messages électroniques entrants issus de la scrutation d’une boite de messagerie via un type de réception « M0 » sont retranscris par DIAPASON sous la forme d’un message xml dont la structure est la suivante :

La règle d’identification portera obligatoirement sur la balise de départ « IS_MAIL ».

Deux solutions possibles pour le traitement du contenu d’un message électronique :

Les données sont directement inscrites dans le corps du message lui-même

Ce type de message électronique peut être considéré comme un message xml simple car le corps décrit les données à traiter. DIAPASON génèrera un fichier xml sous la forme :

La règle d’identification peut tester la présence de la balise « D_ART01 » et aiguiller sur une type de message (« 0 » sur correspondances XML ou « 9 » décryptage complexe).

Les données sont inscrites dans une ou plusieurs pièces jointes du message

Ce type de message électronique sera considéré comme un message xml complexe car le fichier xml ressort uniquement les noms des fichiers effectivement à traiter (balise IS_CPJ dans le descripeur IS_PJ :

Note : dans tous les cas de figures il est conseillé de décrire une règle d’identification prioritaire (sur balise de départ IS_MAIL et testant la présence de la balise IS_PJ) destinée au traitement de messages électroniques avec pièces jointes. Cette règle devra faire l’association avec un type de message associé à la méthode de traitement « 9 » (décryptage complexe) .

Les règles d’identification sur des messages électroniques dont le corps contient les données à traiter peuvent faire l’objet de règles d’identification sur des types de messages associés aux méthodes de traitement « 0 » (par correspondance XML) ou « 9 » (décryptage complexe). Elles seront définies APRES la règle concernant les messages avec pièces jointes.

Traitement des Messages

Principe de Traitement

Le principe de traitement d’un message repose sur l’interprétation du message et l’exécution d’une action interne DIAPASON. La phase d’interprétation du message repose sur des caractéristiques définies sur les types de messages, l’action interne peut quand à elle être définie à plusieurs niveaux. Ce chapitre a pour but de détailler ces deux phases.

Paramétrage des Types de Message (et événements)

Tout message entrant, pour être interprété par DIAPASON doit être associé à un Type de Message. Ce dernier défini des caractéristiques de traitement décrites ci dessous. Les types de messages sont multi-sociétés.

Les types de messages sont définis par le biais d’une GFG DIAPASON accessible depuis l’explorateur applicatif telle que :

➡️ GFG Définition des Types de Messages

Onglet « Définition »

• Référence Référence Type de Message

• Désignation Désignation du Type de Message

• Mot Directeur Mot Directeur du Type de Message

• Famille Référence famille du Type de Message. Ce champ a pour but de classer les types de messages définis. Lien avec Paramètre Utilisateur ‘EIA/TME-FAM’.

• Sous-Famille Référence sous-famille du Type de Message. Ce champ a pour but de classer les types de messages définis. Lien avec Paramètre Utilisateur ‘EIA/TME-SFA’.

• Commentaire Commentaire libre.

• Mode Traitement: Le mode de traitement influe directement sur la manière dont le message va être interprété par DIAPASON. Les différents modes de traitement sont :

  • ‘0’  : Correspondance XML. Ce mode de traitement implique que le message associé à ce type de message est au format XML, qu’un couple modèle/version XML en exploitation est défini dans DIAPASON pour interpréter ce message, enfin qu’il existe au moins une correspondance définie sur le couple modèle/version XML de façon à pouvoir faire le lien entre les données lues dans le fichiers et les mises à jour dans DIAPASON qu’elles impliquent.

  • ‘1’  : Message Entrant-Sortant. Ce mode de traitement implique que la résultante du traitement sera la génération par DIAPASON d’un message sortant. Ce mode autorise les messages de tout format, ce dernier étant précisé dans la suite de la définition du type de message.

  • ‘9’  : Décryptage Complexe; Ce mode de traitement passe obligatoirement par l’exécution d’une requête REB pour la lecture et le traitement du message. Ce mode est obligatoirement dédié aux fichiers au format ASCII et aux fichiers XML type DTCAM pour lesquels il est complexe de modéliser une correspondance par rapport aux mises à jour induites. Dans ce cas, la liste « WfFicTransfert » est alimentée et exploitable dans la REB.

  • ‘99’ : Evènement. Ce mode de traitement est dédié à la réception des évènements. L’action interne est obligatoirement indiquée. Cette gestion remplace l’ancienne gestion des évènements DIAPASON.

• Modèle XML Référence modèle XML utilisé pour la lecture et le traitement du message. Le modèle est forcément un modèle en exploitation. Cette zone est active pour les modes de traitement ‘0’, ‘1’ et ‘9’.

• Version XML Numéro de version associé au modèle XML. La version est forcément une version en exploitation. Cette zone est active pour les modes de traitement ‘0’, ‘1’, et ‘9’.

• Action Interne Référence action interne à mener par DIAPASON. Cette zone concerne uniquement le mode de traitement ‘99’ (Evènements). Les actions internes disponibles sont visibles dans l’application de consultation des actions internes.

• Entité Zone non saisissable. Renseignée uniquement pour les modes de traitement ‘99’ (Evènements). Indique la référence entité (au sens DIAPASON) sur laquelle la mise à jour aura lieu.

Onglet « Réception Message »

Cet onglet a pour but de définir les caractéristiques de réception d’un message.

• Type Pré. Enreg Permet de définir des règles d’enregistrement du message dans la boîte aux lettres du moniteur EIA. Ces règles sont dépendantes du contenu du message. Actuellement cette zone n’est pas gérée (un seul choix possible => Sans Contrôle).

• Règles Déc./ Détermine les règles de déclenchement du message, conditionne la réception proprement dite du message dans la boîte aux lettres du moniteur EIA. Les règles existantes sont :

  • ‘0’ Enregistre le message entrant : Le message est toujours réceptionné, aucun contrôle particulier n’est effectué.

  • ‘1’ Supprime les messages en erreur : Le message est toujours réceptionné, s’il existe des messages identiques en erreur, ils seront supprimés. Des messages sont dits identiques lorsqu’ils ont la même clé d’identification.

  • ‘2’ Supprime le message en cours : S’il existe au moins un message identique dans la boîte aux lettres du moniteur EIA et que ce dernier n’est pas traité, la réception du message en cours n’est pas effectuée.

  • ‘3’ Transfère le message dans BL erreur : Le message est toujours réceptionné mais s’il existe un message identique en erreur alors il sera réceptionné dans la boite aux lettres des éléments en erreur.

• Synchronisé ? Ce flag indique si le traitement du message doit s’enchaîner automatiquement dés la phase de réception terminée.

• Niv. Importance Niveau d'importance : les valeurs possibles sont issues des paramètres utilisateurs toutes sociétés ‘EIA’, ‘NIV-IMP’. Attention cette notion n’a pas pour but de prioriser les messages dans les boites aux lettres du moniteur. Il sera possible toutefois d’utiliser cette zone pour des filtres dans les listes du moniteur.

• Dossier BL EIA Référence dossier dans lequel le message va être réceptionné. Les valeurs possibles sont issues des paramètres utilisateur toutes sociétés ‘EIA/DOS-BL’.

• Conf. Récep ? Ce flag indique si DIAPASON doit envoyer ou non une confirmation de réception pour ce message.

• Doc. Conf. Rec. Référence document pour la confirmation de réception.

Les champs suivants sont issus de la lecture du fichier, aussi est-il possible de définir pour chacun d’eux une règle dont la syntaxe est :

<Balise> : Le champ contenant cette syntaxe sera affecté par la valeur de la balise donnée. Format XML uniquement.

<Balise1> ;<Balise2> : idem que règle précédente, les valeurs des balises sont concaténées. Format XML uniquement.

Valeur : Il est possible de donner une valeur constante. Cette syntaxe est valable quel que soit le format du fichier (XML ou Autre).

CHAINE[ligne,colonne,longueur] OU CHAINE[ligne,séparateur,numéro mot] : concerne exclusivement les fichiers au format ASCII, le champ prendra la valeur de la chaîne dont le positionnement est donnée entre crochets suivant le format du contenu du fichier( concaténé ou liste chaînée).

Pour les fichiers XML, il est possible de donner le chemin complet de la référence balise dans le cas ou la balise souhaitée existe plusieurs fois dans le message. La syntaxe est la suivant <Balise1/Balise2/Balise3/Balise>.

• Clé Clé d’identification du message. Permet d’identifier un message (voir Règles Déc. ci-dessus),

• Emetteur Référence de l’émetteur du message.

• Objet Description générale du message.

• Application Ori. Référence Application dont le message est issu.

• Société Ori. Référence Société dont le message est issu.

• Pièces Jointes Liste chaînée des noms de fichiers composants les pièces jointes du message.

• Req.Comp.Ide Référence requête REB permettant de définir ou re-définir les caractéristiques de chacun des messages en cours de réception. Le contexte de la requête est le suivant :

WFEIALisMes : Liste des messages en cours de réception

SCR.EIA_TypRec : Référence Type de Réception en cours

SCR.EIA_FicRef : Référence du message courant

SCR.EIA_SocMes : Référence société du message (= société du type de message )

SCR.EIA_TypMes : Référence Type de Message associé au message courant.
SCHEMA RECAPITULAIF DE LA PHASE DE RECEPTION D’UN MESSAGE

Onglet « Traitement Entrant (1) »

• Trans. Glo Zone saisissable uniquement pour les types de message dont le mode de traitement est ‘0’ (Correspondance XML) ou ‘9’ (Décryptage Complexe). Ce flag indique si le traitement du message se déroule dans un seule transaction ou non.

• Requête Traitement Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘9’ (Décryptage Complexe). Zone obligatoire, en effet ces types de messages ne peuvent être traités que par le biais d’une requête REB.

• Critères Défaut Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘9’ (Décryptage Complexe). Bouton lançant l’application de définition des caractéristiques (saisie, affichage, initialisations…) des critères de la requête sus renseignée.

• Correspondances Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘0’ (Correspondance XML). Permet d’indiquer quelles seront les correspondances devant être effectivement traitées avec ce type de message. En effet il se pourrait que plusieurs correspondances soient définies sur un couple modèle/version XML et que le type de message n’en gère qu’une en particulier (Voir chapitre sur gestion des correspondances)

• Départ Transaction Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘0’ (Correspondance XML). Dans le cas où la zone Trans. Glo n’est pas cochée, le bouton permet de définir parmi les correspondances sus sélectionnées, lesquelles démarreront une transaction.

• Message Sortant Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘1’ (Messages Entrant-Sortant). Reçoit la référence du document de type message sortant (voir définition des documents, définition messages sortants). Ce document est exécuté lors du traitement du message entrant, le message servant de critère (contexte en entrée) du document. Un chapitre plus détaillé est dédié aux messages entrants-sortants.

• Protocole Zone saisissable uniquement pour les types de messages dont le mode de traitement est ‘99’ (Evènements) et dont l’action interne est EV-R-ML. Reçoit la référence de la requête de traitement de l’évènement reçu.

• Objet du Mail Drapeau indiquant si l’objet du mail doit être scruté ou non.

• Corps du Mail Drapeau indiquant si le corps du mail doit être scruté ou non.

• Pièces Jointes Drapeau indiquant si les pièces jointes doivent être scrutées ou non.

• Noms Pièces Jointes Permet d’indiquer le ou les noms des fichiers attachés au mail. Chacun des noms de fichiers devra être séparé par une virgule.

• Types Pièces Jointes Permet d’indiquer le ou les types des fichiers attachés au mail. Chacun des types de fichiers devra être séparé par une virgule. Par type on entend extension.

Onglet « Traitement Entrant (2) »

• Répert. Travail Peut contenir un répertoire donné. Si renseigné, le fichier sera copié dans ce répertoire avant d’être traité (instruction « cp » UNIX).

• Cde. Sys. Avt. Commande système exécutée avant traitement du message.

• Requête Avt. Cette requête est exécutée avant le début du traitement du message. Voir contexte ci-dessous.

• Cde. Sys. Apr. Commande système exécutée après traitement du message.

• Requête Apr. Cette requête est exécutée après le traitement du message. Voir contexte ci-dessous.

• Répert. Erreur Peut contenir un répertoire donné. Si renseigné et si le traitement du message est en erreur, le fichier sera transféré de son emplacement vers ce répertoire (instruction mv UNIX).

• Document Erreur Peut contenir la référence d’un document DIAPASON qui s’exécutera si le traitement du message termine en erreur.

• Conf. Lecture ? Flag indiquant s’il y a gestion ou non d’une confirmation de lecture.

• Doc. Conf. Lec. Si il y a gestion de confirmation de lecture, doit contenir la référence du document DIAPASON destiné à la génération de la confirmation.

• Archivage ? Flag indiquant s’il y a gestion ou non d’archivage.

• Répertoire Archivage Si il y a gestion de l’archivage, doit contenir un répertoire de destination pour le fichier venant d’être traité (traitement OK).

• Horizon Purge Indique le nombre de jours maximum de présence d’un message dans la boîte aux lettres des éléments traités dans le moniteur EIA.

Si l’horizon est nul, la purge du message traité n’est pas réalisée.

• Histo. Sur Entité ? Si coché, permet de tracer toutes les actions effectuées sur la ou les entités gérées.

• Entités Bouton permettant de sélectionner les entités pour lesquelles on désire suivre un historique des actions menées (Histo. Sur Entité = Oui). Les entités présentées sont déduites des correspondances paramétrées sur l’onglet « Traitement Entrant (1) ». Les correspondances n’étant pas forcément définies sur entité, il est tout à fait possible qu’aucune entité ne soit sélectionnable et de ce fait la gestion de ces deux champs n’est pas effective.

Le contexte des requêtes de début et fin traitement message entrant est le suivant :

SCR.EIA_FicRec : nom du fichier courant.

Onglet « MàJ Complémentaire »

• MàJ Complémentaire Le bouton permet d’accéder à un éditeur en saisie pour insérer un bloc Progress exécuté en fin de traitement de correspondance. Ce bloc est utilisé dans le cadre de la gestion des type de message de mode ‘99’ (Evènements).

Onglet « Caractéristiques »

• Caractéristiques Zone de texte dédié à la description de caractéristiques générales tel que le format date, le format décimal ... pouvant être commun à tous les messages rattachés à ce type. Ce champ n’est actuellement pas géré.

• Bases Bouton permettant de sélectionner les bases nécessaires au traitement du message. Utilisé uniquement dans le cadre de types de messages dont le mode de traitement est ‘99’ (Evènement).

Quelles actions sont disponibles ?

• Génération Message Cette action se présente, à l’image des actions de génération de requêtes, en trois sous-actions permettant la génération des « Messages sélectionnés », « Messages à Re-Générer » ou de « Tous les Messages ». Un type de message ne peut être exploitable qu’à la condition qu’il est était généré.

Cette action est active pour les types de message dont le mode est ‘0’ (Correspondance / XML), ‘1’ (Message Entrant-Sortant), ‘99’ (Evènement) .

Une action « Environnement EIA à Régénérer » permet de regénérer, tous les types de messages, les correspondances et les documents à Re-Générer.

• Gestion Evènement Pour les types de message de type « 99 », cette action permet d’accéder à l’application de définition de la structure de l’évènement.

Cette définition est réalisée par le biais d’une GFG telle que 

Onglet « Définition »

• Information Information contextuelle de l’action interne. Obligatoire, elle doit contenir, soit une variable spécifique de l’action interne, soit une variable standard ou spécifique de l’entité liée à l’action interne. Une sélection est disponible sur cette zone.

• Type Type de l’information. Cette zone est initialisée avec le type de l’information renseignée précédemment. Les types possibles sont Caractère, Numérique, Date, Logique.

• Stocké Indique si cette information est ou non stockée dans la boîte aux lettres des événements transmis. Une information doit être stockée pour être transmise par l’événement.

• Liste Nom de la liste de détail dans laquelle on stocke l’information. Non gérée.

• N.Ord Numéro d’ordre dans la liste ci-dessus. Non géré.

• Zone La liste déroulante présente la liste des champs de la boîte aux lettres des événements transmis. La saisie est obligatoire si la zone «Stocké» est cochée.

Il est recommandé d’utiliser un champ correspondant au type de l’information ; les champs EvtCar* correspondant au type Caractère, les champs EvtDat* correspondant au type Date, les champs EvtLog* correspondant au type Logique et les champs EvtNum* et EvtRec* correspondant au type Numérique.

• Format Format utilisé pour le stockage de l’information. Le format saisi doit correspondre au type de l’information. Une sélection est disponible sur cette zone.

Onglet « Valeurs Défaut »

• Commentaire Commentaire associé à l’information. Cette zone n’est pas saisissable.

• Valeur Alpha. Valeur Alphanumérique par défaut. Cette zone n’est saisissable que si l’information est de type Caractère.

• Valeur Num. Valeur Numérique par défaut. Cette zone n’est saisissable que si l’information est de type Numérique.

• Valeur Date Valeur Date par défaut. Cette zone n’est saisissable que si l’information est de type Date.

• Valeur Logique Valeur Logique par défaut. Cette zone n’est saisissable que si l’information est de type Logique.

Seules les variables définies dans la structure d’un événement peuvent être utilisées dans le bloc de mise à jour complémentaire de celui-ci (sous la forme V_NomVariable).

Les actions disponibles sur cette application sont :

Actions standards GFG : Création, Modification, Duplication, Suppression

Paramétrage des Correspondances XML Entrantes 

Définition des Correspondances XML

La définition des Correspondances permet d’associer des balises d’un modèle XML à des variables DIAPASON ou à des valeurs défauts. Cette application est accessible depuis la branche « Gestion Correspondances » de l’explorateur applicatif . Il est à noter que cette application est accessible aussi depuis la gestion de définition des modèles XML en exploitation par le biais de deux actions spécifiques (cf. Modèles XML en Exploitation).

➡️ GFG de définition des correspondances

Onglet « Définition »

• Modèle Référence modèle XML en exploitation servant de support de définition de la correspondance

• Version Numéro de version du modèle XML sus référencé.

• Correspondance Référence correspondance.

• Désignation Désignation correspondance.

• Commentaire Zone de texte libre permettant de données des informations complémentaires à titre d’information.

Onglet « Caractéristiques »

• Type Correspondance Permet de définir si la correspondance est utilisée pour un message entrant ou pour un message sortant.

• Balise Début Le bouton permet de choisir, dans la structure du modèle XML, la balise de départ de l’action rattachée à la correspondance.

• Action Interne: La liste déroulante permet de sélectionner l’action interne entrante devant être exécutée par DIAPASON. Cette zone est obligatoire. On distingue trois types d’actions internes entrantes :

  • ACT-SIM : Action simple hors entité. Correspondent aux actions disponibles par ENR-ACT-ENT en dehors de la notion d’entité.

  • ENT-MAJ : Action simple sur entité. Correspond aux actions disponibles par ENR-ACT-ENT agissant sur les entités GFD.

  • ENT-INI : Action d’initialisation de contexte par le biais d’une requête. Ces actions ne concernent que les messages entrants-sortants. Le principe repose sur le fait de renseigner une requête (REB ou REN) et d’indiquer sur quelle liste la correspondance doit se faire (si requête REB). Par la suite lors de l’exécution du document pour génération du message sortant, la liste donnée et la correspondance seront connues en contexte d’entrée.

• Entité – Requête

Permet de renseigner l’entité ou la requête suivant l’action interne saisie précédemment. Cette zone est obligatoire. Une sélection est possible sur cette zone.

Cette zone n’est saisie que si l’action interne est ENT-MAJ, INI-REB ou INI-REN.

Pour l’action interne ENT-MAJ, elle doit contenir une entité DIAPASON. Les entités possibles sont toutes les entités GFD de DIAPASON.

Pour l’action interne INI-REB, elle doit contenir une requête de type REB.

Pour l’action interne INI-REN, elle doit contenir une requête de type REN.

• Liste Requête

La liste déroulante permet de sélectionner la liste de la requête REB pour laquelle on souhaite faire la correspondance. Cette zone est obligatoire. Cette zone n’est saisie que si l’action interne est INI-REB.

Onglet « Message Entrant »

• Transaction Unitaire Indique si une transaction unitaire sera utilisée pour la correspondance. Cette notion est prioritaire sur les notions de transaction définies sur la GFG de définition des types de messages.

• Visib. Bal. Sup ?

Par défaut coché à oui, permet lors de la définition du détail de correspondance par rapport au modèle XML d’avoir toute l’arborescence visible ou pas . Dans le cas contraire seule la partie de l’arborescence (fils) de la balise de départ donnée (cf. Balise Départ) sera visible.

• Requête Début Référence requête de type REB exécuté avant traitement de la correspondance. Voir contexte requête ci-dessous.

• Critères Défaut Bouton permettant de définir les caractéristiques des critères (saisie, affichage, initialisation,..) de la requête sus renseignée.

• Requête Fin Référence requête de type REB exécuté après traitement de la correspondance. Voir contexte requête ci-dessous.

• Critères Défaut Bouton permettant de définir les caractéristiques des critères (saisie, affichage, initialisation,..) de la requête sus renseignée

Contexte requête Avant et Après Traitement des correspondances :

Dans chacune des requêtes les variables XML,SCR,VCR, les structures WfEntVar et WfEntAct sont visibles.

Le contexte en entrée de requête est le suivant :

• SCR.EIA_MesIde : Identifiant du message que l’on traite

• SCR.EIA_CorRef : Référence Correspondance courante

• SCR.EIA_BalRef : Référence balise de départ correspondance

• SCR.EIA_BalIdP : Identifiant Père de la balise de départ

• SCR.EIA_BalIdF : Identifiant Fils de la balise de départ

• SCR.IAP_ModeAcc : Mode accès (Début correspondance ‘D’ ou Fin correspondance ‘F’)

Onglet « Message Sortant »

Cet onglet est spécifique aux correspondances sortantes, il sera décrit dans le paragraphe des correspondances sortantes.

Onglet « Qui, Quand ? »

• Statut Statut de la correspondance.

• Erreur Indique si la correspondance est ou non en erreur. Une correspondance est en erreur si le programme de traitement de cette correspondance n’a pas pu être généré.

• A Générer Indique si la correspondance doit ou non être générée. Une correspondance doit être générée si on modifie une des informations de définition ou si on en modifie le détail ou si la requête rattachée à la correspondance (cas des actions INI-REB et INI-REN) a été re-générée. Si la génération du programme de traitement d’une correspondance se déroule anormalement, la correspondance reste à générer

• Util. Création Utilisateur ayant créé la correspondance

• Date Création Date de création de la correspondance

• Heure Création Heure de création de la correspondance

• Util. Modification Utilisation ayant effectué la dernière modification de la correspondance.

• Date Modification Date de dernière modification de la correspondance

• Heure Modification Heure de dernière modification de la correspondance.

• Util. Génération Utilisateur ayant effectué la dernière génération du programme de traitement de la correspondance.

• Date Génération Date de dernière génération du programme de traitement de correspondance.

• Heure Génération Heure de dernière génération du programme de traitement de correspondance.

• Programme Programme de traitement de correspondance.

Détail Correspondances XML 

Il existe quatre méthodes de définition du détail des correspondances XML.

• Définition / Modèle

• Définition / Variables

• Définition / Variables Obligatoires

• Définition / Toutes Variables

Chacune de ces méthodes correspond à une action depuis la liste des entêtes de correspondances.

Sur cette application, les actions possibles sont :

• Actions standards GFG : Création, Modification, Duplication, Suppression

• Actions de Génération des Programmes des Correspondances . Trois actions permettent de regénérer les programmes de traitement des correspondances :

  • Correspondances Sélectionnées : les correspondances sélectionnées (ou la correspondance courante si aucune sélection n’a été faite)

  • Correspondances à Re-Générer : toutes les correspondances ayant été modifiées et n’ayant pas été re-générés (Information «A Générer» cochée). Remarque : une branche de l’explorateur applicatif des Echanges Inter-Applicatifs, « Correspondances à Générer »  présente la liste de toutes les correspondances à re-générer.

  • Toutes les Correspondances : toutes les correspondances

Ces actions de génération lance le traitement GEN-REQ qui peut être exécuté en mode interactif ou en mode batch.

• Action de Génération « Environnement EIA à Régénérer »

Cette action permet de regénérer, tous les types de messages, les correspondances et les documents à Re-Générer.

• Définition / Modèle

Dans cette approche, le point de départ de définition d’un détail de correspondance est le modèle XML (à l’image du message XML à traiter). On raisonne en balise et on y affecte des variables.

Cette action permet de définir le détail des correspondances à partir de l’arborescence du couple modèle/version XML rattaché sur l’entête.

Le principe est de décrire les liens Balises-Information DIAPASON de façon à ce que l’action interne puisse être menée à bien.

Au fur et à mesure de la définition des détails de correspondances, les icônes du tree-view vont évoluer de façon à avoir un état visuel de l’avancement. Le tableau ci-dessous décrit les différents icônes utilisés dans cette représentation :

Les icônes vont représenter à la fois le type de balise mais aussi le type de correspondance définie pour ce lien.

	Balise	PDF	Balise Valeur	Attribut
Aucune correspondance
Correspondance sur Variable	(idem sur fond bleu)	(idem sur fond bleu)	(idem sur fond bleu)	(idem sur fond bleu)
Valeur défaut	(idem sur fond jaune)	(idem sur fond jaune)	(idem sur fond jaune)	(idem sur fond jaune)
Début de Lien	(idem sur fond vert)	(idem sur fond vert)	(idem sur fond vert)	(idem sur fond vert)
Fin de Lien	(idem sur fond rouge)	(idem sur fond rouge)	(idem sur fond rouge)	(idem sur fond rouge)

Pour définir le détail de correspondance, il suffit de se positionner sur la balise désirée pour accéder à la fiche de définition de sa correspondance.

➡️ Description de la fiche de définition du détail de correspondances :

Onglet « Définition » :

• Ordre

Numéro ordre de traitement de la correspondance. Cet ordre permet de prioriser lors du traitement du message les affectations des variables et permet donc de se détacher de la structure du message lui-même. Par exemple, il est tout à fait envisageable d’avoir un message XML présentant une balise <OF> suivie d’une balise <Etape> et de vouloir d’abord initialiser la variable réceptionnant la valeur de la balise <Etape>.

• Variable

Référence variable associée à la balise. Les variables possibles sont déterminées en fonction de l’action interne (définie sur l’entête de correspondance). Le tableau ci-dessous présente un récapitulatif des variables par action interne :

• Balise Bouton permettant de sélectionner la balise sur laquelle la correspondance doit s’effectuer. Cette zone est inactive dans ce cadre de définition puisque le choix de la balise se fait en se positionnant dessus dans le tree-view.

• Visib. Bal. Sup. Si coché, ce flag indique que si la balise en cours de définition n’est pas présente dans le message (occurrence 0/1 ou 0/n), DIAPASON remontera les niveaux d’arborescence du message XML traité et cherchera la première balise ayant le même nom. Si il en trouve une, il affectera alors la valeur à la variable rattachée à la balise non présente.

• Formule Référence formule. Possibilité de re-travailler la valeur de la balise courante par rapport à des règles données (exemple, calcul d’une variable date à partir de trois balises <jour>, <mois>, <annee>). Voir chapitre détaillant la définition des formules.

• Par. 1 Formule Paramètre d’entrée éventuel de la formule.

• Par. 2 Formule Paramètre d’entrée éventuel de la formule.

• Par. 3 Formule Paramètre d’entrée éventuel de la formule.

• Par. 4 Formule Paramètre d’entrée éventuel de la formule.

• Par. 5 Formule Paramètre d’entrée éventuel de la formule.

• Valeur Alpha. Valeur défaut alphanumérique. Ce champ est actif si la variable associée est de type alphanumérique.

• Valeur Num. Valeur défaut numérique. Ce champ est actif si la variable associée est de type réel ou entier.

• Valeur Date Valeur défaut date. Ce champ est actif si la variable associée est de type date.

• Valeur Log. Valeur défaut logique. Ce champ est actif si la variable associée est de type logique.

Principe d’affectation des valeurs défaut :

La variable associée est initialisée par sa valeur défaut définie sur sa définition. Si une valeur défaut est définie au niveau de la correspondance, alors elle lui est affectée. Enfin si la lecture du message renvoie une valeur par rapport à la balise donnée, alors elle lui est affectée.

Onglet « MàJ Complémentaires »

• MàJ Comp. Le bouton permet d’accéder à un éditeur en saisie pour insérer un bloc Progress exécuté en fin de traitement de la correspondance. Ainsi il est possible de re-travailler la valeur récupérée selon des règles de gestion éventuelles.

Onglet « Définition Balise »

Toutes les informations de cet onglet sont en consultation. Elles permettent d’avoir en ligne les informations inhérentes à la balise courante.

• Type Nœud: Indique le type de la balise. Les différents types sont :

  • ‘B’ : balise. Ce type défini un ensemble (fils) de balises de tout type.

  • ‘V’ : Valeur. Une balise valeur est une balise de dernier niveau (aucun fils) contenant une valeur.

  • ‘A’ : Attribut. Une balise attribut décrit plusieurs valeurs chacune étant décrite par Var = Valeur et ce, dans le référencement de la balise elle-même (exemple : <Balise_Attr Var1=Val1 Var2=Val2 ... /> )

• N° Enfant

Numéro ordre de description dans le modèle XML par rapport à la balise père.

• Modèle Pré-Défi.

Si renseigné, ce champ indique que la balise provient de ce dit modèle pré-défini. Voir chapitre détaillant la gestion des modèles XML.

• Version Pré-Défi.

Si renseigné, ce champ indique que la balise provient de ladite version du modèle pré-défini sus renseigné. Voir chapitre détaillant la gestion des modèles XML.

• Référence

Référence ou nom de la balise.

• Désignation

Désignation de la balise.

• Occurrence: Règle permettant d’indiquer si une balise est obligatoirement existante dans un message XML et si oui permet d’indiquer si elle peut se répéter ou non :

  • 1/1 : Balise obligatoirement présente dans le message. Elle y sera qu’une fois.

  • 1/n : Balise obligatoirement présente dans le message. Elle peut être répétée.

  • 0/1 : Balise non obligatoirement présente dans le message. Dans le cas où elle est présente, elle n’y sera qu’une fois.

  • 0/n : Balise non obligatoirement présente dans le message. Dans le cas où elle est présente, elle peut être répétée.

• Format XML

Zone non gérée actuellement, Sert à titre d’information.

• Format Diapaso.

Zone non gérée actuellement. Sert à titre d’information.

• Commentaire

Texte libre permettant de donner des informations complémentaires éventuelles.

• Définition / Variables

Application identique à celle décrite précédemment mais avec une approche différente. On raisonne par rapport aux variables de l’action à mener et on réalise le rattachement des balises sur chacune. Lors de la création d’un détail, l’accès à la GFG de définition présente une liste vide et on est directement positionné en création sur la fiche.

La description de la fiche est identique à celle décrite précédemment.

• Variable 

Référence variable de l’action interne (définie sur l’entête de correspondance) sur laquelle va être définie la correspondance avec une balise du couple modèle/version XML. L’action de sélection ne présente que les variables possibles en fonction de l’action interne.

• Balise

Le bouton lance un tree-view représentant l’arborescence du couple modèle/version XML. La sélection de la balise se fait donc depuis cette arborescence.

• Définition / Variables Obligatoires

Même principe que ‘Définition / Variables’ si ce n’est que la liste est pré-initialisée avec les variables de l’action interne (définie sur l’entête de correspondance). Toutefois la notion ‘Obligatoire’ n’est à ce jour considérée que sur les actions reposant sur une entité. En ce qui concerne les actions internes entrantes, seule l’action ACT-AP-RE repose sur une entité (APL) et cette application n’a de ce fait d’intérêt que pour cette action interne entrante (l’intérêt est plus évident sur les actions internes sortantes dont la majorité repose sur une entité). La saisie dans la fiche correspond du coup à une modification et non à une création.

• Définition / Toutes Variables

Même principe que ‘Définition / Variables’ si ce n’est que la liste est pré-initialisée avec toutes les variables de l’action interne. La saisie dans la fiche correspond du coup à une modification et non à une création.

Il est donc possible d’affecter les balises sur les variables voulues et de supprimer les variables non nécessaires au traitement de l’action.

Il est possible d’accéder à la gestion du détail de correspondance depuis la branche de l’explorateur applicatif ‘Détail Correspondances’.

Cette branche présente la liste de tous les détails de correspondances définis tous modèles/versions XML confondues. Il est ainsi possible par le jeu de ‘Filtres’ de connaître les différents cas d’emplois d’une variable par exemple ou de lister les différentes correspondances reposant sur le même modèle/version XML ....

Les actions disponibles sur cette liste sont les actions de gestion de base (Création, Modification, Suppression, Détail et Modification Globale).

Description Liste :

• Ambiguïté Ce flag indique si la correspondance présente une ambiguïté par rapport au modèle/version XML. En effet, les modèles/versions XML peuvent évoluer de façon indépendante par rapport aux correspondances déjà définies et donc provoquer des ambiguïtés. Ces dernières sont repérées lors du transfert d’un modèle/version en exploitation. Voir le chapitre concernant la définition des modèles XML qui détaille les différents cas d’ambiguïté.

• Modèle Référence modèle XML en exploitation servant de support pour la définition de la correspondance.

• Version Version du modèle XML en exploitation sus cité.

• Correspondance Référence correspondance.

• Ordre Numéro ordre de traitement du détail de correspondance (initialisation variable associée)

• Variable Référence variable concernée par le détail de correspondance courant.

• Désignation Variable Désignation de la variable sus citée.

• Balise Référence balise rattachée à la variable.

• Désignation Balise Désignation de la balise sus citée.

• Format Format de la variable.

• Valeur Alpha. Valeur défaut de la correspondance si variable de type alphanumérique

• Valeur Num. Valeur défaut de la correspondance si variable de type numérique

• Valeur Date Valeur défaut de la correspondance si variable de type date

• Valeur Log. Valeur défaut de la correspondance si variable de type logique

• Formule Référence formule utilisée pour calcul particulier sur la variable.

• Désignation Formule Désignation de la formule.

• MàJ Complémentaire Flag indiquant si un bloc Progress exécuté après traitement du détail de correspondance a été défini ou non.

Correspondances en Anomalie

Cette application présente toutes les correspondances présentant au moins une anomalie suite à une modification du modèle/version XML en exploitation sur lequel l’action ‘transfert forcé’ a été effectué. Il est alors possible de lever les ambiguïtés par le biais des actions de modification ou de suppression.

Description de la liste :

• Ambiguïté

Ce flag indique si la correspondance présente une ambiguïté par rapport au modèle/version XML. En effet, les modèles/versions XML peuvent évoluer de façon indépendante par rapport aux correspondances déjà définies et donc provoquer des ambiguïtés. Ces dernières sont repérées lors du transfert d’un modèle/version en exploitation. Voir le chapitre concernant la définition des modèles XML qui détaille les différents cas d’ambiguïté.

• Erreur

Descriptif de l’erreur à l’origine de l’ambiguïté.

• Proposition

Lors du transfert en mode forcé, l’algorithme de contrôle d’intégrité tente de trouver des liens possibles entre la nouvelle structure du modèle/version XML et les correspondances déjà définies et pour lesquelles il a trouvé une ambiguïté.

• Modèle

Référence modèle XML en exploitation servant de support pour la définition de la correspondance.

• Version

Version du modèle XML en exploitation sus cité.

• Correspondance

Référence correspondance.

• Ordre

Numéro ordre de traitement du détail de correspondance (initialisation variable associée)

• Variable

Référence variable concernée par le détail de correspondance courant.

• Désignation Variable

Désignation de la variable sus citée.

• Balise

Référence balise rattachée à la variable.

• Désignation Balise

Désignation de la balise sus citée.

• Format

Format de la variable.

• Valeur Alpha.

Valeur défaut de la correspondance si variable de type alphanumérique

• Valeur Num.

Valeur défaut de la correspondance si variable de type numérique

• Valeur Date

Valeur défaut de la correspondance si variable de type date

• Valeur Log.

Valeur défaut de la correspondance si variable de type logique

• Formule

Référence formule utilisée pour calcul particulier sur la variable.

• Désignation Formule

Désignation de la formule.

• MàJ Complémentaire

Flag indiquant si un bloc Progress exécuté après traitement du détail de correspondance a été défini ou non.

Correspondances à Générer

Une correspondance ne peut être utilisée dans DIAPASON que si elle a été générée. La phase de génération consiste en la génération d’un programme Progress traduisant toutes les affectations de variables impliquées dans la correspondance.

Cette application présente donc toutes les correspondances créées ou celles pour lesquelles au moins une modification a été apportée au niveau de son détail.

Définition des formules Entrantes

Il est possible de définir des formules de façon à pouvoir transformer toute valeur issue d’une correspondance Balise-Variable lors du traitement d’un message. Ces formules peuvent notamment servir à formater une variable date à partir de plusieurs balises, ou d’appliquer un taux de conversion à une valeur numérique ...

Ce chapitre a pour but de présenter la définition d’une formule en précisant notamment le contexte en entrée et en sortie pour les formules utilisées dans les correspondances entrantes.

Les formules entrantes sont des blocs de mise à jour complémentaire «standards» pouvant être utilisés sur les détails de correspondances, pour éviter la re-saisie de mises à jour complémentaires identiques sur différentes balises. Elles peuvent recevoir jusqu’à cinq paramètres distincts.

L’application de définition des formules est une application de type GFG accessible depuis l’explorateur applicatif des Echanges Inter-Applicatifs.

Ce paragraphe ne traite que des formules de type entant.

Onglet « Définition »

• Référence Référence de la formule. Cette zone est obligatoire.

• Type Correspondance Permet de définir si la formule est utilisable sur les correspondances entrantes ou sortantes.

• Désignation Désignation de la formule.

• Commentaire Un éditeur permet de renseigner un commentaire pour la formule.

• Figée La formule est-elle figée ou non ? Non géré.

• Type Résultat Type de résultat de la formule. Le résultat d’une formule est du type de la variable associé au détail de correspondance en cours de traitement.

• Contenu

Un éditeur permet de renseigner le contenu de la formule.

Un certain nombre de règles doivent être respectées pour cette saisie afin de pouvoir générer correctement le programme de traitement de la correspondance ou du document utilisant la formule :

Tous les mots doivent être séparés par les espaces (avant et après les parenthèses, avant et après les virgules, avant et après les points …)

Des mots clés peuvent être utilisés, ce sont :

• DIAP_VALEUR_ENTREE : Valeur initiale de la variable (DIAP_VALEUR_ENTREE est du même type que la variable saisie dans la zone « Variable » de la correspondance utilisant la formule ou de type Caractère si aucune variable n’a été saisie)

• DIAP_VALEUR_RETOUR : Valeur définitive associée à la balise (DIAP_VALEUR_RETOUR est du même type que la variable saisie dans la zone « Variable » de la correspondance utilisant la formule ou de type Caractère si aucune variable n’a été saisie).

• DIAP_ERREUR : permet de retourner une erreur et donc d’annuler la génération du message sortant. La syntaxe est la suivante : DIAP_ERREUR = libellé de l’erreur

• DIAP_WARNING : permet d’afficher un message d’alerte lors de la génération du message XML sortant. La syntaxe est la suivante : DIAP_WARNING = contenu du warning

• DIAP_SOCIETE : Société courante

Les paramètres passés à la formule (cinq au maximum) peuvent être utilisés sous la forme P_1 (1^er paramètre), P_2 (2^nd paramètre), P_3 (3^éme paramètre), P_4 (4^éme paramètre) et P_5 (5^ème paramètre). Ils sont tous au format caractère.

Les variables de l’action interne peuvent être utilisées sont la forme NomAction.NomVar (exemple : ACT-FA-DE.LanSerReeDecDat)

Les infos de la liste de la requête peuvent être utilisées sous la forme NomListe.InfoListe (exemple Resultat.LanSerfabOF). Pour une requête REN (action interne INI-REN), la liste de sortie se nomme toujours WfListe.

Les variables de l’entité peuvent être utilisées sur la forme TypVar.NomVar (exemple : SFL.AppNumCom)

Les variables de type XML peuvent être utilisées sous la forme XML.NomVar (exemple : XML.Nombre)

Les variables de type SCR peuvent être utilisées sous la forme SCR.NomVar (exemple : SCR.AppNumCom)

Les variables de type VCR peuvent être utilisées sous la forme VCR.NomVar (exemple : VCR.DebutNumCom)

L’initialisation d’une balise de niveau inférieur doit être écrite de la manière suivante :

<NomBalise> = …

Il n’est pas possible d’utiliser un nom de balise pour récupérer la valeur de cette balise, c’est-à-dire d’écrire par exemple :

DIAP_VALEUR_RETOUR = <NomBalise> …

Onglet « Paramètres »

• Nb Paramètres Nombre de paramètres utilisés par cette formule. Ce nombre doit correspondre au nombre de P_* utilisés dans le contenu de la formule.

• Paramètre 1 Cette zone permet de donner un commentaire sur le paramètre 1. Cette zone n’est saisie que si le nombre de paramètres est supérieur ou égal à 1.

• Paramètre 2 Cette zone permet de donner un commentaire sur le paramètre 2. Cette zone n’est saisie que si le nombre de paramètres est supérieur ou égal à 2.

• Paramètre 3 Cette zone permet de donner un commentaire sur le paramètre 3. Cette zone n’est saisie que si le nombre de paramètres est supérieur ou égal à 3.

• Paramètre 4 Cette zone permet de donner un commentaire sur le paramètre 4. Cette zone n’est saisie que si le nombre de paramètres est supérieur ou égal à 4.

• Paramètre 5 Cette zone permet de donner un commentaire sur le paramètre 5. Cette zone n’est saisie que si le nombre de paramètres est égal à 5.

Onglet « Qui, Quand ? »

• Util. Création Utilisateur ayant créée la formule.

• Date Création Date de création de la formule.

• Heure Création Heure de création de la formule.

• Util. Modification Utilisateur de dernière modification de la formule

• Date Modification Date de dernière modification de la formule

• Heure Modification Heure de dernière modification de la formule.

Les actions possibles sur cette application sont :

Actions standards GFG : Création, Modification, Duplication, Suppression

Principe de lecture balise « supérieure » dans un fichier XML

Si une balise ne se trouve pas dans la balise départ de correspondance et que l'option "Visibilité Balise" est cochée sur la correspondance Balise Variable, une recherche est 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.

Exemple : soit le modèle suivant, servant à gérer des commandes et des lignes :

La recherche de la balise « NoCde » va s’effectuer de la manière suivante :

1. 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 ».

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

Principe de FormatAGE D’une info XML de Type date

Le formatage d’une information de type date JJ/MM/AAAA passe obligatoirement par une variable XML de type caractère. En effet le type « date » au sens XML est un format universel.

L’exemple suivant décrit le principe :

La correspondance va reposer sur une variable de type « C » de DIAPASON

Dans la règle DIALOG chargée d’initialiser les valeurs devant être générées l’affectation se fera comme suit :

VLO.Datejour = DATEJOUR( )

INIT XML.Val = CHAINE( VALEUR= VLO.Datejour , D/JJ/MM/AAAA )

Le résultat de la fonction XML-GENCOR donne :

Exemple de Message Entrant 

La copie d’écran ci-dessus fait une synthèse du principe de traitement des messages entrants. L’exemple présenté concerne une déclaration de fabrication par le biais d’un fichier XML (Fenêtre en haut à gauche). Le fichier XML est le point de départ qui permet de définir le modèle XML décrivant la structure du fichier (Fenêtre en haut à droite). La phase suivante est de définir les différentes correspondances permettant de faire les liens entre les balises et les variables de l’action interne à mener (dans ce cas l’action interne est ACT-FA-DE, Fenêtre en bas à droite. Pour que le traitement du fichier puisse se faire par DIAPASON, il faut associer un type de message au fichier XML( Fenêtre en bas à gauche). Le lien est notamment fait par la notion de modèle/version sur le type de message. Une fois ce paramétrage effectué, il est alors possible de définir un type de réception dont le but sera de récupérer le fichier (par le biais d’une commande Unix du type ‘ls –1 [chemin]’ ou d’une requête DIALOG) et une règle d’identification devant agir dans notre exemple sur la balise de départ DECFAB.