{:fr}

Principe

Pour un modèle de campagne donné, les compartiments de formulaires correspondant aux versions paramétrées pour être intégrées vont mettre à jour les tables de stockages.

Réponses

Vous pouvez sélectionner les versions de réponses collectées en fonction de leur statut de validation et/ou de leur ordre de collecte.

• Statut de validation : Vous pouvez choisir de n’intégrer :
  • que les réponses validées
  • que les réponses invalidées
  • toutes les réponses quel que soit leur statut de validation
  • toutes les réponses sauf les réponses validées
  • toutes les réponses sauf les réponses invalidées
  • toutes les réponses sauf les réponses en attente de validation

• Sélection des réponses : Vous pouvez choisir parmi les options suivantes :
  • Toutes les réponses
  • Dernières par combinaison d’axes de validation : pour chaque entité, seule sera intégrée la dernière version par combinaison d’axes de diffusion et, le cas échéant, d’axes de validation supplémentaires (cf Types d’axes pour un rappel des différents types d’axes).
  • Dernières par combinaison d’axes personnalisée : pour chaque entité, seule sera intégrée la dernière version en fonction des axes présents dans le formulaire. Définissez ces axes en cliquant sur le bouton « … » et en sélectionnant les axes voulus.

• Table de date d’arrêté : Table / vue contenant la date d’arrêté à utiliser pour sélectionner la 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.

• Colonnes à rajouter dans l’export : vous pouvez sélectionner une série de champs qui seront ajoutés dans les données à intégrer. Pour chaque champ coché, saisissez un nom de champ pour recevoir la valeur. Attention, les champs sélectionnés n’apparaîtront pas dans les scripts SQL des compartiments.
  Voici la liste des champs pouvant être ajoutés :
  • Version de GTAnswer
  • Date heure d’envoi de la réponse
  • Date heure de réception de la réponse
  • Statut de validation (0 = En attente, 1 = Validé, 2 = Invalidé)
  • Commentaire de validation
  • Date heure de validation
  • Valideur, Date arrêté
  • Utilisateur OS
  • Domaine OS
  • Version OS
  • Email du répondant
  • Date heure d’intégration
  • Mode d’envoi de la réponse.

• Intégrer aussi les questionnaires envoyés sans réponses : Cette option permet d’intégrer les questionnaires auxquels les destinataires n’ont pas répondu. Cette option permet de profiter des contrôles de cohérence du questionnaire sir les données personnalisées, sans renvoyer de réponse.

• Intégration différentielle : si cette case est cochée, seules les entités ayant reçu de nouvelles réponses depuis la dernière intégration seront intégrées. Le statut de validation n’est pas pris en compte.

Données

Pour chaque compartiment du formulaire, vous pouvez sélectionner une ou plusieurs tables pour recevoir les données collectées.

Si vous souhaitez créer rapidement une table de stockage, vous pouvez afficher le script SQL de création de table contenant tous les champs du compartiment en effectuant un clic droit sur le compartiment puis, dans le menu contextuel, en sélectionnant l’élément « Script SQL du compartiment ».
Note : le script SQL est une aide à la création des champs mais n’a pas pour but de réaliser une table exploitable :

• le script fournit pour chaque champ un type détecté automatiquement en fonction des contraintes apposées au composant lors de la création du formulaire. Cependant, et notamment pour les champs issus d’une transposition et pouvant donc « croiser » différents composants, le type résultant peut ne pas être optimisé.
• le script ne générera pas de clé primaire ni aucune autre fonctionnalité de gestion d’intégrité.

Pièces jointes

Les pièces jointes collectées via des pièces jointes ascendantes ne sont pas intégrés dans les tables de stockage sous forme de BLOB : elles sont exportées vers un chemin réseau et la table de stockage recevra un champ contenant le nom de fichier complet ainsi que le répertoire dans lequel la pièce jointe collectée sera exportée.

Par défaut, les pièces jointes sont exportées dans une série de sous-répertoires contenant la date et le numéro de version, permettant de ne jamais écraser les fichiers exportés, mais vous pouvez spécifier le répertoire d’extraction. De façon optionnelle, vous pouvez également demander :

• la création d’un sous-répertoire contenant le nom de l’action
• la création d’un sous-répertoire contenant la date d’arrêté
• la purge du répertoire avant l’intégration.

En cas d’erreur à l’exécution

Ce paragraphe liste quelques méthodes permettant d’identifier la cause de la plupart des messages d’erreurs de GTServer lors de l’intégration.

Dans tous les cas, comme pour tous les types d’actions (lancement, intégration, restitution), l’action peut être copiée (bouton « Crééer une copie » dans GTClient) 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 dans GTClient

