Document d architecture

Document d architecture Composants, fonctionnement général et prérequis techniques Calame Software S.A.S

Versions Version Date Description Auteur 2.8 18/11/2012 Mise à jour pour la version 3.5 Sébastien Pancher 2.7 05/03/2012 Fusion gestionnaires, MAJ charte graphique Sébastien Pancher 2.5 03/11/2011 MAJ suite à la sortie de la V3.1 Sébastien Pancher 2.0 20/07/2011 Description des fonctionnalités Sébastien Pancher 1.9 13/04/2011 Suppression Answer pour GTClient Sébastien Pancher 1.8 01/04/2011 Support navigateurs internet Sébastien Pancher 1.7 25/03/2011 Ajout du rôle de gestionnaire de suivi Sébastien Pancher 1.6 12/02/2011 Ajustements des prérequis Sébastien Pancher 1.5 19/01/2011 Ajustements des prérequis Olivier Corneloup 1.1 07/01/2011 Modifications de la gestion PKI Nicolas Durand 1.0 23/11/2010 Première version Sébastien Pancher Gathering 1 Tools : architecture 1 /19

Contenu Description de la suite logicielle Gathering Tools...3 Rôles et responsabilités...4 Fonctionnalités...5 Conception de formulaires...5 Conception des transactions...6 Pilotage / Workflow...7 Architecture...8 Schéma d architecture...8 Description des modules...8 Description des transactions...9 Administrateur Serveur...9 Administrateur Base GT...9 Développeur Serveur... 10 Gestionnaire - Serveur... 10 Serveur Base de données client... 11 Destinataire - Serveur... 11 Droits nécessaires sur les bases de données... 12 Base GT... 12 Base client... 12 Sécurité... 13 Authentification des accès... 13 Modules concernés... 13 Fonctionnement de l authentification pour l accès aux modules Design et GTClient... 13 Sécurisation des transactions par messagerie... 13 Utilisation de certificats pour l authentification et le cryptage - PKI... 13 Paramétrage... 14 Fonctionnalités... 15 Prérequis techniques... 18 Gathering 2 Tools : architecture 2 /19

Description de la suite logicielle Gathering Tools Gahtering Tools est une suite d outils logiciels permettant d alimenter le système d information de données préalablement collectées sous forme de documents de type classeur Excel. Gathering Tools effectue cette tâche en remplaçant les dits fichiers bureautiques par des formulaires proposant une ergonomie et des fonctionnalités extrêmement proches des documents d origine. L exécution des processus de collecte fait appel à une solution de type «3-tiers» permettant la distribution des formulaires, le pilotage du processus de collecte, le stockage des données et leur restitution sous forme de classeurs Excel. Les principaux bénéfices de Gathering Tools sont : La continuité d ergonomie, qui limite la conduite du changement pour les fournisseurs de données La conception de formulaires structurant à partir de classeurs Excel, qui facilite les échanges entre les gestionnaires fonctionnels et les développeurs IT. La capacité de pilotage des flux pour les gestionnaires La souplesse de mise en œuvre et le faible impact sur le système d information Gathering 3 Tools : architecture 3 /19

Rôles et responsabilités 2003 2014 Calame Software S.A.S Gathering Tools peut être déployé sur des périmètres très différents, depuis le petit projet géré par quelques personnes jusqu aux projets plus vastes impliquant des centaines d utilisateurs répartis sur de nombreux sites. Plus les projets seront légers, plus il sera fréquent que certains acteurs cumulent différents rôles. Le tableau ci-après donne la liste des rôles pouvant être attribués dans un projet Gathering Tools. Rôle Responsabilité Modules installés Profil-Type Administrateur Créée et paramètre les instances o Connexion au repository o Connexion à la base cliente o Connexion au compte de messagerie o Connexion au serveur Web o PKI Créée et gère les utilisateurs Développeur Gère les utilisateurs o Créée et maintient les accès développeur et gestionnaire o Créée et maintient les groupes d utilisateurs o Créée et maintient les filtres d accès des gestionnaires aux modèles Créée et maintient les modèles (formulaires et tableaux de bord) Créée et maintient la base de données sous-tendant les transactions au sein d une instance Créée et maintient les actions mises à disposition des gestionnaires Gestionnaire Exécution des actions créées par les développeurs Suivi des campagnes Validation des réponses Gestion de la communication auprès des destinataires (relances, versions, etc.) Valideur Suivi des campagnes Validation des réponses Gestion de la communication auprès des destinataires (relances, versions, etc.) Contributeur Alimentation des formulaires en données Consultation des tableaux de bord GTAdmin, GTClient Design, Answer, GTClient GTClient ou accès web et Acrobat Reader GTClient ou accès web et Acrobat Reader Answer Equipe d infrastructure, correspondant IT Développeur, DBA, MOA Responsable fonctionnel d une entité de reporting Responsable fonctionnel d une entité de reporting Gathering 4 Tools : architecture 4 /19

