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

Séquence

Contexte

Actions

1.1

Avant la création du programme d’import :

L’Openo qui permet d’écrire le programme temporaire d’import (de nom donné par la variable IMPTRT) n’est pas encore fait.

Il est possible de changer le nom des masques utilisés (tableau NOMMSK, le nombre de masques est donné par NBMASK)

IMP_COMPILE

1.2

Après la création du programme d’import :

Le traitement temporaire d’import (de nom donné par la variable IMPTRT) est toujours ouvert par Openo : il est donc possible d’y ajouter (par Wrseq) des instructions complémentaires.

Le traitement sera compilé après cette action, puis la procédure d’import à proprement parler commencera.

IMP_TRTSUP

2

Début de programme

OUVRE IMP_OUVRE

3

Lecture de l’enregistrement d’en-tête

Transfert dans la classe [F]

L’action AP_IMPORT est appelée après le chargement des variables décodées de chaque bloc (le niveau d’imbrication est connu par la variable SEPNUM (de 1 à 8), l’abréviation de la table principale en cours de traitement par la variable IMPABR

 

 

AP_IMPORT

4

Vérification de l’autorisation de créer ou

De modifier :

SETBOUT IMP_SETBOUT (*)

5

Test d’existence de l’OBJet :

 

5.1

Si l’OBJet n’existe pas :

SETBOUT IMP_SETBOUT
RAZCRE IMP_RAZCRE

5.2

Si l’OBJet existe :

Puis chargement de la fiche

Revérification des autorisations

VERROU IMP_VERROU

LIENS IMP_LIENS

SETBOUT IMP_SETBOUT

AVANT_MOD IMP_AVANT_MOD

6.1

Simulation de saisie des écrans associés

à la table principale

IMPORT

IMP_DEFTRT (*)

6.2

Pour chaque champ de l’écran :

Exécution des actions avant_zone

avant_saisie

init

Si la zone est saisie :

Pour savoir si la zone est dans un tableau :

(cette action affecte nolign si nécessaire)

Si OK=1, transfert depuis la classe [F]

Du champ de même nom

Exécution des actions après_zone

Et le cas échéant après_modif

 

 

 

 

 

 

IMP_ZONE

7.1

Lecture d’un enregistrement du fichier secondaire (ceci est fait pour tous les niveaux d’enregistrements secondaires)

 

IMPORT

IMP_TAB

 

AP_IMPORT

 

7.2

Simulation des écrans associés.

Dans le cas d’un tableau, la variable

nolign est utilisée.

Par défaut, une ligne est ajoutée

( nolign = 0)

 

8

Enregistrement de l’OBJet

 

8.1

Cas de la création :

Début de transaction

Ecriture

Fin transaction

 

 

En cas de Rollback :

VERIF_CRE IMP_VERIF_CRE

INICRE IMP_INICRE

CREATION IMP_CREATION

APRES_CRE IMP_APRES_CRE

 

AB_CREATION

IMP_AB_CREATION

8.2

Cas de la modification :

Début de transaction

Verrouillage de l’enregistrement

Affectation des variables [F]

Réécriture

Fin transaction

 

 

En cas de Rollback :

Déverrouillage

VERIF_MOD IMP_VERIF_MOD

AVANT_MODFIC

IMP_AVANT_MODFIC

INIMOD IMP_INIMOD

MODIF IMP_MODIF (*)

APRES_MOD IMP_APRES_MOD

 

AB_MODIF IMP_AB_MODIF

DEVERROU IMP_DEVERROU

9

Fin de programme :

FERME IMP_FERME

(*) 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é

Séquence

Contexte

Actions

1.1

Avant la création du programme d’import :

L’Openo qui permet d’écrire le programme temporaire d’import (de nom donné par la variable IMPTRT) n’est pas encore fait.

Il est possible de changer le nom des masques utilisés (tableau NOMMSK, le nombre de masques est donné par NBMASK)

IMP_COMPILE

1.2

Après la création du programme d’import :

Le traitement temporaire d’import (de nom donné par la variable IMPTRT) est toujours ouvert par Openo : il est donc possible d’y ajouter (par Wrseq) des instructions complémentaires.

Le traitement sera compilé après cette action, puis la procédure d’import à proprement parler commencera.

IMP_TRTSUP

1.3

Début de programme

OUVRE IMP_OUVRE

2

Lecture du fichier d’import et transfert dans classe [F]

L’action AP_IMPORT est appelée après le chargement des variables décodées de chaque bloc (le niveau d’imbrication est connu par la variable SEPNUM (de 1 à 8), l’abréviation de la table principale en cours de traitement par la variable IMPABR

AP_IMPORT

3

Test d’existence de l’OBJet (nbre lignes >0)

 

3.1

Si l’OBJet existe :

VERROU IMP_VERROU

3.2

Vérification de l’autorisation de créer ou

de modifier :

SETBOUTIMP_SETBOUT

3.3

Si l’OBJet n’existe pas :

SETBOUTIMP_SETBOUT

RAZCREIMP_RAZCRE

4.1

Boucle de lecture des enregistrements

Enregistrements liés à chaque ligne :

Transfert dans la classe [F]

Fin de boucle de lecture

Enregistrements liés en fin de boucle :

FILTRE

LIENS0 IMP_LIENS0

LIENS IMP_LIENS

 

LIENS2 IMP_LIENS2

5.1

Simulation de saisie des écrans associés

à la table principale

IMPORT

IMP_DEFTRT (*)

5.2

Pour chaque champ de l’écran :

Exécution des actions avant_zone

avant_saisie

init

Si la zone est saisie :

Si OK=1, transfert depuis la classe [F] du champ de même nom

Exécution des actions après_zone et le cas échéant après_modif

 

 

 

 

IMP_ZONE

6.1

Lecture d’un enregistrement du fichier secondaire

L’action AP_IMPORT est appelée après le chargement des variables décodées de chaque bloc (le niveau d’imbrication est connu par la variable SEPNUM (de 1 à 8), l’abréviation de la table principale en cours de traitement par la variable IMPABR

IMPORT

 

AP_IMPORT

6.2

Simulation des écrans associés.

Dans le cas d’un tableau, la variable nolign est utilisée.

Par défaut, une ligne est ajoutée

( nolign = 0)

 

7

Enregistrement de l’OBJet

 

7.1

Cas de la création :

 

Début de transaction

Pour chaque ligne :

Ecriture

 

A la fin de l’écriture des lignes :

Transaction terminée :

VERIF_CRE IMP_VERIF_CRE

DEBUT_CRE IMP_DEBUT_CRE

INICREIMP_INICRE

CREATIONIMP_CREATION

MODIF IMP_MODIF

APRES_CRE IMP_APRES_CRE

7.2

Cas de la modification :

  Début de transaction

Effacement des lignes

Boucle sur les lignes :

 

Création de ligne

A la fin de la boucle

Fin transaction

VERIF_MOD IMP_VERIF_MOD

DEBUT_MOD

IMP_DEBUT_MOD

FILTRE

INICRE IMP_INICRE

CREATION IMP_CREATION

MODIFIMP_MODIF

APRES_MOD IMP_APRES_MOD DEVERROUIMP_DEVERROU

8

Fin de programme :

FERME IMP_FERME

 

Objet tableau

Séquence

Contexte

Actions

1.1

Avant la création du programme d’import :

L’Openo qui permet d’écrire le programme temporaire d’import (de nom donné par la variable IMPTRT) n’est pas encore fait.

Il est possible de changer le nom des masques utilisés (tableau NOMMSK, le nombre de masques est donné par NBMASK)

IMP_COMPILE

1.2

Après la création du programme d’import :

Le traitement temporaire d’import (de nom donné par la variable IMPTRT) est toujours ouvert par Openo : il est donc possible d’y ajouter (par Wrseq) des instructions complémentaires.

Le traitement sera compilé après cette action, puis la procédure d’import à proprement parler commencera.

IMP_TRTSUP

1.3

Début de programme

OUVRE IMP_OUVRE

2

Lecture des données du fichier et chargement de la classe [F]

L’action AP_IMPORT est appelée après le chargement des variables décodées de chaque bloc (le niveau d’imbrication est connu par la variable SEPNUM (de 1 à 8), l’abréviation de la table principale en cours de traitement par la variable IMPABR

 

AP_IMPORT

3

Si l’OBJet existe :

VERROU IMP_VERROU

4

Verrouillage de la table

Début de lecture :

Boucle de lecture des enregistrements

A la fin de la lecture

FILTRE

LIENS0 IMP_LIENS0

LIENS IMP_LIENS

LIENS2 IMP_LIENS2

5

Vérification de l’autorisation de modifier :

SETBOUTIMP_SETBOUT

6.1

Simulation de saisie des écrans associés

à la table principale

IMPORT

IMP_DEFTRT (*)

6.2

Pour chaque champ de l’écran :

Exécution des actions avant_zone

avant_saisie

init

Si la zone est saisie :

Si OK=1, transfert depuis la classe [F] du champ de même nom

Exécution des actions après_zone et le cas échéant après_modif

 

 

 

 

IMP_ZONE

7.1

Lecture d’un enregistrement du fichier secondaire

IMPORT

7.2

Simulation des écrans associés.

une ligne est ajoutée au tableau (nolign est géré par la gestion OBJet)

 

8

Enregistrement de l’OBJet

 

8.1

On est toujours en création

Début de transaction

puis verrouillage table

si OK<>0 à la suite de MOD_IMPORT,

la transaction est poursuivie :

On efface tous les enregs existants

Pour chaque ligne :

Ecriture

A la fin de l’écriture des lignes :

Fin de transaction

VERIF_MOD IMP_VERIF_MOD

MOD_IMPORT

 

FILTRE

INICREIMP_INICRE

CREATIONIMP_CREATION

MODIF IMP_MODIF

9

Lorsque la transaction est réussie

APRES_MOD IMP_APRES_MOD

10

Fin de programme :

FERMEIMP_FERME

 

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 :

Etiquette

Contexte

$OUVRE

En début d’import, cette étiquette permet de déclarer les masques, tables, et variables nécessaires.

$RAZCRE

En début de lecture (on va lire un nouvel enregistrement). Permet de mettre à zéro les variables qui vont ensuite être remplies par l’import.

$SAIMSK

Lorsqu’un groupe de données a été lu. La variable IMPFIC permet de connaître l’abréviation de la table dont le contenu a été lu. La classe [F] correspondant à cette table est alors renseignée, et on peut effectuer des transferts de données vers des masques (lorsqu’on travaille avec des OBJets de type en-tête / ligne, c’est en général dans un masque que l’on stocke temporairement les données).

$VALID

On a terminé de lire les données : cette étiquette permet de faire les contrôle et de créer ou de modifier les données dans la base.

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).

Octet

0

1

2

3

4

5

6

7

8

9

16…

 

¡

¢

£

¤

¥

¦

§

¨

©

17…

ª

«

¬

 

®

¯

°

±

²

³

18…

 ´

µ

·

¸

¹

º

»

¼

½

19…

¾

¿

À

Á

Â

Ã

Ä

Å

Æ

Ç

20…

 È

É

Ê

Ë

Ì

Í

Î

Ï

Ð

Ñ

21…

Ò

Ó

Ô

Õ

Ö

×

Ø

Ù

Ú

Û

22…

Ü

Ý

Þ

ß

à

á

â

ã

ä

å

23…

æ

ç

è

é

ê

ë

ì

í

î

ï

24…

 ð

ñ

ò

ó

ô

õ 

ö

÷

ø

ù 

25…

 ú

 û

ü

ý

þ

ÿ 

 

 

 

 

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 SYS n'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îne2 sont des préfixes sur 3 caractères définissant le code du jeu que l’on veut définir. Par exemple, on pourrait utiliser ado pour la chaîne 1, et jeu pour 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 eacute le 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"

Il est important de noter :
  • 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