Modèles import/export

Cette fonction définit les formats de fichiers utilisés par les fonctions d'import et d'export pour intégrer ou d'extraire des données de la base du progiciel.

Un fichier utilisable par le module import et généré par le module export est à la base un fichier avec une structure de l'un des types suivants :

  • fichier plat avec champs en longueur fixe,
  • fichier plat avec séparateur entre les champs (et enregistrements),
  • fichier XML.

Le module d'import/export utilise la notion d'objet pour permettre la mise à jour de données dans la base. Un objet est un ensemble de tables et d'écrans, qui inclut également les actions standard associées aux champs et à la mise à jour. De plus, on garantit ainsi que l'ensemble des contrôles et des actions nécessaires lors de la mise à jour de la base sont effectués, puisque une seule description de l'objet permet à la fois de générer le code relatif à une mise à jour en conversationnel et la mise à jour par import.

Lorsqu'un objet ne met à jour qu'une seule table, le modèle d'import décrit la liste des champs de la table à intégrer, sachant qu'un bloc de données du fichier à importer ou exporter contient les données d'un enregistrement. Lorsque plusieurs tables sont mises à jour par un objet (par exemple, l'en-tête et les lignes), on retrouvera plusieurs blocs de données pour une instance de l'objet à intégrer (par exemple, un bloc définissant l'en-tête et N blocs, un pour chaque ligne).

Il est également possible d'importer une table sans l'associer à une notion d'objet. Pour cela, le champ objet doit rester vide et vous devez uniquement indiquer la table et les champs concernés dans le tableau de la seconde section. L'import se fait alors sans aucun autre contrôle que ceux induits par les formats associés aux types de données des champs de la table.

Prérequis

SEEREFERTTO Reportez-vous à la documentation de mise en oeuvre.

Gestion de l'écran

En-tête

Un modèle d'import/export s'identifie par un code alphanumérique. En plus de l'intitulé, vous pouvez définir, sur deux sections, les caractéristiques techniques du modèle.

Onglet En-tête

Cette section définit les caractéristiques générales du modèle :

  • les données à exporter,
  • la structure générale du fichier (format, codage, définition de groupes de données),
  • des paramètres complémentaires.

Onglet Champs

Les différents champs à importer sont définis dans ce tableau. Ils sont organisés en groupes identifiés par la colonne Code dans laquelle on retrouve l'un des codes définis dans le tableau des indicateurs de la première section. Le champ peut rester vide si aucune table n'a été définie.

Cette section contient le tableau définissant la structure détaillée des groupes existants dans la première section. Remarques :

  • Il n'est pas obligatoire de définir des champs dans tous les groupes. Certains groupes sont purement techniques et servent à définir des liens. Par exemple, si les champs de l'en-tête de Commande et le Client payeur doivent être exportés dans un même groupe de données, vous devrez définir deux groupes : le premier pour les commandes et le second pour le client, avec le lien adéquat. En revanche, la section des champs ne doit contenir que les lignes associées au second groupe. Ces lignes peuvent inclure à la fois des informations extraites du client et de l'en-tête de la commande.
  • Il est obligatoire de définir pour chaque groupe la position où se trouve le séparateur de groupe lorsque qu'il s'agit d'un modèle utilisable en import et qu'il y a plusieurs groupes.
  • Les blocs doivent être rangés de façon séquentielle. Lorsqu'un bloc de niveau inférieur existe, il doit suivre le bloc auquel il est lié.

États

Par défaut, les états suivants sont associés à la fonction :

  • PRTSCR : Impression écran

Mais ceci peut être modifié par paramétrage.

Actions spécifiques

Barre de menus

Options / Export schéma d'un modèle

Cette fonction, accessible lorsque le format d'export est XML, permet de produire un fichier XSD décrivant la structure du fichier créé par le modèle. Ce fichier est créé dans le sous-répertoire suivant du répertoire où se trouvent les dossiers sur le serveur d'application :

  • X3_PUB/FOLDER/GEN/ALL/WEBS (FOLDER est le nom du dossier courant)
  • Le nom de ce fichier est WWIMPTEMPLATE.xsd (TEMPLATE est le nom du modèle d'import/export)

Ce fichier XSD définit le format des données afin de permettre un contrôle préliminaire de validité syntaxique par des outils de type ETL. La syntaxe obtenue intègre (outre des en-têtes standard) des lignes du type :

  • Lignes décrivant les groupes et les lignes. Ici, un modèle ADI et des champs CODE et NUMTAB, dont les balises sont ADI_CODE et ADI_NUMTAB) :

