Modèles d'import/export : annexe technique

Le traitement d'import et les actions associées

L’import et l’export d’OBJet est réalisé par l’intermédiaire d’un traitement créé à partir de la compilation du modèle. Ce traitement temporaire a pour nom WWINNNNNN ou WWENNNNNN (NNNNNN étant un numéro incrémental).

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.

Mais on appelle en outre des étiquettes supplémentaires spécifiques à l’import, définies dans le traitement IMPXXX, s’il existe (et dans le traitement spécifique défini dans le modèle, qui permet de traiter les cas spécifiques). Les chronologies qui suivent décrivent précisément la manière dont se déroule un import dans le cas des différents types d’objet (on se reportera à la documentation sur la gestion d’OBJet pour plus de précisions). Dans le tableau qui suit, les actions de l’objet standard sont indiquées en italique, celles liées à l’import le sont en gras.

La colonne Actions indique des actions réalisées juste après l’opération indiquée dans le contexte : par exemple, dans le cas de l’objet simple, si on regarde le pavé 8.2 :

• on réalise les actions VERIF_MOD et IMP_VERIF_MOD
• on verrouille l’enregistrement, puis on réalise les actions AVANT_MODFIC et IMP_AVANT_MODFIC
• on affecte les variables de la classe [F], puis on réalise les actions INIMOD et IMP_INIMOD.
• on réécrit, puis on réalise les actions MODIF et IMP_MODIF.
• on exécute l’opération de fin de transaction (Commit), puis on réalise les actions APRES_MOD et IMP_APRES_MOD.
• on déverrouille, puis on exécute les actions DEVERROU et IMP_DEVERROU.

Il est à noter que les actions situées dans le traitement spécifique d’import sont effectuées avant celles du traitement standard d’import ; si le traitement spécifique d’import affecte la variable GPE à 1, l’action du traitement standard d’import est inhibé.

Objet simple

(*) Les actions MODIF et IMP_MODIF sont en principe utilisées pour gérer l’enregistrement des lignes (MODIF est utilisé en standard par la gestion d’OBJet, IMP_MODIF permet de gérer des actions complémentaires). L’action IMP_DEFTRT permet de réaffecter si nécessaire la variable TRTMSK, qui définit le nom du traitement automatique défini dans le dictionnaire des écrans. 

L’action IMP_SETBOUT est utilisée pour compléter les options de gestion de l'objet: on peut avoir à faire un Call VIREBOUT en import pour interdire la création par exemple et agit notamment sur la variable CHAINE qui contient toutes les options.

Objet combiné

Objet tableau

Les actions du traitement IMPxxx

Toutes les actions IMPxxx ont le même contexte que celles de SUBxxx et sont appelées après.

Les actions suivantes sont particulières.

l’action IMPORT

L’action IMPORT est appelée après chaque lecture d’enregistrement.

La variable IMPFIC contient l’abréviation du fichier importé. La classe correspondante est en ligne (pour les infos réellement importées).

Dans le cas d’un tableau, la variable nolign est initialisée à 0, elle sera exploitée en sortie pour savoir quelle ligne est saisie. Si nolign est laissé à zéro, une nouvelle ligne sera créée.

l’action IMP_TAB

L’action IMPORT est utilisée pour gérer les zones d’une table secondaire rangées dans un tableau (la page 3 de l’objet définit à cet effet les tables secondaires, les écrans, et les variables de bas de tableau correspondantes). Ceci permet de distinguer les zones non indicées devant être rangées dans un tableau des autres zones. Cette action n’est utilisée que pour les imports d’objet de type normal.

Action IMP_ZONE

L’action IMP_ZONE est appelée en lieu et place de la saisie d’une zone, elle permet de récupérer une valeur dans un écran qui aurait un nom différent dans le fichier (ex : cas des zones dimensionnées dans une table qui correspond à plusieurs colonnes d’un tableau) :

• La variable IMPFIC contient l’abréviation du fichier qui a provoqué la saisie.
• La variable IMPMSK contient le nom de l’écran en cours de saisie.
• La variable IMPZON contient le nom de la zone en cours de saisie.
• La variable IMPMOD, prépositionnée à 0 permet de déclencher l’action d’après_modif.
• La variable OK, initialisée à 1, permet ou non de déclencher l’action standard.

