Lors de la configuration d'un import automatisé (vers votre liste de contacts ou une table relationnelle), vous devez fournir le chemin d'accès d'un fichier Excel ou CSV qui contient les données à importer. Les colonnes du fichier indiquent de façon dynamique la destination des données dans votre projet DI.
Ce guide vous fournit des lignes directrices sur la préparation du fichier et les formats à utiliser pour qu'il soit conforme aux attentes du système d'imports automatisés de DI. Si vous optez pour un fichier CSV, assurez-vous de lire la section sur les règles additionnelles pour les fichiers CSV.
Il est à noter que Dialog Insight peut travailler avec des fichiers qui ne respectent pas ces normes, mais que toute déviation de ce standard entraînera possiblement des travaux sur mesure pour le traitement des fichiers. Communiquez avec votre responsable de compte pour plus de détails.
Types de fichiers acceptés
Le système d’imports automatisés de Dialog Insight accepte comme fichier à importer les formats Excel et CSV (acronyme de « Comma Separated Values », c’est-à-dire que les valeurs sont séparées par des virgules).
Bien qu’il existe historiquement plusieurs façons distinctes de préparer des fichiers CSV, Dialog Insight utilise le format CSV tel que standardisé dans le document RFC 4180 disponible à l’adresse suivante : ietf.org/rfc/rfc4180.txt
Préparation du fichier
Voici quelques précisions sur les types de champs et sur comment les utiliser. Il est obligatoire d'inclure un champ clé (clé unique) dans le fichier d'import.
La première ligne du fichier doit donc être un en-tête qui décrit les données contenues dans les colonnes du fichier. Pour chaque colonne, la ligne d’en-tête doit contenir l’une des valeurs suivantes : champs ordinaires, champs clés, champ requis ou champ à ignorer.
Pour les champs clés de tables relationnelles, vous ne devez pas ajouter le « f_ », mais uniquement le préfixe « key_ ». Exemple : « key_EMail ».
Note : Cette option existe pour faciliter l’import lorsque les fichiers sont produits avec des outils sur lesquels le client a peu de contrôle; autrement, il est fortement recommandé de ne PAS utiliser cette option. Il est préférable de toujours produire un fichier qui contient exactement ce qui doit être importé, ainsi le volume de données transférées et la charge de travail requise pour traiter le fichier seront réduits, et, par conséquent, la performance sera améliorée.
Format des types de données
Les fichiers Excel et CSV traités par Dialog Insight ne doivent contenir que du texte. Certains types de données qui seront échangées dans ces fichiers doivent donc être formatés en texte et le système Dialog Insight supporte des formats précis qui sont requis lors de l’import et utilisés à l’export. C’est le cas pour les valeurs numériques ou décimales, les champs « vrai/faux » (booléen) et les champs de type « date & heure ».
Par exemple : 1234567 ou -9876543
Par exemple : 12345.67 ou -98765.43
- AAAA.MM.JJ HH:mm:ss
- AAAA.MM.JJ HH:mm
- AAAA.MM.JJ
À titre d’exemple, les champs de type « nombre entier » ajoutés à la fiche d’un contact sont stockés dans un champ SQL de type « nombre entier » 32 bits et supportent donc des valeurs entre -2147483648 et 2147483647. Un autre exemple est que les champs de type « date » utilisés dans certaines situations n’acceptent pas de date inférieure à l’an 1753.
Règles additionnelles pour les fichiers CSV
Les règles suivantes s’appliquent uniquement aux fichiers CSV, et s’ajoutent à celles mentionnées précédemment pour l’import de fichiers Excel et CSV.
- Le fichier doit contenir un enregistrement par ligne.
- Chaque ligne doit se terminer par une fin de ligne « CRLF ».
- Le séparateur de champ est la virgule, et le délimiteur de champ est le guillemet.
- Le délimiteur de champ est optionnel pour les champs ne contenant pas de caractères spéciaux.
Exemple : 123,456,"789",ABC,"DEF" - Le délimiteur de champ est obligatoire si le champ contient une virgule, un guillemet, ou toute forme de saut de ligne ou espacement vertical (CR, LF, VT, etc.).
Exemple : un champ contenant ab,c devient obligatoirement "ab,c"
Donc : 123,456,"789","ab,c","DEF"
De plus, tout guillemet contenu dans le champ délimité doit être doublé.
Exemple : ab"c devient "ab""c"
Donc : 123,456,"789","ab""c","DEF"
Si le champ lu commence par un guillemet, alors :
- Le champ se terminera seulement lorsqu’un guillemet qui ne fait pas partie d’une paire de 2 guillemets consécutifs est rencontré, peu importe les autres caractères rencontrés avant d’arriver à ce marqueur de fin de champ.
- Le guillemet initial et le guillemet final devront être ignorés.
- Toute paire de 2 guillemets consécutifs dans le champ devra être remplacée par un seul guillemet.
Le dernier enregistrement du fichier peut se terminer par EOF au lieu d’un CRLF; mais si la fin du fichier est atteinte et que le champ délimité n’est pas, cela causera une erreur.
Aucun CR ou LF présent seul (hors d’une paire CRLF) ni aucun caractère d’espacement vertical (VT) n’est permis en à l’extérieur d’un champ délimité; leur présence est donc une erreur.
Le système d’imports automatisés de Dialog Insight est en mesure d’utiliser une variété d’encodages, mais les imports manuels sont pour l’instant limités à l’import de fichiers encodés en UTF-8 ou ISO-8859-1.
Détection de l'encodage UTF-8 lors des imports
L’application Dialog Insight permet deux types d’imports de fichiers : l’import manuel (procédure lancée à la main par un utilisateur) et l’import automatisé (procédure récurrente qui récupère un fichier et l’importe selon un horaire établi).
Pour des raisons historiques, lors d’un import manuel, le fichier sera réputé être encodé en ISO-8859-1 à moins qu’il ne contienne un marqueur qui permette de reconnaître l’encodage UTF-8. Ce « Byte Order Mark » ou « Préambule » UTF-8 est une chaîne de 3 octets (0xEF 0xBB 0xBF en hexadécimal) injectée au début du fichier et qui sert de signature pour reconnaître l’encodage UTF-8. Pour plus de détails, visitez : http://en.wikipedia.org/wiki/Byte_order_mark.
Les imports automatisés permettent de définir explicitement l’encodage qui sera utilisé pour chaque fichier échangé. Les encodages possibles incluent, en plus d’iso-8859-1 et UTF-8, les encodages UTF-32 et UTF-16 dans les deux ordres de bytes possibles (« Big endian » et « Little-endian »).
Fichiers produits par Dialog Insight
Puisque les bases de données de Dialog Insight acceptent des données UNICODE, les fichiers produits à l’export utiliseront par défaut l’encodage UTF-8 et le « Byte Order Mark » sera inclus au début du fichier. Ceci permet d’assurer que tous les caractères contenus dans la base de données pourront être représentés dans le fichier. Certaines fonctions d’exports manuels dans l’application permettent de choisir un encodage ISO-8859-1, mais soyez avisé que l’export échouera si des caractères contenus dans les données à exporter ne peuvent pas être représentés en ISO-8859-1.
Choix de l'encodage
Bien que Dialog Insight supporte l’encodage ISO-8859-1, cet encodage est restreint à des caractères très spécifiques de l’alphabet nord-américain et européen; nous ne recommandons donc pas son utilisation pour des bases de données modernes. Un exemple fort simple est que cet encodage ne supporte pas les apostrophes ou guillemets stylisés qui sont utilisés couramment (’ au lieu de '). Le choix de l’encodage ISO-8859-1 est cependant acceptable lorsque vous devez transmettre des données à partir d’anciennes bases de données qui ne supportent pas UNICODE.
Validation du fichier et mise en place
Lors de la mise en place d’un import automatisé, notre équipe de service vous fournira la liste des codes de champs exacts correspondant à votre projet. Vous pouvez aussi consulter la liste de ces codes dans l’interface de configuration des champs de votre projet.
Une fois vos premiers fichiers produits, vous pourrez les remettre à notre équipe de développement, qui fera une validation du format, de l’encodage et des données, et mettra alors en place les procédures automatisées appropriées.