<xs:complexType name="ADI">

<xs:sequence>

<xs:element name="ADI_NUMTAB" type="ADI_NUMTAB" minOccurs="1" maxOccurs="1"/>

<xs:element name="ADI_CODE" type="ADI_CODE" minOccurs="0" maxOccurs="1"/>

...

</xs:sequence>

</xs:complexType>

  • Lignes décrivant les types de données :

<xs:simpleType name="ADI_NUMTAB">

<xs:restriction base="xs:int">

<xs:minExclusive value="-32768"/>

<xs:maxExclusive value="32767"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="ADI_CODE">

<xs:restriction base="xs:string"/>

<xs:maxLength value="5"/>

<xs:pattern value="{[A-Z]}*"/>

</xs:restriction>

</xs:simpleType>

On voit ici des exemples de champs de type numérique, puis alphabétique. Quelques commentaires à propos de la façon dont est générée cette syntaxe :

  • Le nom de chaque champ (ici, ADI_CODE et ADI_NUMTAB) correspond au contenu de la colonne Balise du modèle.
  • La rubrique pattern est issue de la colonne Pattern dans le modèle (ici, la syntaxe proposée correspond à un nombre quelconque de caractères alphabétiques majuscules)
  • Les rubriques minOccurs et maxOccurs sont renseignées en tenant compte de la colonne obligatoire du modèle
  • Les types de données, qui peuvent être, selon les cas, xs:string, xs:int, xs:decimal, xs:date, xs:base64Binary, xs:boolean, sont issues du type de données X3 correspondants, ainsi que la rubrique maxLength, et les rubriques maxExclusive, minExclusive, maxInclusive, minInclusive selon les cas.

Documentation / Paragraphes

Cette fonction permet d'accéder à la gestion de la documentation, sur le premier paragraphe de la documentation (si elle existe) associé à la fiche courante.

Documentation / Liens

Cette fonction permet d'accéder à la gestion des liens. Elle permet de définir des liens entre la fiche courante et d'autres fiches (par exemple des liens entre fonctions et paramètres). Ces liens, purement documentaires, permettent d'alimenter la mécanique de génération des squelettes de documentation.

Documentation / Génération

Ce menu permet de lancer une génération de documentation. La génération peut se lancer également à partir du bouton [Génération] dans le bas de la fenêtre.

Trois types de génération peuvent être lancées, séparément ou simultanément :

  • la génération du squelette de documentation à partir du dictionnaire (tables ADOCUMENT, ADOCBLB, ADOCCLB).
  • la génération de la documentation à partir des tables précédentes.
  • la génération de la documentation sur champ.

Les bornes proposées par défaut tiennent compte de la fiche en cours, mais elles peuvent être modifiées au lancement.

Messages d'erreur

Outre les messages génériques, les messages d'erreur suivants peuvent apparaître lors de la saisie :

Import impossible sur cet objet

L'objet n'a pas été défini comme importable. La case à cocher Import n'est pas sélectionnée dans la section Divers.

Code déjà existant en ligne nnn

On saisit deux fois le même code associé à des groupes différents.

ZZZ zone inexistante (XXXXXX, YYYYY, ... )

Ce message est affiché lorsqu'on exprime un lien dans le tableau des groupes en utilisant un champ ZZZ qui n'est référencé dans aucune des tables (XXXXX, YYYYY, ...) définies dans les lignes précédentes.

G séparateur (/) non référencé dans les champs. Interdit sur un modèle d'import

Dans le tableau des champs, pour le groupe G, aucune ligne n'indique l'endroit où se trouve l'identificateur de groupe (syntaxe /).

Lien impossible. Interdit sur un modèle d'import

On a tenté, dans le lignes décrivant les champs, d'insérer un champ issu d'une table qui ne peut pas être liée à la table principale du groupe.

Longueur incorrecte nnn<>mmm

La longueur définie par le format numérique (mmm) est différente de la longueur du champ définie dans la colonne précédente (nnn).