Fonctionnalités Gathering Tools possède un jeu de fonctionnalités très étendu, mais ces fonctionnalités peuvent être regroupées dans les catégories suivantes : Conception de formulaires Le gestionnaire fournit au développeur un fichier Excel à transformer en formulaire. Le développeur, à l aide du module Design, construit le formulaire en important le fichier Excel. Une fois l import réalisé, le développeur obtient un document au format GT (.QST) reproduisant fidèlement le classeur Excel (mise en forme, structure, formules de calculs, formats de nombres, etc.) mais non modifiable. Le développeur va alors effectuer trois opérations : 1. Sécurisation des données. Le formulaire ne pourra être saisi par les destinataires que sur les cellules contenant des objets. GT propose une gamme d objets très complète (boite de saisie, liste déroulante, groupe de boutons radio mais aussi hyperliens, pièces jointes montantes et descendantes et autres objets avancés). Chaque objet propose un jeu de propriétés permettant d encadrer la fourniture des données par les destinataires (zone obligatoires et contrôles de cohérences : toutes les fonctions du moteur de calcul peuvent être utilisées pour créer les contrôles de cohérence souhaités). Le développeur s assure ainsi que les destinataires ne pourront pas renvoyer un jeu de données incomplet ou incohérent. 2. Structuration. Les objets du formulaire vont supporter des transactions avec les destinataires (collecte) et avec le système d information (alimentation du formulaire, intégration des données collectées). Pour gérer ces transactions de la façon la plus efficace possible, le développeur va regrouper les objets en compartiments. Les compartiments peuvent être assimilés à des modèles de données. Les compartiments, outre leur rôle d organisation des données, permettent d ajouter des fonctionnalités aux structures du formulaire (transposition des données, ajout / suppression de lignes, de tableaux, d onglets, etc.) 3. Création de la matrice de saisie Le formulaire peut être l interface unique de saisie si les données à fournir ne sont pas trop volumineuses. Dans le cas contraire, il est considéré comme une bonne pratique de fournir aux destinataires une matrice de saisie. La matrice de saisie est, schématiquement, un export du formulaire au format Excel (.XLS ou.xlsx) comportant, sur chaque cellule correspondant à un objet du formulaire, une zone de nom contenant le nom de l objet. Cela permet aux destinataires de travailler directement sur la feuille Excel puis d importer les données d Excel dans le formulaire d un simple clic. Les zones de nom permettent de gérer avec souplesse les modifications de la feuille Excel par les destinataires : les données sont importées par leur nom, pas en fonction de leur position. D autre part, comme les données ne peuvent être transmises que par le truchement du formulaire, toute erreur de données est détectée et bloque la transmission, un hyperlien pointant vers la cellule incriminée de la feuille Excel étant fourni pour une ergonomie optimale. Les matrices de saisies permettent ainsi aux destinataires de créer ou de pérenniser des mécanismes d automatisation de la fourniture de données plus ou moins élaborés (liens vers d autres feuilles Excel, macros, connexions ODBC, etc.) Gathering 5 Tools : architecture 5 /19