• Dans les tests de l’action d’intégration, effectuez toujours des tests avec au moins deux entités et vérifiez que l’action d’intégration puisse s’exécuter deux fois pour la même campagne, en intégrant au moins une réponse différente (nouvelle réponse).

• De manière générale lorsqu’une contrainte de la table d’accueil n’est pas respectée, construisez une copie de cette table en ne spécifiant aucune contrainte voire en modifiant les types des champs pour en donner de plus permissifs.

• Si une vue intermédiaire d’intégration est utilisée, créez une action d’intégration intégrant les données directement dans la table intermédiaire d’intégration (considérée comme table de destination finale pour cette action), quitte à purger la table au préalable et à mettre des champs pivots bidon : de cette façon, vous pourrez analyser les données de la vue intermédiaire d’intégration. Pour cela, copiez l’action d’intégration et pour les compartiments posant problème, spécifiez comme table finale la table intermédiaire d’intégration et n’utilisez plus ni table intermédiaire d’intégration ni vue intermédiaire d’intégration pour ces compartiments.

• Si une erreur s’est produite lors de l’intégration, et si l’erreur provient de l’insertion des données par GTServer dans la première table (que celle-ci soit la table intermédiaire d’intégration ou la table créée par GTServer créée à partir de la table finale d’accueil des données), les données sont dumpées par GTServer dans des fichiers CSV dans un sous-répertoire du répertoire de l’instance accueillant les fichiers temporaires. Si vous êtes amenés à ouvrir ces fichiers, pensez à les fermer avant de valider la boîte de visualisation de l’erreur. Enfin, en ouvrant des csv avec Excel, celui-ci va réinterpréter certaines données (modifier un 01 en 1, etc…)

• De façon à restreindre la volumétrie des données à intégrer pour affiner le diagnostic de manière confortable, vous pouvez éditer l’action d’intégration pour ne prendre en compte que les données validées, puis parmi les réponses, limitez-vous à ne validez que l’entité dont les données posent problème à l’intégration.

• Si des modifications de champ, etc.. ont eu lieu depuis la dernière modification de l’action de lancement, éditez une copie de l’action de lancement et vérifiez que vous pouvez valider cette action (certaines vérifications de cohérence seront effectuées par GTServer à la validation). vérifiez notamment dans une mise à jour sur champs clés que tous les champs à mettre à jour sont effectivement sélectionnés.

• Si la connexion à la base de donnée ne peut être effectuée, consulter le paragraphe des connexions de l’article Erreurs.

• Vérifiez l’ordre d’intégration des compartiments dans les tables (numéro à droite de l’association compartiment-table). Celui-ci doit respecter les contraintes d’intégrité référentielle inscrites dans les tables.

• Si des problèmes de performance se posent, essayez d’abord d’intégrer les données dans une table vide (quitte à utiliser l’option « Purger les données » de l’action d’intégration). Ajoutez des index (au mieux uniques) portant sur les champs pivots ou les champs clés. Des index couvrants peuvent également être utile notamment dans le cas de la mise à jour sur champs clés. Puis réessayez d’intégrer les données dans la table finale. Vous pouvez également déposer les données dans une table vide, puis alimenter la table finale au moyen d’une procédure stockée.

• 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 via l’option de l’action d’intégration. Il est néanmoins toujours préférable de procéder au préalable à des optimisations en ajoutant des index sur les tables sources ou les tables de destination, en construisant des vues indexées etc, ou en limitant la volumétrie des données.

{:}{:en}

Principle

For a given campaign template, the compartments of the forms corresponding to the versions set up to be integrated will update the storage tables.

Responses

You can select the versions of responses collected according to their validation status and/or their collection order.

• Validation status: You can choose to integrate :
  • only validated responses
  • only invalidated responses
  • all responses regardless of their validation status
  • all responses except validated responses
  • all responses except invalidated responses
  • all responses except responses awaiting validation
• Response selection: You can choose from the following options:
  • All responses
  • Latest by combination of validation axis: for each entity, only the latest version by combination of diffusion axis and, if necessary, additional validation axis will be integrated (see Types of axis for a reminder of the different types of axis).
  • Latest by customised axis combination: for each entity, only the latest version will be integrated according to the axis present in the form. Define these axis by clicking on the « … » button and selecting the desired axis.
• Statement date table : Table / view containing the Statement date to be used to select the campaign.
  • Source column: Table/view field containing the value to be used as Statement date. This field must be a date field. If the table/view contains several records, only the first one is taken into account.
