Retrouvez cet article dans : Linux Pratique Hors série 9

Le Président aurait dû être content : le bulletin de La Sauce semblait promis à un bel avenir (voir l’article précédent). Cependant, le Trésorier (que d’aucuns avaient surnommé " Iznogoud ") avait malicieusement souligné en réunion de bureau que la distribution du journal allait causer des difficultés. " J’en sais quelque chose, moi qui ai à gérer le fichier des adhérents et qui expédie régulièrement des lettres de rappel pour des cotisations impayées ! " avait-il susurré.

Une fois de plus, cet horrible Iznogoud gâchait la fête. Sa fête. Il se prit à rêver à un outil informatisé qui prenne en charge la diffusion du bulletin.
Interrogeant la liste de diffusion d’OpenOffice.org [Forum], le Président fut orienté vers une fonction inconnue de lui, le publipostage, et vers les nombreux documents mis à disposition sur le site d’OpenOffice.org. Il y découvrit l’art et la manière d’adresser des courriers à divers correspondants, dès lors que l’on dispose d’une " base de données " contenant les informations sur ceux-ci. C’était précisément son cas ! Il allait donc s’attaquer à ce nouveau défi et, une fois de plus, damer le pion au Trésorier.
En homme avisé, le Président décida de commencer par l’étude du principe de fonctionnement du publipostage [Publipostage]. Après quoi, il passerait à la réalisation de la diffusion du bulletin. Pour ce faire, il réaliserait tout d’abord la base de données qu’il savait nécessaire, puis il établirait le lien entre cette base et le document à envoyer. La sortie du premier numéro du bulletin serait l’occasion de tester triomphalement le nouveau mode de diffusion.

Le principe

Le publipostage – en anglais mailing – est la faculté offerte par les outils informatiques de fusionner deux ensembles d’informations : une lettre-type et un fichier d’adresses par exemple. L’opération de mailing est très couramment utilisée pour réaliser des séries de documents dont seule une partie change (ici, ce seront les adresses des adhérents) et dont la forme demeure semblable d’un document individuel à l’autre.
Le publipostage peut s’appliquer à de nombreux besoins, tels que la réalisation de circulaires, de fiches sur des matériels, la confection d’enveloppes ou d’étiquettes, des formulaires pré-remplis, etc.

Les éléments d’un publipostage

Pour pratiquer un mailing, le Président découvrit qu’il lui fallait deux éléments différents. Tout d’abord, un document " à trous ", le document de fusion, plus connu sous le nom de " lettre-type ". Ce document comporte la mise en forme générale des données. Ici, ce serait soit une étiquette, soit une enveloppe, soit une zone laissée volontairement vierge du
bulletin lui-même. Ensuite, il lui faudrait un ensemble de données destinées à combler les " trous " du document de fusion. Ici, ce serait les adresses des adhérents. Le diagramme de la figure 1 résume
les opérations.

Fig. 1 : Le principe du publipostage

1 " Base de données " et " source de données " sont ici synonymes.

Le document de fusion

La lettre-type est, par exemple, constituée d’un document de traitement de textes qui, outre la mise en forme habituelle, comporte des emplacements réservés, également nommés " champs ", où seront insérées les données voulues. Ces dernières seront prises dans la base de données au moment de la fusion proprement dite.

La " base de données "

La base de données – que le traitement de textes nomme du terme générique " source de données " – est le lieu où sont réunies les informations variables à insérer dans la lettre-type. OpenOffice.org v.2 accepte des sources de données 1 des types suivants :

• fichiers texte (fichiers .txt, .csv) ;
• feuilles Calc (classeurs .sxc ou .ods) ;
• tables de base de données dBase (fichiers .dbf) ;
• bases de données OpenOffice Base (fichiers .odb) ;
• bases de données externes accédées à travers des pilotes ODBC ou JDBC (MSAccess, MySQL, PostgreSQL).

En termes de fonctionnalités, les deux premières options (texte et Calc) ne sont pas équivalentes au trois dernières (tables de bases de données). Les tables de bases de données permettent, en effet, un accès dynamique aux informations au cours des opérations de publipostage elles-mêmes. Il est ainsi possible de procéder à des mises à jour in extremis. Elles offrent bien d’autres avantages comme, par exemple, des possibilités de réalisation de requêtes entre tables qui répondent aux besoins les plus complexes.

La liaison entre le document de fusion et la source de données