Aucun test d'existence de répertoire n'est fait sur le chemin défini par défaut dans le modèle. Il est possible que le répertoire n'existe pas encore. Ce contrôle ne sera fait qu'au lancement de l'import ou de l'export.

Tables mises en œuvre

SEEREFERTTO Reportez-vous à la documentation de mise en oeuvre.

Conseils de mise en oeuvre

Principes de base

Les principes suivants doivent être pris en compte lorsque vous paramétrez un modèle d'import :

  • L'import permet des actions de création et de modification.
  • Pour déterminer l'action à mener sur un enregistrement importé, le système effectue un test d'existence de l'objet à traiter. Ce test s'effectue en chargeant la clé primaire de l'objet avec les informations de l'enregistrement importé.
  • Par conséquent, si la clé principale n'est pas définie, tous les enregistrements seront passés en mode création. Les enregistrements fonctionnent uniquement si la clé de l'objet à créer peut être affectée automatiquement. Par exemple, en utilisant un compteur (numéros de séquence).
  • Un import correspond à une simulation de saisie de tous les écrans liés à l'objet importé.
  • Il traite tous les champs de l'écran en effectuant les mêmes contrôles qu'une saisie interactive.
  • Il ne prend pas en compte les champs non saisissables de l'écran (sauf cas particuliers et référencés). Par conséquent, les champs paramétrés dans un modèle correspondant à un champ non saisissable ne sont pas importés.
  • L'ordre dans lequel sont paramétrés les champs à l'intérieur d'un enregistrement n'a pas d'importance. L'import charge d'abord tous les champs du fichier, puis les importe dans l'ordre des champs dans les écrans.

Modèles standard fournis

Si l'export de données est toujours possible quel que soit l'objet, ce n'est pas le cas de l'import. Les mécanismes automatiques de décodage des flux de données et l'appel des contrôles liés à l'objet automatisent grandement l'import. Cependant, cela ne suffit pas pour permettre un import automatique sur les objets complexes. Ainsi, tout objet n'est pas importable.

Dans le dossier de référence, un modèle d'import modifiable est fourni pour chaque objet dont l'import est possible. Il est toutefois possible de lier l'import à des fonctionnalités spécifiques. Cela est décrit dans l'aide en ligne associée aux modèles d'import, ainsi que les cas particuliers. Pour consulter cette aidée, utilisez la combinaison de touches Alt + F1 sur votre clavier lorsque le modèle est chargé.

Cliquez sur le lien suivant pour consulter la liste des aides correspondantes (classées par module).

Tableau des identificateurs

Le choix de la structure des fichiers à importer ou exporter dépend des possibilités d'extraction ou d'intégration que l'on trouve dans le progiciel avec lequel on veut dialoguer.

Dans tous les cas, vous devez organiser les données en groupes logiques de lignes, qui peuvent être de types différents (en-tête, détail, sous-détail, par exemple), ou d'un type unique. Vous pouvez définir l'organisation de ces groupes dans le tableau des identificateurs, situé sur la première section du modèle.

Chaque groupe est associé à une des tables de la base données. La première étant la table principale de l'objet. Les autres tables sont définies par des liens renvoyant aux tables précédentes. Si vous utilisez le modèle pour réaliser un export d'objet, vous pouvez définir des liens avec n'importe quelle table de la base sur laquelle un lien théorique existe pour extraire des données liées. Dans le cas d'un modèle d'import, vous pouvez uniquement utilisez les tables mises à jour par l'objet. Il n'est pas possible d'importer simultanément la commande et le client, par exemple. L'objet "commande" n'a pas été conçu dans cette logique.

Ce tableau peut rester vide si la structure des données à importer ou exporter s'appuie sur l'utilisation de la table principale uniquement. Dans ce cas, la colonne Code reste vide sur la page suivante. Vous n'avez pas besoin de créer plusieurs groupes de données si plusieurs tables liées doivent être exportées simultanément. Si les champs extraits des tables s'affichent dans un même groupe de données, le traitement d'export va tenter de résoudre les liens entre tables en utilisant la structure des liens décrite dans le dictionnaire. Cela signifie qu'un seul lien est possible de la table principale du groupe vers la table décrite. Sinon, le premier lien trouvé est utilisé, même s'il est incorrect.