Action MOD_IMPORT

L’action MOD_IMPORT ne sert qu’en import d’un objet tableau (pour interdire éventuellement cet import).

Le traitement d'import spécifique

Ce traitement d’import court-circuite (en général pour des raisons de performance) la gestion standard d’OBJet et n’inclut qu’un nombre restreint d’étiquettes appelées par Gosub depuis la fonction d’import. Ces étiquettes sont définies ci-dessous :

Il n’est conseillé de réaliser ce mode d’import que si des problèmes particulier de performance se posent. En effet, même s’il est plus lourd, l’import " standard " d’objet permet d’obtenir un contrôle automatique en incluant tout ce qui est décrit dans la logique d’objet, alors que le programme d’import spécifique nécessite de tout recoder à la main, en appelant éventuellement des composants existants.

Fichiers de transcodage

Principe du transcodage

Dans le modèle d’import ou d’un export, ADONIX X3 reçoit un flux de données dans un jeu de caractères qui n’est pas forcément le jeu de caractères interne (correspondant au jeu de caractères WE8ISO8951P1 sous oracle). Il faut être en mesure de le transcoder. Attention, on ne parlera dans cette documentation que de transcodage de caractères stockés sur un octet, correspondant en général à des caractères accentués ou particuliers à certaines langues occidentales. Ces caractères sont normalement codés sur un octet avec des valeurs comprises entre 160 et 250. Ci dessous, on trouvera les correspondances entre ces caractères et les codes ascii du jeu standard utilisé par ADONIX X3 (affichés avec une police de type Arial).

Ceci se fait par l’intermédiaire du champ Jeux de caractères dans le pavé de transcodage. Le champ en question prend des valeurs définies par le menu local 9. Ce menu local n’est pas paramétrable par défaut, mais il est possible d’y ajouter des valeurs en développement, pour gérer de nouveaux jeux de caractères externes.

A chaque valeur de ce menu local correspond un fichier externe, installé sur le serveur, qui définit les transcodages à réaliser. Ce fichier se trouve dans le répertoire SYS du dossier X3, et a pour nom TRANS#.cnv, où # correspond au numéro du menu local (1, 2, 3…). Le fichier TRANS#.cnv doit être encodé avec un format UNIX et un jeu de caractères UTF8. Si cela n'est pas fait, le transcodage ne fonctionnera pas lors de l'import/export.

Le répertoire SYSn'existe pas par défaut. Il faut le créer au niveau du dossier du point de connexion.

Exemple de chemin d'accès au répertoire SYS : SAGE\SAGEX3V6\X3V6SQL\Folders\DEMO\SYS

Le fichier TRANS0.cnv contient des commentaires expliquant (en anglais) la manière de faire :

• On définit d’abord deux lignes sur lesquelles on indique :
• adonix="chaîne1"
• output="chaîne2"

chaîne1 et chaîne2sont des préfixes sur 3 caractères définissant le code du jeu que l’on veut définir. Par exemple, on pourrait utiliser adopour la chaîne 1, et jeupour le deuxième jeu de caractères.

• On définit d’abord ensuite des lignes pour définir chaque caractère en lui attribuant un mnémonique identique (qui sera préfixé par chaîne1 ou chaîne2), suivi d’un signe d’égalité et du code du caractère. Par exemple, si on désigne par eacutele e accent aigü, imaginons que ce caractère soit transcodé dans le jeu de caractère d’arrivée jeu avec le code décimal 238 (il est codé 233 dans le jeu ado). On écrirait alors les deux lignes suivantes :
• adoeacute="238"
• jeueacute="233"

• que les doubles quotes ne sont pas obligatoires (on aurait pu écrire adoeacute=238).
• que les codes peuvent aussi être donnés en format octal sous la forme \nnn, et en format hexadécimal sous la forme Hxx.
• que l’ordre dans lequel les lignes sont présentées importe peu (on peut d’abord définir la totalité des caractères d’un jeu, puis celles du jeu suivant, ou apparier les caractères deux à deux, ou prendre n’importe quel autre ordre).
• que des caractères non décrits (ou décrits dans un jeu sans l’être dans l’autre) ne seront pas transcodés.
• que des lignes de commentaires peuvent librement être insérées ou ajoutées en fin de ligne, pourvu qu’elles soient précédées du caractère #.