Conception des transactions Une fois le formulaire créé, le développeur va créer les transactions entre le serveur et les correspondants. Les transactions sont des actions qui, une fois créées, seront mises à disposition des gestionnaires pour exploitation en fonction de leurs droits respectifs. GT reconnait trois types d actions : 1. Lancement de campagne L action de lancement de campagne définit : a. La diffusion du formulaire Le développeur fournit à la campagne un objet de données (table / vue /requête sur la base client) fournissant un annuaire 1 des destinataires et un autre objet fournissant les affectations. Le croisement de ces deux objets (jointure) permet au développeur de définir les axes de diffusion et de collecte permettant de gérer la granularité des données. Par exemple, une campagne collecte des données auprès de 5 filiales, mais dans chaque filiale 2 correspondants sont identifiés, un correspondant principal et un suppléant. Au final, 10 formulaires seront diffusés (5x2) mais seuls 5 réponses pourront être validées (une par élément de l axe de diffusion, la filiale dans notre cas). Ce mode de fonctionnement permet de gérer avec beaucoup de souplesse les démultiplications et recouvrement de périmètres. b. L alimentation du formulaire Pour chacun des compartiments du formulaire, le développeur peut sélectionner un ou plusieurs objets de données (table / vue /requête sur la base client) alimentant le compartiment en données. Les données d alimentation peuvent être filtrées par les axes de diffusion afin que chaque formulaire s adapte, en données et en structure, au contexte métier des destinataires. c. Les messages contextuels de la campagne Pour chaque évènement de la campagne (lancement, réception de réponses, relance, gestion des doublons, validation/invalidation, etc.) le développeur peut définir des modèles de messages. Les messages sont des emails pouvant contenant des variables et différentes pièces jointes pour s adapter au contexte du destinataire. d. Les modalités techniques des transactions Les transactions entre le serveur et les destinataires peuvent mobiliser deux types de connectivité : le web (transactions http(s)) et la messagerie (transactions de données par mail), chaque modalité possède ses avantages propres : le mail offre une grande capacité de synchronisation, la messagerie permet de travailler offline et avec les entités à faible bande passante. Pour plus de détail, consulter le chapitre «Architecture», cf infra. 2. Intégration de campagne Le développeur définit deux informations principales : a. Les versions à intégrer : toutes les versions, seulement les versions validées, seulement la dernière version de chaque entité, etc. 1 GT n offre pas de connexion directe à un annuaire type LDAP pour deux raisons : 1. Cela empêcherait d intégrer dans une campagne des destinataires non inclus dans l annuaire 2. GT regroupe toutes les transactions de données d une instance dans un schéma de base unique. Autrement dit, l annuaire doit être une table ou une vue du schéma auquel GT est connecté. Gathering 6 Tools : architecture 6 /19

b. Pour chaque compartiment du formulaire, le développeur sélectionner une ou plusieurs tables de stockage dans la base client. Si les tables n existent pas, GT fournit le script SQL pour chaque compartiment. Chaque table peut être alimentée suivant différente modalités techniques (import par pivot, par axes clés ainsi que de nombreux modes avancés permettant de gérer tous les cas) 3. Restitution GT n est pas un outil d analyse mais il permet de rafraichir et de diffuser des classeurs Excel (.XLS ou.xlsx) suivant des modalités proches de celles des diffusions de campagnes. Cela permet notamment de diffuser des tableaux de bord au entités mais également de diffuser des matrices de saisie personnalisées. Pilotage / Workflow Les gestionnaires habilités en fonctions de leurs droits respectifs peuvent utiliser le module GTClient pour exécuter les actions créées par le développeur et piloter les campagnes. Le pilotage des campagnes recouvre les fonctionnalités suivantes : 1. Gestion des destinataires. Lors de l exécution d une action de campagne, le serveur présélectionne les destinataires en fonction des affectations définies par le développeur. Le gestionnaire peut amender cette sélection et n en retenant qu un sous-ensemble et /ou en réaffectant tout ou partie des destinataires afin, par exemple, de gérer les absences, le turnover, etc. Le gestionnaire peut à tout moment s affecter à lui-même tout ou partie des formulaires afin de se substituer aux destinataires. 2. Suivi des retours GTClient permet au gestionnaire de suivre, en fonction de ses droits, tout ou partie des entités et, pour chaque entité, de consulter les différentes versions. 3. Validation Lors de la visualisation des versions fournies par les entités, le gestionnaire peut, en fonction de ses droits, valider ou invalider tout ou partie de versions. Le gestionnaire peut commenter les raisons de son choix et les commentaires peuvent être renvoyés aux entités dans un mail accusant réception ou demandant une version corrective. La validation est optionnelle. 4. Intégration Lors du processus de collecte et de validation les données fournies par les entités ne sont pas stockées dans la base client mais dans la base GT (cf infra, Architecture) qui fait alors office de sas. Les données ne seront déversées dans la base client que lors de l exécution de l action d intégration. Il est à noter que toutes les actions dévolues au gestionnaire (sauf la validation) peuvent se voir automatiser grâce à un planificateur de tâches intégré à GT. Gathering 7 Tools : architecture 7 /19