Il s’agit ici d’indiquer à la lettre-type l’emplacement où se trouvent les informations qui permettront de remplir les " trous " (les champs). Cet emplacement – c’est-à-dire le dossier où est enregistrée la source des données – peut se trouver sur la machine hôte ou ailleurs sur le réseau local.

La réalisation

À présent, il connaissait les grandes lignes de la réalisation d’un publipostage. Restait à les mettre en œuvre. Fidèle à ses principes – car c’était un homme à principes –, il commença par déterminer son plan d’attaque.

Le plan d’attaque

Comme précédemment, le Président se munit d’un crayon et d’une feuille de papier et y jeta les grandes lignes du travail qu’il aurait à accomplir : l’organisation du document de fusion et celle de sa base de données. Il posa également quelques questions qui, pour le moment, restaient pour lui sans réponse. En particulier, pourrait-il envoyer le bulletin à des adhérents sélectionnés ?

La création du document de fusion

Ce document, également nommé " lettre-type ", est celui qui va recevoir les données de la base.
Le Président utiliserait un document existant : le bulletin lui-même, qu’il avait créé auparavant (voir l’article précédent sur la réalisation d’un journal associatif), et qui serait aménagé de manière à recevoir les rubriques d’adressage. Un emplacement laissé vierge en bas de la dernière page serait le lieu idéal pour insérer ces informations.
Le document étant déjà créé, il passa à la conception de la base de données.

La " base de données "

Bien qu’OpenOffice.org puisse s’interfacer avec de nombreuses sources de données, et pour ne pas quitter un environnement bien connu, le Président avait décidé de mettre en œuvre le tout nouveau module Base. Il serait ainsi plus facile d’accéder aux données :
les données seraient modifiables dynamiquement pendant l’exploitation du document de fusion, ce qui permettrait de procéder à d’ultimes mises à jour ;
il serait possible, sans difficulté, de perfectionner la base et d’y créer des requêtes et des vues, elles aussi accessibles pendant les opérations de publipostage.
Pour plus de détails sur les bases de données et leurs éléments, on se reportera à l’article suivant consacré au module Base. Un glossaire qui détaille les notions manipulées ici figure également à la fin de
cet article.

La création de la base

Avant de créer la table qui lui servirait à stocker les adresses des adhérents, il lui fallait en créer le conteneur : la base de données proprement dite. Le Président lança le module Base. Cette opération peut s’effectuer au choix depuis n’importe quel autre module (Fichier -> Nouveau -> Base de données) ou par les menus du système d’exploitation.
La base est en général, et pour plus de commodité, créée dans un dossier spécifique. À l’ouverture du module Base, un assistant composé de deux fenêtres consécutives (Fig. 2) propose d’ouvrir une base existante ou bien d’en créer une nouvelle.

Fig. 2 : Première et seconde étape de l’assistant Bases de données

Le Président choisit de créer une base qu’il nomma DiffusionAioli et enregistra dans un dossier de même nom dans son dossier personnel 2.

2 Le dossier personnel est, sous GNU/Linux, le dossier /home/<user>. Sous Windows, il s’agit de Mes documents.

Fig. 3 : La fenêtre principale du module Base

La base étant créée, la fenêtre principale du module Base se présente (Fig. 3).

La création de la table

Même si elle en est l’élément " de base " (sic !), une table n’est qu’un des nombreux composants que peut contenir une base de données. Pour la créer, il cliqua sur le bouton Tables de la colonne Base de données, puis l’option Créer une table en mode ébauche, car cette dernière lui donne une maîtrise complète du processus, contrairement à l’assistant de création
de tables.
Une nouvelle fenêtre dédiée à la création de la table est présentée. Il s’agit d’une grille qui permet, pour chaque type d’information (les colonnes ou champs), d’en définir le nom et le type. Une description peut y être ajoutée ce qui permet de documenter le travail. Des propriétés, variables selon le type de champ, sont également accessibles en bas le la fenêtre (Fig. 4). L’article suivant consacré à Base donne plus d’informations sur ce sujet.

Fig. 4 : La création d’une table

Il est important, voire essentiel de spécifier une clef primaire pour chacune des tables d’une base. C’est pourquoi, dans la liste des champs figure ID, un champ de type Entier (Integer), indépendant de toute information, auto-incrémenté (la rubrique AutoValeur est positionnée sur " Oui ") et défini comme clef primaire. Pour donner l’attribut clef primaire à un champ (ou à plusieurs), le Président le sélectionna puis, par clic droit activa l’option correspondante (Fig. 5). Une icône " clef " apparaît dans la grille, en regard du nom de la colonne. Bien que cette clef primaire ne soit pas strictement nécessaire à la réalisation du publipostage, il est utile de prévoir l’avenir.
La structure finale de la table est montrée au tableau 1.