• Columns to be added to the export: you can select a series of fields that will be added to the data to be integrated. For each checked field, enter a field name to receive the value. Note that the selected fields will not appear in the SQL scripts of the compartments.

Here is the list of fields that can be added:

• • GTAnswer version
  • Date time the response was sent
  • Date time the response was received
  • Validation status (0 = Pending, 1 = Validated, 2 = Invalidated)
  • Validation comment
  • Validation date time
  • Validator, Statement DateOS User
  • OS domain
  • OS version
  • Respondent’s email
  • Date time of integration
  • Method of sending the response.
• Also include questionnaires sent without responses: This option permits the inclusion of questionnaires to which the recipients have not responded. It allows you to take advantage of the questionnaire’s consistency checks on personalised data, without sending back a response.
• Differential integration: If this box is checked, only entities that have received new responses since the last integration will be integrated. The validation status is not taken into account.

Data

For each compartment of the form, you can select one or more tables to receive the collected data.

If you want to quickly create a storage table, you can display the SQL script for creating the table containing all the fields in the compartment by right-clicking on the compartment and then selecting the « Compartment SQL Script » item from the pop-up menu.

Note: the SQL script is an aid to creating fields but is not intended to create a usable table:

• the script provides an automatically detected type for each field based on the constraints applied to the component when the form was created. However, and particularly for fields resulting from a transposition and which may, therefore, « cross » different components, the resulting type may not be optimised.
• the script will not generate a primary key or any other integrity management functionality.

Attachments

Attachments collected via ascending attachments are not integrated into the storage tables as BLOBs: they are exported to a network path and the storage table will receive a field containing the full filename and the directory to which the collected attachment will be exported.

By default, attachments are exported to a series of subdirectories containing the date and version number, such The exported files are never overwritten, but you can specify the extraction directory. Optionally, you can also request :

• the creation of a sub-directory containing the name of the action
• the creation of a sub-directory containing the Statement date
• the purging of the directory before the integration.

In case of an error at runtime

This paragraph lists some methods to identify the cause of most GTServer error messages during integration.

In all cases, as for all types of actions (launch, integration, rendering), the action can be copied (button « Create a copy » in GTClient) in order to be able to make modifications on the copy (generally to simplify the action) so as to locate the causes of malfunction more easily.

• Consult the details of the error messages displayed in GTClient
• When testing the integration action, always test with at least two entities and check that the integration action can run twice for the same campaign, including at least one different response (new response).
• Generally, when a constraint in the host table is not respected, build a copy of this table by not specifying any constraint or by modifying the field types to give more permissive ones.
• If an intermediate integration view is used, create an integration action which integrates the data directly into the intermediate integration table (considered to be the final destination table for this action), even if this means clearing the table beforehand and setting up bogus pivot fields: in this way, you will be able to analyse the data in the intermediate integration view. To do this, copy the integration action and for the compartments causing problems, specify the intermediate integration table as the final table and do not use either the intermediate integration table or the intermediate integration view for these compartments.
• If an error occurred during the integration, and if the error comes from the insertion of the data by GTServer in the first table (whether it is the intermediate integration table or the table created by GTServer from the final table hosting the data), the data is dumped by GTServer in CSV files in a subdirectory of the instance directory hosting the temporary files. If you have to open these files, remember to close them before validating the error display box. Finally, when opening csv files with Excel, the latter will reinterpret certain data (change a 01 into 1, etc.)
• To restrict the volume of data to be integrated for a more accurate diagnosis, you can edit the integration action to consider only the validated data. Then, among the responses, limit yourself to validating only the entity whose data poses a problem to the integration.
• If field modifications, etc., have taken place since the last modification of the launch action, edit a copy of the launch action and check that you can validate this action (certain consistency checks will be carried out by GTServer during validation).
• If the connection to the database cannot be made, see the connections paragraph of the Errors article.
• Check the order of integration of the compartments in the tables (number on the right of the compartment-table association). This must respect the referential integrity constraints written in the tables.
• If performance problems arise, first try to integrate the data in an empty table (even if it means using the « Purge data » option of the integration action). Add indexes (optimally unique) to pivot or key fields. Covering indexes can also be useful, especially in the case of updating on key fields. Then try again to integrate the data into the final table. You can also drop the data into an empty table and then fill the final table with a stored procedure.
• If a timeout occurs when GTServer is processing SQL sentences, you can change the timeout value for waiting for client-server execution of SQL commands via the option in the integration action. However, it is always preferable to optimise beforehand by adding indexes on the source or destination tables, building indexed views, etc., or limiting the data volume.

{:}