Architecture Schéma d architecture Le schéma ci-dessous décrit l architecture technique de Gathering Tools, les modules à installer pour chaque rôle ainsi que les modalités de transactions entre eux. Description des modules GTAdmin permet à l administrateur de créer et gérer les instances. Pour chaque instance, il permet de : o Configurer l accès de l instance à la Base GT (repository, qui gère le fonctionnement interne de l application), Initialiser la base GT o Configurer l accès de l instance à la Base client (base de données qui supporte les transactions de données métier) o Créer les utilisateurs o Démarrer / Arrêter le service Serveur de l application o Gérer la sécurité Gathering 8 Tools : architecture 8 /19

GTServeur est le serveur de l application. Il permet : o D exécuter toutes les transactions sur la base de données client o De gérer les entrées / sorties de données entre la Base GT et les destinataires (envois de mails, collecte des données transmises par les destinataires, création de tableaux de bord) o De publier pour le module GTClient les statuts des différentes campagnes (répondants, versions de réponse, historique, etc.) Design permet aux développeurs de créer les formulaires et de mettre à jour les formulaires publiés sur le serveur GTClient permet aux développeurs et aux gestionnaires, suivant leurs droits respectifs, de : o Créer les modèles (stockage de modèles de formulaires et de tableaux de bord) o Créer les actions (lancement de campagne, intégration de données, diffusion de tableaux de bord) o Exécuter les actions o Consulter les statuts de campagnes (réponses, versions, historiques, etc.) o Communiquer auprès des destinataires (relances, demande de corrections, etc.) Answer permet aux destinataires d alimenter les formulaires en données puis de renvoyer ces dernières vers le serveur. Description des transactions Administrateur Serveur Création d utilisateurs 1. L administrateur lance le module GTClient et s authentifie sur une instance. 2. L administrateur créée les utilisateurs. Création de groupes d utilisateurs 1. L administrateur lance le module GTClient et s authentifie sur une instance. 2. L administrateur crée les groupes d utilisateurs en sélectionnant les fonctionnalités autorisées pour chaque groupe. 3. L administrateur spécifie, pour chaque modèle de formulaire ou de tableau de bord, une table/vue sur la base client permettant de filtrer les données autorisées pour chaque gestionnaire (les développeurs et administrateurs ont accès à tous les modèles et toutes les données sur une instance donnée). Administrateur Base GT Initialisation de la base GT 1. L administrateur lance le module GTAdmin et sélectionne (ou crée) une instance. 2. L administrateur initialise la base GT (toutes les données préalablement stockées y sont effacées) Gathering 9 Tools : architecture 9 /19

Développeur Serveur Conception de formulaires 1. Le développeur créée les formulaires à l aide du module Design. 2. Les formulaires (extension *.QST) sont sauvegardés sur un répertoire. 3. Le développeur lance le module GTClient et s authentifie sur une instance. 4. Le développeur charge les formulaires sur l instance. Mise à jour de formulaires 1. Le développeur lance le module Design et s authentifie sur une instance. 2. Le développeur télécharge une copie locale des formulaires. 3. Le développeur effectue les modifications souhaitées. 4. Le développeur met à jour les formulaires sur l instance. Conception / mise à jour de tableaux de bord 1. Le développeur lance le module GTClient et s authentifie sur une instance. 2. Le développeur charge les tableaux de bord (extension *.xls, *.xlsx) sur l instance. Conception d une action de lancement de campagne 1. Le développeur lance le module GTClient et s authentifie sur une instance. 2. Le développeur associe à un modèle de formulaire les tables/vues de la base client qui viendront alimenter le formulaire 3. Le développeur spécifie le mode de transaction pour la diffusion des formulaires et la transmission des réponses depuis le module Answer (http ou mail) Conception d une action d intégration de données 1. Le développeur lance le module GTClient et s authentifie sur une instance. 2. Le développeur associe à un modèle de formulaire les tables de la base client qui seront alimentées par les différents compartiments du formulaire. Conception d une action de diffusion de tableaux de bord 1. Le développeur lance le module GTClient et s authentifie sur une instance. 2. Le développeur associe à un modèle de tableau de bord les tables/vues de la base client qui viendront alimenter le tableau de bord 3. Le développeur spécifie le mode de transaction pour la diffusion des tableaux de bord (diffusion par mail ou dépose des fichiers sur une arborescence de dossiers) Gestionnaire - Serveur Exécution d une action 1. Le gestionnaire demande l exécution de l action 2. La demande est ajoutée à la pile de l instance 3. La demande est traitée aussitôt qu elle arrive en bas de la pile. Note En cas d arrêt du serveur. La pile n est pas mémorisée. Lors du redémarrage du serveur, les actions non exécutée lors de l arrêt sont perdues. Gathering 10 Tools : architecture 10 /19