Fig. 5 : La définition de la clef primaire

Après avoir créé la structure, il ne restait plus qu’à enregistrer la table... et à y insérer des données. Il effectua l’enregistrement en cliquant sur le bouton Enregistrer (ou par le menu Fichier -> Enregistrer) et donna le nom Adherents à la table. Par le menu Fenêtre -> Fermer la fenêtre, il fut ramené à la fenêtre principale de Base. Le nom de la table " Adherents " apparaissait maintenant dans la zone Tables.

L’ajout d’informations dans la table

L’insertion de données dans les tables Base peut être réalisée de multiples façons. La plus simple pour l’instant consiste à appeler le dialogue correspondant en double cliquant sur le nom de la table (ou par le menu Édition -> Ouvrir un objet de base de données). Plus tard, il sera possible de créer des formulaires qui facilitent la prise en main de l’outil (voir l’article consacré à Base). Le Président ajouta ainsi quelques adresses fictives afin de tester les fonctionnalités qu’il mettait en place (Fig. 6).

Nommage des entités

(tables, champs, etc.)

• Donnez des noms les plus parlants possible. Des noms abscons pourraient par la suite occasionner des interrogations de la part d’utilisateurs n’ayant pas participé à la conception de la base.
• N’utilisez pour les noms de tables et de champs que des lettres, chiffres et le caractère souligné bas " _ " (underscore). En d’autres termes, évitez tous les caractères qui, dans le cas d’une migration entre différents systèmes de gestion de base de données, seraient susceptibles d’imposer des adaptations : espace, caractères accentués, caractères de ponctuation, etc. sont de véritables pièges prêts à mordre.
• Ne pas utiliser d’identifiants SQL 3 comme noms de colonne. C’est le cas, en particulier, du terme " DATE ". Si ce choix n’est pas rédhibitoire, il risque d’occasionner des manipulations supplémentaires dans le cas de la réalisation de requêtes.

Il remarque deux choses :

• La colonne ID n’a pas à être renseignée : auto-incrémentée, c’est Base qui en gère le contenu sous la forme d’une valeur numérique croissante. Le symbole <Autochamp> y apparaît tant que la ligne n’est pas validée.
• Il n’y a pas lieu de procéder ici à un enregistrement, car les données sont mémorisées automatiquement lorsque l’on quitte la ligne en cours d’édition.

Pour revenir à l’interface générale du module Base, il appela Fenêtre -> Fermer la fenêtre ([Ctrl] + [W]).

Fig. 6 : La saisie de quelques données dans la grille proposée par Base

La table existait maintenant et pouvait servir de source de données de publipostage. Il était donc prêt à passer à l’étape suivante : la réalisation de la liaison entre la table et le document de fusion.
Pour la mise en œuvre effective, il demanderait à la Secrétaire de La Sauce de lui confier le fichier des adhérents (un simple classeur Calc) qu’il convertirait au format Base [Conversion].

La création de la liaison entre la table et la lettre-type

Il referma le module Base et ouvrit le document type (la maquette de bulletin).
Les bases de données gérées à travers le module Base sont connues dès l’ouverture des autres modules OOo 4. Il appuya [F4] pour faire apparaître les sources de données dans le Navigateur de données (Fig. 7). Bien entendu, il choisit la base DiffusionAioli et plus particulièrement la table Adherents.

Fig. 7 : Le Navigateur de données

3 SQL (Structured Query Language, langage de requête structuré) est l’espéranto des bases de données relationnelles d’aujourd’hui. Ce langage permet d’agir sur les bases de données et d’en extraire les données pertinentes.

4 Dans le cas de liaisons avec d’autres types de tables, telles que les classeurs Calc, la liaison entre la table et les données doit être explicitement déclarée à Writer. Cette opération s’effectue très simplement via le menu Édition -> Changer de base de données.

Au passage, il remarqua que le Navigateur de données lui offrait une vision des informations contenues dans la table, mais aussi des moyens de filtrage et de tri de ces informations, par l’intermédiaire des
différents boutons de sa barre d’outils.
Puisque les coordonnées postales de l’adhérent devaient être insérées dans le bas de la dernière page, il positionna le point d’insertion à cet endroit dans le document. Puis, il fit appel à Insertion -> Champ -> Autres ([Ctrl] + [F2]), onglet Base de
données (Fig. 8) pour accéder à la fenêtre d’insertion des champs.