Il existe un cas particulier : si le modèle est défini avec une longueur fixe, alors il est nécessaire de créer au moins un groupe. Dans ce cas, vous devez définir la longueur de l'enregistrement au niveau de la table des groupes. Si l'indicateur de groupe n'est pas obligatoire dans la liste des champs, il suffit de définir ce groupe avec un code vide : seul un groupe pourra alors être défini, et la colonne Code ne sera plus saisie dans la section suivante.

Le tableau des identificateurs n'est accessible en saisie que si l'objet est de type simple. Si des identificateurs de groupe sont définis, chacun doit être associé à un niveau, une table, et des conditions de liens qui permettent relier les lignes entre elles.

La table principale est définie au niveau 1 pour l'import et l'export. Cette table n'est pas saisie dans le tableau, mais déduite en fonction de l'objet associé au modèle.

Pour toute table liée à une table précédente, le niveau est égal au niveau de la table précédente si un lien biunivoque existe entre les deux tables, et vaut ce niveau plus un si plusieurs enregistrements sont liés à un enregistrement de la table précédente. Le lien est caractérisé par la clé de la table destination à lire, et par l'expression des segments de clés dont la valeur définit les lignes liées.

Si vous définissez des groupes comme dans l'exemple suivant :

Niveau

Groupe

1

A

2

B

2

C

3

D

Vous obtiendrez les informations suivantes, qui se chevauchent :

Groupe A enregistrement 1

Groupe B enregistrement 1.1

Groupe B enregistrement 1.2

...

Groupe B enregistrement 1.N

Groupe C enregistrement 1.1

Groupe D enregistrement 1.1.1

Groupe D enregistrement 1.1.2

...

Groupe D enregistrement 1.1.M

Groupe C enregistrement 1.2

Groupe D enregistrement 1.2.1

...

Groupe C enregistrement 1.Q

Groupe D enregistrement 1.Q.1

...

Groupe D enregistrement 1.Q.R

Groupe A enregistrement 2

Groupe B enregistrement 2.1

...

Exemple de groupes

Pour illustrer ce paramétrage, on peut prendre l'exemple d'un modèle d'export uniquement mettant en jeu les sociétés et sites :

  • La table principale COMPANY est au niveau 1.
  • On souhaite intégrer des informations liées à la devise comptable (champ ACCCUR) dans le fichier exporté. Il n'est pas nécessaire de définir un nouveau groupe lié à la table "société" dans ce cas. Vous devez simplement définir les champs de la table TABCUR dans le groupe. Le moteur d'export va alors parcourir le dictionnaire pour chercher un lien entre la table COMPANY et la table TABCUR. Comme il y en a plusieurs, c'est le premier qui va être utilisé. Dans ce cas, c'est le lien qui nous intéresse.
  • Si on avait voulu exporter des informations liées à la devise du capital social (champ RGCCUR), il aurait fallu créer un deuxième groupe de données. Ce deuxième groupe aura dû être de niveau 1 également, basé sur la table TABCUR. Ce groupe afficherait alors RGCCUR dans la colonne des liens. C'est également ce que l'on serait amené à faire si le lien n'était pas explicite. Par exemple, le champ CREUSR, qui correspond au code de l'utilisateur ayant créé la fiche, utilise un type générique (A) qui ne permet pas de faire le lien de façon automatique. Si donc on avait voulu faire figurer des informations relatives à l'utilisateur ayant créé la fiche, il aurait fallu définir le lien par un groupe.
  • Supposons qu'ensuite on veuille faire apparaître la liste des sites rattachés à la société. On va alors créer un groupe de niveau 2, utilisant la table FACILITY, avec un lien basé sur l'index FCY prenant comme valeur le champ CPY de la table principale.
  • Finalement, si les valeurs du paramétrage liées à chaque société doivent être extraites, un deuxième groupe de niveau 2 serait créé à partir de la table ADOVAL. Ce deuxième groupe aurait un lien s'appuyant sur l'index ADW0, reprenant la valeur du champ CPY de la table principale.

Le tableau ci-dessous résume les identificateurs tels qu'ils seraient saisis :

Niveau

Code

Table

Clé

Lien

