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 lesvariables GIMP(n).
La documentation sur les modèles d'import/export apporte un complément d'information.
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
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.
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.
Le modèle d'import spécial est réduit donc plus ouvert, mais comporte moinsd'automatismes. Il ne gère pas le chargement des masques, la simulation desaisie, 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.
Le traitement standard ou spécifique comment donc par cette étiquette$ACTION à écrire de la façon suivante ( ou XXXXXX est le code del'é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.Sil ny a pas de traitement pour un événement, le fonctionnement dela fonctionn'en sera pas entravé. C'est dans le sous-programme $ACTION, que l'on faitl'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 ; Celapermetdonc d'utiliser des variables locales au traitement superviseur.
On trouvera ci-joint la liste des actions. Ontrouvera ensuite, la description détaillée de ces actions. On y décritle contexte appelant et l'OBJectif de ces actions.
Par défaut, pour un même évènement, l'action spécifique est appelée avant l'action standard.
Elle peut annuler etremplacer l'action standard si elle positionne la variable GPE à lavaleur 1.
Pour exécuter l'action standard avant l'action spécifique, dans ce cas, onduplique le traitement standard dans l'action spécifique, on y ajout letraitement spécifique puis on positionne la variable GPE à lavaleur 1. Exemple :
Traitement superviseur
GPE=0
Gosub ACTION From trait_std ( appel dustandard)
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 dappel du standard suite au spécifique )
Return