Fig. 8 : L’insertion des champs de base de données dans le document-type

Pour chaque champ utile, il positionna le point d’insertion dans le document, sélectionna le nom du champ dans la fenêtre, puis cliqua sur Insérer. En fin d’opération, il referma la fenêtre d’insertion des champs
(il aurait également pu réaliser cette action par un glisser/déposer du nom de colonne dans le texte). Ces derniers apparaissaient sous la forme <Nom du champ> sur fond grisé entre crochets aigus.

Fig. 9 : Les données apparaissent dans les champs

Il termina par l’affectation d’une mise en forme adaptée aux champs insérés (alignement, police, etc.). Naturellement, il enregistra son travail.
Son bulletin comportait maintenant tout ce qui était nécessaire à la phase finale : la fusion.
La fusion est l’opération ultime du publipostage. Elle réalise l’intégration des données figurant dans la base de données au sein de la lettre-type. Chaque information vient, lorsque l’enregistrement est traité, s’insérer dans la rubrique correspondante placée dans le document de fusion. OpenOffice.org génère alors les documents finaux personnalisés.
Mais avant de se lancer, le Président désirait vérifier que l’aspect du document correspondait à ses désirs.

Le contrôle de l’aspect du document final

Pour manipuler les données gérées dans le publipostage, il disposait de la barre d’outils du Navigateur de données. En particulier, le bouton Données dans les champs (entouré en rouge sur la figure 9) lui permettait de se faire une idée précise de la position et de l’encombrement des informations réelles dans le document type. Il sélectionna l’enregistrement à visualiser, puis cliqua sur ce bouton.
Pour revenir à l’affichage des noms de champs, il sélectionna : Édition -> Changer de base de données et, sa base actuelle étant présélectionnée, cliqua simplement sur Définir.

La fusion

Il restait maintenant à réaliser l’opération finale : la fusion des données et de la lettre-type. Pour ce faire, il ferait appel à l’Assistant Mailing (menu Outils -> Assistant mailing).
Cet assistant prend en charge toutes les opérations liées au publipostage (mailing en anglais). Il fut tout d’abord effrayé par les huit étapes proposées. Compte tenu de ses besoins, pour l’heure très basiques, il fut vite rassuré : seules la première et la dernière étapes lui seraient utiles. Il ignorerait donc les autres... pour l’instant.
À la première étape, il choisit d’utiliser le document actif, car la maquette du bulletin était ouverte dans Writer. Il laissa de côté les étapes suivantes et alla directement à la dernière qui lui permettrait de choisir la manière dont il voulait réaliser le document final fusionné (Fig. 10). Lors de cette étape, Writer traite les lignes de la source de données et prépare la fusion.

Fig. 10 : La dernière étape de l’Assistant mailing : la fusion

La partie supérieure de la fenêtre propose quatre options de base qui donnent chacune accès à un jeu d’options complémentaires, en bas :

• Enregistrer le document de base :

mémorise la lettre-type seule, c’est-à-dire dans son état avant la fusion.

•  Enregistrer le document fusionné :

mémorise le document après fusion, c’est-à-dire avec les données. Cette opération peut être réalisée soit sous la forme de documents individuels pour chaque destinataire, soit sous la forme d’un document unique qui regroupe tous les documents individuels, placés l’un après l’autre.

•  Imprimer le document fusionné :

envoie le résultat de la fusion directement à l’imprimante.

•  Envoyer le document fusionné par e-mail :

expédie le résultat de la fusion par e-mail. Il faut alors que la table comporte une colonne qui spécifie l’adresse e-mail du destinataire.

Il choisit l’option la plus simple et la plus souple : l’enregistrement du document fusionné en un seul document. Ainsi, avant l’impression proprement dite, il pourrait réviser chaque exemplaire et, au besoin, apporter de petites corrections. Ceci, au moins, pendant sa période " probatoire " !
Dans ce cas, il faut donner à Writer le nom du fichier à enregistrer en cliquant sur le bouton Enregistrer les documents. Après validation de cet enregistrement, le bouton Terminer devient actif et permet de revenir au document de fusion qui est maintenant à l’état fusionné, mais sous une version non enregistrée
(la version enregistrée précédemment est bel et bien sur le disque !). Le Président peut ainsi rapidement parcourir les pages et vérifier la bonne exécution de la fusion. Le document-type originel a été refermé lors de la fusion.

Perfectionnements