Serveur Base de données client Le serveur se connecte à la base client à l aide des paramètres fournis par l administrateur et stockés dans la base GT d une instance donnée. Destinataire - Serveur 1. Le destinataire ouvre son formulaire à l aide du module Answer 2. Si le développeur a spécifié un renvoi des données par messagerie : a. Le module Answer détecte les protocoles de messagerie disponibles sur le poste utilisateur b. Le module Answer initialise la transaction sur le protocole sélectionné. Au besoin, un mot de passe est demandé à l utilisateur c. Answer génère un mail contenant le fichier de données en pièce attachée et l envoie au compte de messagerie associé à l instance 3. Si le développeur a spécifié une vérification de mise à jour d Answer: a. Le module Answer se connecte au serveur (http) b. le module Answer vérifie auprès du serveur que la version du module Answer est la plus à jour c. Le cas échéant, la session d Answer est quittée, le nouveau setup du module Answer est téléchargé puis exécuté 4. Si le développeur a spécifié une vérification de mise à jour du formulaire : a. Le module Answer se connecte au serveur (http) b. le module Answer vérifie auprès du serveur que la version du formulaire est la plus à jour c. Le cas échéant, la session d Answer est quittée, le nouveau formulaire est téléchargé puis ouvert. 5. Le destinataire alimente le formulaire en données (par saisie et/ou import depuis Excel / Calc) 6. Le destinataire clique sur le bouton de transmission des données 7. Le module Answer extrait du formulaire les données à transmettre sous forme d un fichier binaire. 8. Si le développeur a spécifié un renvoi des données en http : a. Le module Answer se connecte au serveur (http) b. Le module Answer vérifie que le formulaire est toujours valide et télécharge la dernière version du formulaire le cas échéant c. Le module Answer vérifie que la campagne à laquelle appartient le formulaire est toujours valide et interdit la transmission des données le cas échéant. d. Le module Answer transmet le fichier de données au serveur e. Le serveur transfère les données dans le compte mail associé à l instance 9. Périodiquement, ou à la demande d un gestionnaire / développeur / administrateur, le serveur effectue un polling sur le compte de messagerie dédié à l instance. 10. Les données collectées sur le compte de messagerie sont intégrées à la base GT 11. Le serveur met à jour les statuts des campagnes. Gathering 11 Tools : architecture 11 /19

Droits nécessaires sur les bases de données Base GT La base GT n est accédée que par le serveur. Lors de l initialisation de la base par l administrateur, il est nécessaire d avoir les droits de suppression de tables et de données et de suppression / création de contraintes. A l exécution, seuls les droits de lecture/écriture sont requis. Base client En phase de développement, le développeur aura besoin d un accès direct à la base via un client dédié. A l exécution, le serveur ne créée ni ne supprime de tables à l exception de tables temporaires utilisées pour les actions d intégration de données. Lorsque le développeur est amené à créer des tables de stockage pour intégrer les données des différents compartiments des formulaires, GTClient lui fournira le script SQL approprié : il appartient au développeur de recopier et exécuter ce script dans son client d accès à la base de données. Gathering 12 Tools : architecture 12 /19

Sécurité Authentification des accès Modules concernés Module GTAdmin GTAdmin est installé sur le serveur et ne peut être exécuté que localement. L accès à GTAdmin n est pas authentifié. Module Design Le module Design est exécuté localement mais peut être connecté au serveur à la demande du développeur pour les opérations d import et de mise à jour des formulaires sur une instance. La connexion est alors authentifiée, cf supra. Module GTClient L utilisation du module GTClient nécessite une connexion au serveur pour toutes les opérations. Module Answer Le module Answer est exécuté localement. L accès à Answer n est pas authentifié mais une authentification peut être réalisée au niveau des formulaires, cf supra Fonctionnement de l authentification pour l accès aux modules Design et GTClient Lors d une tentative de connexion, le serveur interroge la liste des comptes localisée dans une table de la base GT. Cette table contient les identifiants et les hash des mots de passes (SHA-1) mais pas les mots de passe en clair. Sécurisation des transactions par messagerie Les transactions par messagerie (diffusion des formulaires et des tableaux de bord, transmission des réponses le cas échéant) peuvent être sécurisées en utilisant SSL sur les protocoles POP/SMTP Utilisation de certificats pour l authentification et le cryptage - PKI Gathering Tools peut fonctionner au sein d une infrastructure à clés publiques (ICP / PKI) et/ou permettre l utilisation de certificats pour authentifier et crypter certaines transactions. Gathering Tools ne fournit pas d infrastructure de gestion de clés. Il appartient au client de se doter d une telle infrastructure et / ou d acquérir les certificats nécessaires. Gathering Tools gère les certificats répondant à la norme X.509 au format *.p12 et *.pfx. Gathering 13 Tools : architecture 13 /19

