Fonctionnement ( Import / Export )

Description

L’import et l’export  sont réalisés par l’intermédiaire d’un traitement généré à partir de la compilation du modèle. Ce traitement temporaire a pour nom WWINNNNNN ou WWENNNNNN (NNNNNN étant un numéro incrémental). Le traitement n'est pas supprimé si avant le lancement de l'import, on positionne la variable GTEST=1.

Dans le cas de l’export, le traitement ne fait qu’extraire des données (en les filtrant selon les habilitations des utilisateurs). Dans le cas de l’import, le traitement contient les instructions de décodage du flux de données, et appelle les différentes fonctions liées à l’OBJet à importer, en émulant en quelque sorte la saisie. Ainsi, les étiquettes standard du traitement SUBXXX et SPEXXX, qui permettent de gérer les OBJets, sont appelées normalement.

On appelle, en outre, des étiquettes supplémentaires particulières à l’import, à écrire dans le traitement standard IMPXXX, ou dans le traitement spécifique associé dans le modèle d'import.

Pour l'import, le superviseur traite en automatique la création et la mise à jour de la table principale; des tables supplémentaires peuvent être mises à jour, si cela a été programmé dans les actions de l'OBJet, par exemple.

Pour l'export, les textes stockés dans X3, sous forme de clob doivent être en texte brut. Si on tente d'exporter un texte riche, on exporterais avec le texte avec tous ses attributs.

Les traitements d'import et d'export peuvent utiliser les variables GIMP(n). 

La documentation sur les modèles d'import/export apporte un complément d'information.  

Cinématique de l'import

1- Avant la simulation de la saisie

   Chargement de la classe [F] intermédiaire par l'enregistrement à importer

   Si l'enregistrement existe dans la base, le superviseur le charge dans la classe [M].

2- Durant la simulation de la saisie ( les champs sont traités un par un ). 

   Les actions sur champs d'exécution "toujours" ou "import/batch" sont exécutées. On exécute pas par exemple, celle du menu contextuel ( Clic, Bouton, Sélection ).

   Pour les champs saisissables, la classe [M] du champ est chargée par la classe [F]intermédiaire avant les actions contrôle, après_zone et après_modif.

3-La transaction de mise à jour

   Chargement de la classe [F] définitive par l'ensemble de la classe [M].

   Création ou mise à jour de la table principale de l'OBJet

   Les tables supplémentaires sont traitées par l'action de l'OBJet suivante : MODIFICATION

Caractéristiques de la simulation de saisie

Les actions sur champs d'exécution "toujours" ou "import/batch" sont exécutées.

Les champs obligatoires doivent être alimentées.

Il n'y a pas de trans-classe automatique pour les champs affichés ou invisibles.

Les champs sont traités dans l'ordre de leur définition dans l'écran.

Une action supplémentaire est disponible en import sur les champs saisissable : IMP_ZONE sur les champs de bloc liste, IMP_TAB sur les champs de bloc tableau prévu pour une table détaille.

Modèle import sans OBJet

Dans ce cas, le superviseur n'utilise pas la classe [M] des masques associés à l'OBJet. Il n'y a donc pas de simulation de saisie avec l'ensemble des contrôles et actions sur champs. C'est un transfert direct dans la table de la base de données. Le superviseur traite en automatique la création et la modification d'enregistrement, pour la table principale.

Import Spécial

Le modèle d'import spécial est réduit donc plus ouvert, mais comporte moins d'automatismes. Il ne gère pas le chargement des masques, la simulation de saisie, et la transaction de mise à jour. Les traitements sont à écrire dans des étiquettes particulières puis si besoin, dans l'étiquette $ACTION du traitement associé à l'import. On peut se créer des imports spéciaux sur des modèles avec OBJet simple, tableau ou combiné. Ils ne sont pas autorisé sur des modèles sans OBJet. L'import spécial est soit spécifique, soit standard. Cependant, sur un import standard, on a quand même, l'unique possibilité d'ajout de spécifique par l'action IMPORT; Pour des raisons techniques, cette action est alors à développer, dans le traitement spécifique de l'OBJet.

Les Actions

Le traitement standard ou spécifique comment donc par cette étiquette $ACTION à écrire de la façon suivante ( ou XXXXXX est le code de l'évènement ) : 

$ ACTION
Case ACTION
   When "XXXXXX" : Gosub XXXXXX
   When default
Endcase
Return

Chaque événement est identifié par un code alphanumérique, contenu dans la variable ACTION. S’il n’y a pas de traitement pour un événement, le fonctionnement de la fonction n'en sera pas entravé. C'est dans le sous-programme $ACTION, que l'on fait l'aiguillage vers l'étiquette ajoutée. On précisera dans cette syntaxe "case ACTION", autant de lignes qu'il y a d'évènements à compléter. Le $ACTION est appelé du traitement superviseur par GOSUB ; Cela permet donc d'utiliser des variables locales au traitement superviseur. 

On trouvera ci-joint la liste des actions. On trouvera ensuite,  la description détaillée de ces actions. On y décrit le contexte appelant et l'OBJectif de ces actions.

Ajout d'actions spécifiques sur le standard

Par défaut, pour un même évènement, l'action spécifique est appelée avant l'action standard. 

Elle peut annuler et remplacer l'action standard si elle positionne la variable GPE à la valeur 1. 

Pour exécuter l'action standard avant l'action spécifique, dans ce cas, on duplique le traitement standard dans l'action spécifique, on y ajout le traitement spécifique puis on positionne la variable GPE à la valeur 1. Exemple :

Traitement superviseur
GPE=0
Gosub  ACTION  From  trait_std              ( appel du standard )
If GPE=0
   Gosub  ACTION  From  trait_spé.            ( appel du spécifique )
Endif

Traitement spécifique
$ ACTION
Case ACTION
   When "OUVRE" : Gosub OUVRE
   When default
Endcase
Return

$OUVRE
...                                                                ( action spécifique OUVRE )
GPE = 1                                                     ( pas d’appel du standard suite au spécifique )
Return

---