Commentaires

1

CPY

COMPANY

CPY0

Enregistrement principal du groupe

1

CUR

TABCUR

TCU0

[CPY]RGCCUR

1 enregistrement lié

2

FCY

FACILITY

FCY1

[CPY]CPY

N enregistrements liés

2

ADP

ADOVAL

ADW0

[CPY]CPY

M enregistrements liés

Formats de fichier

Les formats de fichier dépendent du type. Il peut s'agir des valeurs suivantes :

Séparateurs de champs (format ASCII 1)

Il s'agit d'un fichier en longueur variable, dont tous les champs sont séparés par un séparateur (le séparateur de champ noté SC).

Champ 1 enreg 1

SC

Champ 2 enreg 1

SC

...

Champ N enreg. 1

SC

Champ 1 enreg 2

SC

Champ 2 enreg 2

SC

...

Champ N enreg. 2

SC

Séparateur d'enregistrement (format ASCII 2)

Il s'agit d'un fichier en longueur variable, dont tous les champs sont séparés par un séparateur (le séparateur de champ). Lorsqu'un enregistrement est terminé, un autre séparateur (le séparateur de ligne noté SL) vient remplacer le séparateur de champ.

Champ 1 enreg 1

SC

Champ 2 enreg 1

SC

...

Champ N enreg. 1

SL

Champ 1 enreg 2

SC

Champ 2 enreg 2

SC

...

Champ N enreg. 2

SL

Format délimité

Il s'agit d'un fichier en longueur variable de même type que le fichier "séparateur d'enregistrement" (deux séparateurs distincts). Mais en plus, les champs de type chaîne de caractères sont encadrés par un délimiteur de champ (noté DC). Dans l'exemple ci-dessous, le deuxième champ est de type alphanumérique.

Champ 1 enreg 1

SC

DC

Champ 2 enreg 1

DC

SC

...

Champ N enreg. 1

SL

Champ 1 enreg 2

SC

DC

Champ 2 enreg 2

DC

SC

...

Champ N enreg. 2

SL

Format en longueur fixe

Il s'agit d'un fichier dont les champs sont définis en longueur fixe, sans séparateur de champ. Vous devez indiquer la longueur totale de l'enregistrement dans le paramétrage. Il peut y avoir un séparateur de ligne. Dans ce cas, il n'est pas nécessaire d'inclure sa longueur dans la longueur de l'enregistrement.

De même, vous pouvez définir la longueur de chaque groupe lorsque des blocs de données sont définis dans la table des indicateurs.

Chp 1 enreg 1

< ---------Champ 2 enreg. 1------------ >

...

< --Champ N enreg. 1-- >

SL

Chp 1 enreg 2

< ---------Champ 2 enreg. 2------------ >

...

< --Champ N enreg. 2-- >

SL

Format XML

Il s'agit d'un format où les données sont définies dans des balises au format XML.

A l'export, on retrouve un ensemble d'informations important liées à la fois au modèle et à l'extraction. Vous pouvez également utiliser le menu Options / Export schéma d'un modèle pour exporter un fichier XSD décrivant la structure du fichier créé par le modèle.

A l'import, les données ont moins d'importance. Il est possible de limiter ces données dans le fichier à importer.

Format A plat

Ce format est le format variable Séparateur d'enregistrement ou le format délimité (si le champ Délimiteur de champ est renseigné).

Si dans le modèle d'import/export plusieurs niveaux sont définis, une seule ligne est générée.

Indicateur niveau 1

Champ 1 enreg 1

SC

DC

Champ 2 enreg 1

DC

SC

...

Indicateur niveau 2

Champ 1 enreg 2

SC

DC

Champ 2 enreg 2

SL

Lors de l'import, l'utilisation de ce type de format a pour conséquence un regroupement de toutes les lignes de détail d'un niveau donné sous le même en-tête dès lors que tous les champs répétés dans l'en-tête sont strictement identiques.

Format d'en-tête

Ce format est le même format que le format A plat plus une ligne en-tête supplémentaire correspondant aux intitulés des champs du modèle.

Par exemple en Allemagne, ce format est utilisé pour les fichier GDPDU.

Annexes techniques

Vous trouverez des informations complémentaires dans les annexes techniques suivantes :