Paramétrage Dans GTAdmin, l administrateur fournit, pour une instance donnée, le certificat et le protocole de chiffrement éventuel. 2003 2014 Calame Software S.A.S Dans GTClient, il est précisé les paramètres de connexion à l instance (identiques à ceux fournis dans GTAdmin). Par défaut, GTClient vérifiera que le nom du serveur est identique au nom exposé dans le certificat (propriété «Common Name» (CN) du sujet du certificat) mais il est possible d autoriser la connexion à un serveur dont le nom serait différent. Il est également possible de spécifier un certificat client au niveau de GTClient Gathering 14 Tools : architecture 14 /19

Fonctionnalités L utilisation de certificats permet de gérer les fonctionnalités suivantes : Fonctionnalité Authentification du serveur par GTClient Authentification de l utilisateur de GTClient par le serveur Cryptage de la communication entre GTClient et le serveur Cryptage des données transmises par Answer Affichage dans le module concerné Exemple de libellé Gathering 15 Tools : architecture 15 /19

Validation des adresses mail des répondants. L identité des destinataires n est techniquement pas nécessaire au fonctionnement des campagnes de collecte. En effet, lors de la diffusion des formulaires, GTServer inscrit dans chaque formulaire une clé d identification de l entité en charge du formulaire et cette clé est renvoyée dans la réponse, permettant au serveur d affecter les données collectées. Ce mode de fonctionnement permet de collecter l information en permettant aux destinataires connus de déléguer la saisie des données à n importe quel individu. Néanmoins, il est possible de collecter l identité des répondants afin d utiliser cette identité à des fins de communication ou de sécurité. Pour cela les utilisateurs du module Answer doivent configurer une adresse mail valide. Le fonctionnement de la validation est le suivant : 1. Le développeur du modèle de formulaire spécifie dans GTClient que les destinataires devront valider leur adresse mail 2. Lorsque les destinataires effectueront une tentative de transmission, si aucune adresse mail n est validée au niveau du module Answer, il leur est alors proposé de saisir leur adresse mail. 3. Le module Answer envoie alors un mail à l adresse indiquée (en utilisant le protocole de messagerie configuré ou, le cas échéant, en utilisant la connectivité http pour demander à GTServer d envoyer le mail). 4. Le mail de validation contient une pièce jointe dont l extension (*.checkmail) est associée à Answer. Lorsque l utilisateur ouvre cette pièce jointe, le module Answer valide l adresse mail, qui est alors enregistrée dans une clé du registre Adresse mail validée dans Answer HKEY_CURRENT_USER de manière encryptée (RC4). L adresse mail validée permet notamment : De distinguer les correspondants (destinataires initiaux, connus du développeur) des répondants (qui répondent effectivement après avoir reçu le QST du correspondant) et d adapter la communication : par exemple, en routant toute ou partie des mails (relances, validation, etc.) vers les répondants et pas les correspondants suivant le paramétrage effectué par le développeur. De faire en sorte que le comportement du formulaire s adapte en fonction de l individu qui l utilise. En effet, l adresse validée peut être utilisée dans les formules de calcul du formulaire. Il est par exemple possible de définir que le correspondant à tous les droits sur le qst, mais que les répondants ne puissent accéder qu à une partie seulement du qst et ne puissent pas transmettre la réponse (ils doivent dans ce cas renvoyer le qst au correspondant). Il est même possible de déléguer au correspondant la désignation des répondants et de leurs droits. Gathering 16 Tools : architecture 16 /19

