On peut vous aider ?
Cherchez des réponses ou parcourez les rubriques de notre documentation
Lancement de collecte
Principe
Une action de type « Lancement de collecte » permet, lors de son exécution, de publier des questionnaires dérivés d’un modèle de collecte.
Si la campagne (identifiée par un modèle de questionnaire et une date d’arrêté) n’existe pas, elle sera créée. Sinon, de nouveaux questionnaires seront publiés pour cette campagne.
Diffusion
Le paramétrage de la diffusion détermine en particulier les entités de destination et les correspondants affectés.
- Carnet d’adresses : Table / vue fournissant la liste des destinataires potentiels des questionnaires. Techniquement, un seul champ contenant l’adresse mail des destinataires est requis. D’autres champs identifiant peuvent être utiles pour enrichir le noyau.
- Axe email : le champ du carnet d’adresses portant les adresses mail des correspondants.
- Relation d’affectation : Table / vue définissant la relation d’affectation.
- Axe de liaison : champ de la relation d’affectation permettant de réaliser la jointure avec le carnet d’adresses.
- Axes de diffusion : Sélectionnez, parmi les champs présents dans la relation d’affectation, ceux définissant les axes de diffusion. Chaque combinaison unique des items d’axes de diffusion constituera une entité (voir aussi la liste des Types d’axes).
- Axes de validation supplémentaires : Les axes de validation supplémentaires sont des champs du compartiment racine permettant, pour chaque entité, d’autoriser autant de versions valides que l’entité aura défini d’items d’axes de validation supplémentaires.
- Axes de visualisation : Sélectionnez, parmi les champs présents dans la racine du questionnaire, ceux définissant les axes de visualisation. Les valeurs de ces composants sont affichés dans la visualisation des réponses à une campagne. Seuls les composants ayant un format texte sont acceptés. Les axes de visualisation permettent d’afficher un résumé de la réponse directement dans le fil de discussion ainsi que dans la page des réponses et de résoudre en partie certains problèmes de workflows informels.
- Nom du questionnaire : Nom de fichier publié. Par défaut, le nom est celui du modèle mais il vous est possible de le personnaliser avec les variables système, les champs du noyau et ceux du compartiment racine du formulaire.
- Table de date d’arrêté : Table / vue contenant la date d’arrêté à utiliser pour cette campagne.
- Colonne source : champ de la table/vue contenant la valeur à utiliser comme date d’arrêté. Ce champ doit être un champ date. Si la table/vue contient plusieurs enregistrements, seul le premier est pris en compte.
- Erreurs de personnalisation bloquantes. Si cette case est cochée, toute erreur dans l’alimentation en données de la campagne bloquera le lancement de cette dernière.
- Cette action n’est pas exécutable. . Si cette case est cochée, l’action ne pourra être exécutée, ni manuellement, ni par l’automatisation). Cette option est utile pour les actions destinées à alimenter une synchronisation. Elle permet que, lors de la synchronisation, les données sources soient différentes des données utilisées par l’action de lancement (par exemple, l’action de lancement peut utiliser un jeu de données restreint pour accélérer la publication, mais la synchronisation utilisera le jeu de données complet).
Données
Cet onglet vous permet de spécifier l’alimentation en données du formulaire. Au moins un compartiment et au moins un champ du formulaire doivent être alimentés en données.
Pour chaque compartiment vous pouvez spécifier une table/vue d’alimentation et un tri.
Dans cet exemple, le compartiment racine est alimenté par la vue « HR_DEMOS_Sites_Flags ». Seuls 2 des 3 champs de la vue sont utilisés. En revanche, pour le compartiment « Newcomers », la totalité (15/15) des champs de la table « HR_DEMO_Newcomers » est utilisée. L’icône sur fond jaune indique un tri des données.
Messages du modèle
Cet onglet liste les messages du modèle dont est issu la campagne. Vous pouvez les modifier et il est généralement préférable d’éditer les messages depuis cette fenêtre plutôt que lors de l’édition du modèle. En effet, vous pouvez ici disposer des variables issues du noyau ainsi que du compartiment racine.
Vous pouvez également référencer les valeurs reçues dans les réponses aux questionnaires (au lieu des valeurs envoyées) en préfixant l’axe/en-tête par un #.
Exemple, dans un message d’accusé de réception, [[Commentaire]] sera substitué par la valeur du composant Commentaire de la racine du questionnaire au moment de l’envoi, tandis que [[#Commentaire]] sera substitué par la réponse au composant Commentaire fournie par le correspondant.
Les variables système sont également utilisables
Publication
- Vérification HTTP : Si cette case est cochée, le document se connectera au serveur web de GTServer pour vérifier :
- Que la campagne est toujours active (ni fermée, ni supprimée)
- Que le questionnaire n’a pas été fermé pour l’entité à laquelle il est rattaché
- Qu’une nouvelle version du questionnaire n’a pas été envoyée.
Si la vérification HTTP n’a pu être effectuée (par exemple s’il n’est pas possible d’accéder à l’url de GTWeb), le questionnaire ne peut pas être ouvert.
- Diffusion HTTP : Si cette case est cochée, la variable PUBLISH_URL est résolue et aucune pièce jointe n’est ajoutée au mail. Dans le cas contraire, la variable n’est pas résolue et le formulaire est fourni en pièce jointe.
Le lien substitué à la variable PUBLISH_URL pointe toujours sur la dernière version du questionnaire envoyé pour l’adresse mail et les items des axes de diffusion : si un questionnaire a de nouveau été envoyé pour cette entité, le correspondant exploitant l’url du premier message chargera la dernière version du questionnaire si le questionnaire a été envoyé pour la même adresse mail.
- Réponse HTTP : Si cette case est cochée, les données du formulaires seront renvoyées à GTServer en utilisant le canal HTTP, dans le cas contraire, les données seront renvoyées en utilisant le canal de la messagerie : GTAnswer détectera le protocole de messagerie disponible sur le poste, générera un mail contenant les données du formulaire en pièce jointe sous forme d’un fichier compressé et enverra ce mail à l’adresse de consolidation spécifiée dans le paramétrage de l’instance.
- Réponse HTTP : Envoyer par mail si la réponse échoue : GTAnswer essaye de transférer la réponse par HTTP, si celle-ci ne peut aboutir (si l’url ne peut être accessible à partir du poste GTAnswer), GTAnswer essaye d’envoyer la réponse par mail.
- Synchronisation descendante des motifs inertes : Permet d’effectuer une Synchronisation à partir de GTAnswer. Le concepteur peut choisir si la liste des motifs à synchroniser est définie par l’action de lancement courante ou par une autre action de lancement (qui ne pourra être utilisée que pour la synchronisation au besoin).
- Autoriser la synchronisation complète : permet de synchroniser l’ensemble des compartiments (à l’exception du multi-onglets) et active l’assistant de résolution de conflits pour les utilisateurs.
Le concepteur peut demander à ce qu’une synchronisation soit effectuée à l’ouverture du questionnaire dans GTAnswer et imposer qu’une synchronisation soit effectuée avant la transmission de la réponse (dans ce dernier cas, la transmission de la réponse ne pourra avoir lieu si la synchronisation préalable a échoué).
Authentification
Cet onglet liste les différentes options possibles d’authentification des répondants via Active Directory (AD) pour les utilisateurs ne disposant pas de compte.
- Pas d’authentification : Aucune authentification requise.
- Active Directory : authentification du compte utilisateur qui ouvre le document : A l’ouverture du document, GTAnswer va demander le mot de passe de l’utilisateur qui est connecté sur la session active via l’AD.
- Active Directory : authentification du compte utilisateur qui ouvre le document et vérification que son adresse mail est bien celle du correspondant : A l’ouverture du document, GTAnswer va demander le mot de passe de l’utilisateur qui est connecté sur la session active via l’AD . Puis GTAnswer vérifie que le mail inscrit dans l’AD pour l’utilisateur est le même que celui du destinataire inscrit par GTServer au lancement de la campagne. Cette option ne permet pas le transfert du questionnaire à une tierce personne.
- Active Directory : seul le compte utilisateur associé à l’adresse mail du correspondant pourra ouvrir le document : GTAnswer va demander le mot de passe du nom d’utilisateur qui correspond au mail inscrit par GTServer et va utiliser ce compte pour l’authentification. Cette option ne permet pas le transfert du questionnaire à une tierce personne, sauf si cette personne connaît le mot de passe du compte de l’AD associé au mail du destinataire initial (par exemple dans le cas d’une adresse générique et d’un compte générique).
Dans les deux derniers cas, c’est l’adresse mail utilisée effectivement par GTServer pour envoyer le mail qui est utilisée comme référence pour vérification dans l’AD.
Si les questionnaires ont été redirigés, c’est l’adresse de redirection qui sera vérifiée dans l’AD.
Si l’adresse d’expédition est une liste d’adresses séparées par des virgules ou points-virgules, c’est cette chaîne de caractère qui sera vérifiée dans l’AD.
En cas d’erreur à l’exécution
Ce paragraphe récapitule certains tests à effectuer pour s’assurer du bon fonctionnement de l’action de lancement.
Il ne concerne que les problèmes de données alimentant le questionnaire.
Dans tous les cas, comme pour tous les types d’actions (lancement, intégration, restitution), l’action peut être copiée (clic droit puis « Dupliquer l’action ») afin de pouvoir effectuer des modifications sur la copie (en général pour simplifier l’action) de façon à repérer plus facilement les causes de dysfonctionnement.
Consultez les détails des messages d’erreur affichés.
L’action de lancement ne s’exécute pas
- Si des modifications de champ, etc.. ont eu lieu depuis la dernière modification de l’action de lancement. Editez une copie de l’action de lancement et vérifiez que vous pouvez valider une modification minime de cette action.
- En cas d’erreur lors de la transposition, la consultation des fichiers temporaires peut aider au diagnostic de cette erreur. Consultez le point correspondant dans le paragraphe suivant.
- Si les mails ne partent pas pour des soucis de connexion de GTServer au SGBD ou de GTServer au serveur de messagerie, consulter le paragraphe des connexions de l’article Erreurs.
- Vérifiez que chacune des tables/vues pointée par l’action de lancement est opérationnelle dans le SGBD (l’exécution d’un SELECT sur chaque table ne doit pas remonter d’erreur mais peut cependant ne renvoyer aucune donnée).
- Si un multi-onglet est utilisé, le compartiment du multi-onglet (ou l’un de ses fils) doit être associé à une table contenant l’axe de multi-onglet. Cet axe de multi-onglet ne doit pas contenir de données NULL.
- Vérifiez le typage des champs qui sont utilisés dans les jointures : axe de liaison avec le carnet d’adresse, axes de diffusion. Ces champs doivent avoir des types compatibles (pour des critères d’égalité) entre les deux tables.
- Vérifiez que les clés des motifs sont respectées dans les données approvisionnant ces motifs.
- Si un timeout apparaît lors de l’exécution des phrases SQL par GTServer, vous pouvez modifier la valeur du timeout pour l’attente d’exécution en client-serveur des commandes SQL. Inscrivez une valeur en secondes dans la base de registre sur le serveur GT Server dans la clé HKLM\SOFTWARE\Calame\GTServer\CommandTimeout (par défaut, cette valeur est à 600 secondes soit 10 minutes). Il est néanmoins toujours préférable de procéder au préalable à des optimisations en ajoutant des index sur les tables , en construisant des vues indexées, des précalculs dans des tables etc, ou en limitant la volumétrie des données.
L’action de lancement s’exécute mais le questionnaire ne contient pas les données attendues
- Exécutez l’action en mode diagnostic
- Exécutez l’action en prévisualisant les données, puis sans fermer la boîte de prévisualisation, allez consulter les fichiers de données produits (.csv) dans le sous-répertoire le plus récent du répertoire temporaire de GT (ce répertoire peut être partagé en lecture seule sur le serveur). Tous les fichiers temporaires ouverts à des fins de diagnostics doivent être fermés après examen et ne doivent pas être modifiés.
- Enlevez toutes les associations de tables/vues à des compartiments sauf le compartiment dont les données sont incorrectes. Exécutez l’action modifiée. Parmi les tables/vues précédemment enlevées, ajoutez seulement les tables/vues associées aux compartiments parents du compartiment aux données incorrectes puis ré exécutez l’action modifiée.
- Si vous avez un souci d’approvisionnement d’une transposition, vérifiez les fichiers temporaires produits en prévisualisation (voir plus haut). Supprimez tous les champs de la table/vue qui ne sont ni des champs des compartiments parents de la transposition ni des champs déclarés dans la définition de la transposition. Cette dernière préconisation exclue le cas où une transposition dans un motif absorbe tous les champs d’un motif : dans ce cas, la table/vue doit doubler tous les champs clés du motif, utiliser éventuellement des champs des compartiments parents et exclure les autres champs (cf Motif et transposition).
- Des interactions entre compartiments peuvent avoir lieu. Les lignes d’un motif ou les onglets d’un multi-onglet sont déterminés par une seule des tables/vues dans le motif ou le multi-onglet : c’est en règle générale la table à la racine du compartiment ou, si celle-ci est absente, la première table associée à un compartiment-fis dans l’ordre alphabétique des compartiments (cf Assemblage des données).
- Les champs du noyau ont priorité sur les autres champ : si un champ est présent dans le carnet d’adresse ou la relation d’affectation, seules les valeurs de ce champ seront prises en compte, tout champ portant le même nom et appartenant à une table/vue associée à un compartiment du qst sera simplement ignoré (cf Assemblage des données).
- Dans le cas d’un motif avec une transposition, vérifiez que vous n’êtes pas dans les cas d’utilisations incorrectes décrits par l’article Motif et transposition
- Si des problèmes de performance se posent, essayez d’exécuter un SELECT dans le SGBD sur chacune des tables/vues. Si le SELECT dans le SGBD pose des problèmes de performance, l’accès à ces mêmes données par GTServer risque d’en poser également. Si le SELECT ne pose pas de problèmes de performance, configurez l’instance pour visualiser les phrases SQL envoyées et testez les phrases SQL envoyées et adaptées pour l’entité concernée.