Exemple de fichier : TRANS0.cnv

On trouvera ci-dessous le contenu du fichier TRANS0.cnv, qui explique en anglais comment s’y prendre :

#
########################################################################
#
# trans0.cnv
#
# Transcodification file used for ADONIX X3 import/export
#
# Each line (except the comments prefixed by # ) must have the following format
#
# adoxxxxx = value1 or extxxxxx = value2
#
# (ado for adonix internal code, ext for "external" file code
#
# xxxxx is an identifier used to associate external & internal code together
#

# values can be defined in following formats :
#
# nnn or "nnn"         value in decimal
# \nnn or "\nnn"       value in octal
# Hnnn or "Hnnn"       value in hexadecimal
#
# Author : Bertrand YVINEC   
# Translated by Dominique BOPP
#
# Copyright (c) ADONIX 1992-2001
#
########################################################################
#
# Identifier definition (default is ado and ext)
#
adonix = "iso"
output = "ibm"

Exemple de fichier : TRANS2.cnv

Ce fichier permet de transcoder dans le jeu IBM PC. Le fichier a ici été expurgé de la plupart des lignes de commentaires.

#
########################################################################
# trans2.cnv
# Copyright (c) ADONIX 1992-2001
########################################################################
adonix = "iso"
output = "ibm"
#
# ISO code first
isoagr="\340"    # a grave
isoeai="\351"    # e acute
isoegr="\350"    # e grave
isocce="\347"    # c cedilla
isougr="\371"    # u grave
isodeg="\260"    # degree
isoali="\247"    # alinea
isoaci="\342"    # a circumflex
isoeci="\352"    # e circumflex
isoici="\356"    # i circumflex
isooci="\364"    # o circumflex
isouci="\373"    # u circumflex
isoatr="\344"    # a dieresis
isoetr="\353"    # e dieresis
isoitr="\357"    # i dieresis
isootr="\366"    # o dieresis
isoutr="\374"    # u dieresis
isopou="\243"    # pound
#
# Ensuite en code PC
ibmagr="\205"    # a grave
ibmeai="\202"    # e acute
ibmegr="\212"    # e grave
ibmcce="\207"    # c cedilla
ibmugr="\227"    # u grave
ibmdeg="\370"    # degree
ibmali="\365"    # alinea (CP 850)
ibmaci="\203"    # a circumflex
ibmeci="\210"    # e circumflex
ibmici="\214"    # i circumflex
ibmoci="\223"    # o circumflex
ibmuci="\226"    # u circumflex
ibmatr="\204"    # a dieresis
ibmetr="\211"    # e dieresis
ibmitr="\213"    # i dieresis
ibmotr="\224"    # o dieresis
ibmutr="\201"    # u dieresis
ibmpou="\234"    # pound

Import silencieux

Principe de l'appel

Si l'on désire déclencher directement un import dans un traitement, il est possible de procéder en insérant les lignes suivantes :

If !GSERVEUR
    Call OUVRE_TRACE(TIT) From LECFIC
Endif
Call IMPORTSIL([L]COD_MODELE,[L]NOM_FICHIER)from GIMPOBJ
If !GSERVEUR
    Call FERME_TRACE From LECFIC
Endif

 Avec

• [L]COD_MODELE=Variable contenant le code du modèle d’import
• [L]NOM_FICHIER=Variable contenant le nom complet du fichier à importer

Variables concernées

Les variables passées en argument sont les suivantes : 

• [L]COD_MODELE=Variable contenant le code du modèle d’import
• [L]NOM_FICHIER=Variable contenant le nom complet du fichier à importer

Le statut de fin de l'import est récupérable dans le champ [M:IMP2]STAT
On peut avoir le texte en clair du message lié à l'erreur en appelant le sous-programme suivant :

Call ERR_IMPORT([M:IMP2]STAT,MESSAGE) From GIMPOBJ