Automatisation Il est possible d automatiser l ensemble des commandes passées à GTServer. A cet effet, un assembly.net est installée sur le serveur. Cet assembly est compilé pour le framework.net 3.5 et peut être appelé : depuis le PowerShell (version 2) depuis n importe quel programme.net Tous les objets de l assembly sont dans le namespace Calame.Automation. Les commandes sont passées à GTServer via des classes nommées CmdXXXX. Il en existe deux types : Les commandes d exécution d action qui héritent de la classe CmdExecuteAction Les autres sont des classes statiques (ex. : CmdDoPolling) Dans les deux cas, l exécution se fait via la méthode Execute dont les paramètres et le type de retour diffèrent selon la commande. Cette méthode passe toujours au moins en paramètre les informations de connexion à l instance. Gathering 17 Tools : architecture 17 /19

Prérequis techniques Le tableau ci-dessous liste les prérequis techniques pour l installation de Gathering Tools. Légende Sans objet Supporté Non supporté Sans objet Aucun droit requis Ø OS supportés Windows Server 08 Windows 7 Windows Vista Windows XP Windows 2000 Design Answer GT Server GT Client GT Admin Droits nécessaires à l'installation Fichiers Base de registres Services Design Answer GT Server GT Client GT Admin Ecrire dans le répertoire d'installation Ecrire dans Ecrire dans "HK_Local_Machine" "HK_Local_Machin Ø e" Ø Ø Installer / Démarrer / Installer / Démarrer / Ø Arrêter les services Arrêter les services Protocoles de messagerie supportés Design Answer GT Server Envoi Recept. GT Client GT Admin POP (*) Sans objet Sans objet SMTP (*) Sans objet IMAP (*) Sans objet Sans objet Sans objet Sans objet Sans objet MAPI Notes (*) avec Support SSL Clients de messagerie supportés (module Answer) Auto-detecté Protocole(s) Widows Live Mail Oui SMTP Outlook Express Oui SMTP Windows Mail Oui SMTP Microsoft Outlook (32 bits) Oui Outlook, SMTP Microsoft Outlook (64 bits) Oui SMTP Lotus Notes Oui Notes Thunderbird (2 mini) Oui SMTP Opera (9.5 mini) Oui SMTP Novell GroupWise Oui GroupWise FoxMail Non SMTP Note : pour les utilisateurs du module Answer ne disposant pas d'un client de messagerie compatible (par exemple, les utilisateurs de webmail tels que Gmail, Hotmail ou autre), le module Answer peut également transmettre les données fournies par l'utilisateur en utilisant le protocole HTTP. Gathering 18 Tools : architecture 18 /19

Role Modules Space GT Server GT Admin Design GT Client Destinataire Answer 20 Mo Gestionnaire GT Client 20 Mo 2003 2014 Calame Software S.A.S Espace disque requis Ram minimum (Mo) Commentaires Serveur 10 Go Taille maximale occupée Développeur 1 Go Taille maximale occupée Design Answer GT Server GT Client GT Admin 1024 512 4096 1024 512 Besoins généraux GTServer 1 compte de messagerie accessible via SMTP pour l'envoi des mails 1 compte de messagerie accessible via POP/IMAP (de préférence le même compte que celui pour l'envoi via SMTP) OU 1 compte de messagerie Notes ou Exchange avec un client Notes ou Outlook 32 bits installé sur le serveur (de préférence le même compte que celui pour l'envoi via SMTP) OU 1 accès au serveur GTWeb (si les réponses Answer sont envoyées par http) 1 schéma de base de données pour la base client (base ouverte), ce schéma doit être différent de celui de la base GT 1 schéma de base de données pour la base GT (base propriétaire), ce schéma doit être différent de celui de la base client Microsoft Excel installé sur le serveur si des restitutions doivent être générées par la suite GT Bases de données supportées Bande passante recommandée Base Versions SqlServer 2005, 2008 Oracle<ref>Client Oracle (ODAC)11G 10G, requis</ref> 11G PostGreSQL 8 et + DB2 9 Solution centralisée Solution distribuée 3 MB/s Latence <= 100ms 1,5 MB/s Latence <= 100ms Modules complémentaires requis Module Fonctionnalité Module complémentaire Version mini. Design Import Excel Microsoft Excel 2000 Answer Import Excel Microsoft Excel 97 Import Calc OpenOffice Calc 2.4 Restitutions Excel Microsoft Excel 2000 Toutes Microsoft.NET Framework 3.5 SP1 GT Server PHP 5.3 Serveur Web IIS 5 ou Apache 2.2 Gathering 19 Tools : architecture 19 /19