Le Président venait de réaliser son tout premier publipostage. Il en était – à juste titre – très fier ! Néanmoins, il lui semblait que bien des perfectionnements pourraient être apportés à ce premier jet. En particulier, il voulait se débarrasser des lignes vierges (inutiles) qui apparaissaient dans les adresses. Il voulait également pouvoir sélectionner les destinataires.

L’omission des lignes vides

Tous les destinataires n’ont pas une adresse en deux parties. Un grand nombre d’entre eux se contentent modestement d’une seule ligne d’adresse. Le résultat de la fusion montre que, pour ceux-ci, il existe une ligne vierge dans le bloc adresse, correspondant à l’information Adr2 absente. Comment se débarrasser de cette ligne inopportune ?
Ses recherches dans l’aide en ligne ([F1]) et les réponses à ses questions sur les listes de discussion d’OOo [Forum] le mirent sur la piste : l’emploi d’un champ " paragraphe masqué " lui permettrait d’arriver à ses fins. Il fallait cacher le paragraphe contenant le champ <Adr2> correspondant à la colonne Adr2 de sa table lorsque son contenu était vide. Il plaça donc le point d’insertion immédiatement à gauche du champ Adr2 dans le bloc adresse du document-type et par [Ctrl] + [F2], il appela le dialogue d’insertion de champs. L’onglet Fonctions était celui qui contenait le nécessaire (Fig. 11).

Fig. 11 : Le masquage d’un paragraphe

Sélectionnant Paragraphe masqué, il entra Adr2=="" dans la rubrique Condition. Ce qui signifie en termes informatiques " masquer le paragraphe en cours lorsque la colonne Adr2 est vide ".
Il valida en cliquant sur Insérer avant de refermer la fenêtre. Il remarqua que le champ nouvellement inséré n’apparaissait pas explicitement dans le document (mais l’appui sur [Ctrl] + [F9] révélait la présence de ce nouveau champ). Il testa de la même manière que précédemment et constata qu’en effet les lignes correspondant à Adr2 n’étaient insérées dans le bloc adresse que lorsque la donnée était présente (Fig. 12).

Fig. 12 : La ligne est supprimée lorsqu’elle est vide

La sélection des destinataires

Il pourrait être intéressant de ne pas expédier le document fusionné à tous les adhérents. Par exemple, il pourrait arriver que des numéros du bulletin soient personnalisés pour les adhérents de certaines régions, lorsque des évènements particuliers s’y déroulent. Pour ces adhérents, on pourrait alors ajouter un feuillet particulier consacré à l’évènement. Il serait donc nécessaire de traiter l’expédition du bulletin en différents lots, en fonction du contenu.
Le Navigateur de données comporte une barre d’outils dont certains sont dédiés au tri (boutons " A…Z ") ou au filtrage des données (les entonnoirs). Sous les versions 2.0, ces tris et filtrages ne s’appliquent malheureusement qu’au seul affichage, mais pas à la fusion. Le Président disposait néanmoins d’une option pour ce faire : utiliser l’ancien assistant mailing de la version 1.x d’OOo qui propose le filtrage des données pendant la fusion.
L’" ancien " assistant mailing est appelé par le menu Fichier -> Imprimer. Writer pose la question de savoir s’il faut imprimer une lettre-type par opposition au seul document de fusion (Fig. 13). Il prit la précaution de répondre " Oui " et, surtout, de ne jamais cocher la case Ne plus afficher l’avertissement !

Fig. 13 : La question " magique "

La fenêtre de l’ancien assistant mailing qui apparut alors présentait de fortes ressemblances avec un environnement déjà connu : il y retrouvait le Navigateur de données, doté des mêmes fonctionnalités que précédemment. Il pourrait ici procéder à la sélection ou au filtrage des destinataires et appliquer cette sélection ou ce filtrage à la sortie finale.
Pour filtrer selon un critère unique, il suffit d’utiliser le filtre automatique : il sélectionna une ligne dans laquelle le critère était satisfait (ici, une ligne dans laquelle la colonne Localite contient " Paris ") et prit soin de placer la sélection dans la colonne concernée (Localite). Il cliqua sur le bouton Autofiltre (repère 1 sur la figure 14) ce qui eut pour résultat de ne laisser présentes dans la liste que les lignes dont la colonne Localite contenait " Paris " (Fig. 15). Les filtrages plus complexes (jusqu’à trois critères) sont accessibles par le bouton Filtre standard (repère 3). Le bouton Supprimer le filtre/tri (repère 4) permet de retrouver la liste dans son état initial.

Fig. 14 : Les boutons de filtrage

Fig. 15 : Le filtrage en action

Il ne lui restait plus qu’à choisir les options de sortie : impression directe ou fichier. En cas de sortie vers plusieurs fichiers, il est possible de demander que les noms des fichiers soient extrapolés à partir du contenu d’une colonne (dans l’exemple : colonne ID).

Email or not email ? Ou comment utiliser les requêtes

C’est alors qu’il reçut un appel du Trésorier qui venait aux nouvelles... et qui, sur les informations positives qu’il reçut, lui signala non sans malice que La Sauce n’était pas une association très riche. Or, la diffusion du bulletin par voie postale est très coûteuse. Il faudrait peut-être songer à réduire les coûts que ce fichu bulletin allait engendrer. Le Président en resta coi. En effet, il n’avait pas songé à cet horrible détail. Il ne fallait à aucun prix que le Trésorier tue le projet dans l’œuf !
Il s’intéressa alors à la diffusion par email, car la majeure partie des adhérents disposaient de ce moyen de communication.

Préalables

• Les adresses email

Bien entendu, il fallait que la source des données comporte l’information correspondante. Il s’assura que sa table " Adherents " comportait une colonne " Email " et il en ajouta par précaution une seconde " VeutMail " qui permettrait de suivre les désirs des adhérents de recevoir des mails ou non, qu’ils disposent ou non d’un tel moyen de communication.

• Comment faire pour les quelques irréductibles hors Internet ?

Si la majeure partie des adhérents possèdent une adresse email, ce n’est certes pas le cas de tous. De plus, même parmi ceux qui profitent de ce moyen de communication, il en est qui préfèrent ne pas recevoir de messages électroniques non sollicités. Il faudrait donc procéder aux envois des bulletins en deux lots : un lot par la messagerie électronique pour les " modernes " et un second par le courrier postal pour les " irréductibles ". Cela signifie-t-il qu’il faille maintenir une table Adherents pour chacune des catégories ? Bien sûr que non ! Et le Président l’avait bien pressenti qui avait déjà ajouté les deux colonnes VeutMail (contenant VRAI si l’adhérent accepte les emails, FAUX dans le cas contraire) et Email à sa table d’adhérents.
Grâce à ces deux colonnes, il allait pouvoir procéder à deux sélections : une sélection des adhérents pour lesquels la colonne VeutMail contient VRAI. À cette sélection-là, les bulletins seraient adressés par voie électronique. Une autre sélection des adhérents pour lesquels la colonne VeutMail contient FAUX. À ceux-ci, les bulletins seraient adressés par voie postale. Mais comment pratiquer cette sélection ?
La solution lui fut donnée par un membre d’une liste de diffusion sur le site OOo et se nomme " Requête ". Grâce au module Base, il est possible de créer autant de requêtes que nécessaire. Le Président créerait donc une requête pour les envois par email.

La création de la requête

Pour créer sa requête, le Président fit un clic droit sur le terme Requête dans le Navigateur de données et choisit Édition fichier de base de données (Fig. 16).

Fig. 16 : L’option permettant la création de requêtes

Le module Base s’ouvrit alors. Puisque seule la création de requêtes l’intéressait, il se contenta de cliquer sur le bouton Requêtes dans la colonne Base de données, puis de Créer une requête en mode ébauche pour passer à la création proprement dite.
Un premier dialogue lui demanda quelle table ajouter. Il choisit Adherents qui contenait les données, cliqua sur Ajouter, puis referma ce dialogue. Une boîte " Adherents " figurait maintenant dans la zone grisée du haut. Il double cliqua successivement dans cette boîte sur les libellés * (étoile, qui signifie " tous les champs ") et VeutMail. Ces libellés furent insérés par Base dans les deux premières colonnes de la grille du bas (Fig. 17).

Fig. 17 : La fenêtre de création des requêtes

La première colonne (le symbole " étoile ") spécifiait qu’il voulait que la requête comporte tous les champs de la table Adherents (il aurait pu n’en sélectionner individuellement que quelques-uns). La seconde lui permettrait de sélectionner les adhérents qui voulaient recevoir des emails. Pour ce faire, il décocha le bouton Visible afin que cette colonne n’apparaisse pas deux fois dans le résultat de la requête. Enfin, dans la ligne Critère, il entra la condition qui permettrait à Base de sélectionner les données. En l’occurrence, la colonne VeutMail devrait contenir VRAI.
Il vérifia immédiatement que la requête exécutait bien ce qu’il cherchait. Par Édition -> Exécuter la requête, il put constater que les données retournées satisfaisaient la condition (Fig. 17).
Il fallait, bien sûr, mémoriser cette requête, ce qu’il fit par Fichier -> Enregistrer ([Ctrl] + [S]) et la baptisa R_Envoi. Pour revenir à la fenêtre principale de Base, il choisit Fichier -> Fermer.
Il restait à retourner au module Writer afin d’exploiter les deux requêtes nouvellement créées. Mais auparavant, il prit soin d’enregistrer à leur tour les modifications apportées à la base par [Ctrl]+[S].

L’utilisation des requêtes

Les requêtes apparaissent dans le Navigateur de données, sous le libellé correspondant (Fig. 18). La sélection de l’une ou l’autre provoquait bien l’affichage des sous-ensembles d’informations dans le Navigateur de données.

Fig. 18 : La requête apparaît dans le Navigateur de données

Attention ! Bien qu’affichés, ces sous-ensembles de données ne sont pas pris en compte pour le publipostage tant qu’une liaison explicite avec eux n’est pas définie. Ce qui signifie que, le document-type étant actuellement lié à la table Adherents, l’exécution de l’assistant mailing prend toutes les données de cette table en considération. Pour que les seules données retournées par les requêtes soient prises en compte, le Président devait spécifier à OpenOffice.org que sa source de données avait changé. Rien de plus simple ! Il appela Édition -> Changer de base de données, choisit la requête R_Envoi et cliqua sur Définir. Le lien avec cette requête était à présent établi.

Fig. 19 : Les paramètres d’envoi des emails

L’envoi par email

La procédure à suivre pour l’expédition du bulletin par email est très ressemblante à celle qu’il avait déjà utilisée : l’Assistant mailing est en effet l’outil à employer. Mais auparavant, il faut donner quelques informations complémentaires à OOo.

• La configuration du compte d’émission des emails

Il fallait en effet qu’OpenOffice.org connaisse les paramètres d’envoi des emails : le nom du compte de messagerie de l’expéditeur, le mot de passe associé, etc. Ces paramètres sont communiqués par les fournisseurs d’accès (FAI).
Le Président se référa donc à la fiche remise par son FAI lors de la souscription de son abonnement et reporta les informations requises dans l’option Outils -> Options, OpenOffice.org Writer, Email de mailing (Fig. 19).

• Votre nom : le nom d’utilisateur en clair ;
• Adresse e-mail : l’adresse email de l’expéditeur ;
• Nom du serveur : le nom du serveur de courrier sortant (serveur SMTP) du FAI ;
• Port : le port utilisé pour l’envoi des messages en SMTP (généralement 25).

Le bouton Authentification du serveur lui permit d’entrer son identifiant et son mot de passe pour communiquer avec le serveur de messagerie de son FAI.
Le bouton libellé par erreur Paramètres du test (en fait, il faut lire Tester les paramètres) permet de vérifier que la communication s’effectue correctement avec les serveurs de messagerie du FAI.

• L’envoi des emails

Fig. 20 : Les paramètres d’envoi par email

Il appela l’assistant mailing. Il en parcourut alors les étapes suivantes :

• Il sélectionna le document actif.
• Il choisit l’envoi d’e-mail.
• Il cliqua sur le bouton Sélectionner une liste d’adresses, puis le bouton Modifier le tableau. Dans la liste proposée, il choisit le tableau d’adresses correspondant à sa requête (ici, R_Envoi), puis valida les deux dialogues.
• Après que le module Writer ait généré les documents, il put préciser les paramètres du publipostage (Fig. 20) :
  • À : le nom de la colonne de la table ou de la requête qui contient l’adresse de courriel du destinataire.
  • Objet : le contenu de la rubrique " Objet " du message électronique à expédier.
  • Envoyer en : le type de message à expédier. Le choix texte brut (Plain text) ou HTML provoque la livraison du document de fusion dans le corps du message. Les autres formats (OpenDocument Text [.odt], Microsoft Word document [.doc] et Adobe PDF-Document [.pdf]) sont envoyés sous la forme de fichiers joints.
• Et les " rebelles " ?
  Bien entendu, il ne fallait pas oublier les irréductibles qui désiraient recevoir leur courrier des mains du postier. Le Président se dit qu’il pouvait soit créer une deuxième requête en spécifiant dans ce cas la condition FAUX dans la colonne VeutMail ou bien simplement changer ce même paramètre dans la requête R_Envoi. Dans un cas comme dans l’autre, l’opération ne demanderait que quelques instants.

Conclusion

Ce soir-là, lors de la réunion de Bureau, le Trésorier-Iznogoud était vert. Non seulement, il n’avait pas pu mettre en défaut ce Président honni, mais il s’apercevait que ses propres méthodes de travail (la réalisation totalement manuelle des rappels de cotisation, par exemple) lui faisaient perdre un temps fou. Une fois de plus, l’aura du Président en sortit renforcée. Il avait bluffé son auditoire.

Le Président savait cependant que bien du chemin lui restait à parcourir en matière de publipostage et de gestion des données. Il lui faudrait explorer maintenant le module Base plus en profondeur, en particulier l’utilisation des vues, et exploiter d’autres options du publipostage, telles que la réalisation d’étiquettes...

Glossaire

Base de données : Une base de données est constituée d’un ensemble de tables, toutes relatives au même domaine qu’elles permettent de documenter.
Les outils de gestion de bases de données (en Français les SGBD [systèmes de gestion de bases de données], en Anglais les DBMS [Database management systems]) dont Base/HSQLDB fait partie, permettent de définir les tables, des relations entre les tables et de les interroger au moyen de requêtes.
Le modèle de bases de données actuellement le plus utilisé est le modèle relationnel.
Clef primaire : La notion de " clef primaire " est très importante en matière de gestion de bases de données. Une clef primaire est une colonne ou une combinaison de colonnes telles que leur contenu garantit l’unicité de la ligne repérée. Cette unicité permettra par la suite d’assurer l’exactitude des résultats des requêtes et des liaisons entre tables.
Par exemple, si nous étions sûrs qu’il n’existe pas de cas d’homonymie complète, nous pourrions choisir la combinaison des colonnes Nom + Prénom pour assurer l’unicité des informations concernant une personne dans une table des adresses. Tel n’est pas le cas (il serait étonnant qu’il n’existe pas plusieurs Jacques Dupont) : il nous faut un critère qui garantisse absolument l’unicité.
Lorsqu’une table comporte une/des colonne(s) répondant à ce critère, il n’est pas utile d’inventer de nouvelles données. Par contre, si aucune colonne ou combinaison de colonnes ne permet de garantir l’unicité de la clef primaire, alors il faut en créer une nouvelle pour cet usage (souvent de type entier auto-incrémenté). Une table ne peut avoir qu’une seule clef primaire.
Colonne (ou champ) : Une colonne, à laquelle sont associés un nom et un type, définit une caractéristique de l’information à stocker dans la table.
Ligne (ou enregistrement) : Une ligne est constituée d’un regroupement de colonnes qui, ensemble, définissent une information de base.
Requête : Une requête est une commande qui permet d’extraire des données d’une ou plusieurs tables selon des critères de sélection et de tri choisis. Les données reflétées par une requête ne sont mises à jour qu’à l’instant où celle-ci est exécutée.
Table : Une table de base de données est une collection d’informations organisée en lignes et colonnes. Un tableau Calc est tout à fait représentatif de ce à quoi ressemble une table de base de données.
Type des données : Le type des données d’une colonne définit très précisément l’étendue prévue pour le contenu de cette colonne. Par exemple, le type INTEGER autorise les valeurs numériques entières de -231 à +231-1. Par exemple, la colonne Nom, de type VARCHAR [60], indique qu’on y enregistre des noms de personnes, à concurrence d’une longueur de 60 caractères.
Il est toujours préférable de choisir le type le plus approprié au contenu actuel et futur des colonnes !
Vue : Une vue est un ensemble de données qui s’apparente à la fois à une table et à une requête. À une requête, car une vue permet l’extraction d’informations de la même façon que pour une requête. À une table, car les données reflétées par la vue sont mises à jour en même temps que celles des tables qu’elle interroge.

Références

• [Conversion] Conversion de classeurs Calc en tables Base : http://fr.openoffice.org/Documentation/How-to/Bdd/CalcABase.pdf
• [Doc] Section " documentation " du site OpenOffice.org : http://fr.openoffice.org/Documentation/Index.html
• [Forum] Point d’entrée dans les forums OOo Entrée " users-fr " sur : http://fr.openoffice.org/contact-forums.html
• [Publipostage] Un guide sur le publipostage : http://fr.openoffice.org/Documentation/Guides/GuidePublipostage.pdf

 Retrouvez cet article dans : Linux Pratique Hors série 9