{:fr}

Présentation

Cet article présente le paramétrage des options de synchronisation pour les développeurs. Pour l’aide utilisateur, consultez l’article Synchronisation des documents.

La synchronisation permet à partir d’un document chargé dans GTAnswer de rapatrier les données de la base Client dans les compartiments du document.

Les données synchronisées sont transmises de la base Client vers GTAnswer : BD Client → GtServer → GtWeb → Answer.

La synchronisation de données est effectuée uniquement :

• avec GTWeb, installé pour assurer la communication entre GTAnswer et GTServer
• de manière descendante (BDClient/GTServer vers Answer via GTWeb). Les données ne remontent pas (seule la transmission de la réponse permet de « remonter les données »)
• en choisissant l’une des modalités suivantes :
  • Synchronisation des motifs inertes hors multi-onglets et hors transposition du questionnaire : c’est-à-dire les motifs en dehors des multi-onglets, ne contenant pas de transposition, et ne comportant que des composants de type « contrôle » ou « hyperlien » (i.e. non modifiables par le correspondant), sans ajout ni suppression de ligne par le correspondant dans le motif.
  • Synchronisation complète, prenant en charge tous les composants et tous les compartiments (sauf les multi-onglets) et proposant un assistant de gestion des conflits pour les utilisateurs.

La synchronisation peut être déclenchée :

• A tout moment par l’utilisateur dans GTAnswer (avec un document ouvert) grâce au bouton Synchronisation
• A l’ouverture du document
• Avant la transmission de la réponse  (pour s’assurer du dernier état des données).

Conception et fonctionnement

Synchronisation des motifs inertes

La synchronisation pour un document est activée dans l’onglet « Publication » de l’action de lancement (collecte ou restitution)

Les données à synchroniser peuvent être :

• Les mêmes que celles de l’action de lancement (option « Utiliser cette action »)
• Définies via une action de lancement de campagne pour le même modèle : l’action de synchronisation.

L’action de synchronisation (définissant les éléments à synchroniser/descendre dans le questionnaire) peut être choisie parmi la liste des actions de lancement du modèle.

L’option Synchronisation au chargement du questionnaire demande à GTAnswer d’effectuer une synchronisation au moment où le questionnaire (ou la restitution) est ouvert(e).
La synchronisation peut échouer sans entraver l’utilisation du document par le correspondant.

L’option synchronisation avant l’envoi de la réponse effectue une synchronisation avant la transmission de la réponse.
Si une erreur se produit lors de cette synchronisation, la transmission de la réponse ne peut être effectuée.
Ceci permet de mettre à jour des contraintes de fonctionnement dans le questionnaire en fonction de l’évolution de statuts de données dans la base Client.

Synchronisation complète

Contrairement à la synchronisation des motifs inertes, la synchronisation complète :

• permet de synchroniser l’ensemble des compartiments (racine, transposition, motifs en écriture) à l’exception des multi-onglets.
• lors de l’exécution, la synchronisation complète affiche un assistant permettant de gérer les conflits (lorsque des données de la base pourraient remplacer des données saisies dans le questionnaire)

Action de synchronisation

C’est l’action de lancement de campagne pointée par l’action de lancement de campagne effectivement exécutée par l’utilisateur.

L’action de synchronisation peut être la même action que l’action de lancement de campagne.

L’action de synchronisation définit impérativement un carnet d’adresses, une relation d’affectation, une table de date d’arrêté et une ou plusieurs tables/vues de la base client à associer aux compartiments à synchroniser.

Seuls les motifs inertes (ne comportant que des composants contrôles sans ajout ni suppression de lignes) et situés hors des multi-onglets peuvent être synchronisés de manière descendante, et aucune gestion des conflits n’a lieu : les données du document sont remplacées par celles de la base.

Quelques  conseils :

• Il est préférable d’avoir une action de synchronisation distincte de l’action de lancement de façon à pouvoir effectuer des mises à jour en fonction de données intégrées partiellement par exemple.
• L’action de synchronisation devrait être non-exécutable
• L’action de synchronisation des motifs inertes devrait être privilégiée pour les restitutions car elle s’exécute directement, sans afficher l’assistant de gestion des conflits (qui n’a de toute façon pas d’intérêt dans le cadre d’une restitution).

Fonctionnement

Lorsqu’une synchronisation est déclenchée (par action de l’utilisateur ou automatiquement à l’ouverture ou avant la transmission de la réponse) :

• GTAnswer sollicite GTWeb pour une synchronisation pour le document actuellement ouvert
• GTWeb sollicite GTServer pour une synchronisation sur le document ouvert dans GTAnswer
• GTServer effectue des vérifications sur la validité du document : publication ouverte, document ouvert.
• GTServer extrait les données de la base client en utilisant l’action de synchronisation de la même manière que pour un lancement de campagne i.e. comme si cette action était utilisée pour préremplir des documents et les envoyer.
• Les données extraites de la base client par GTServer sont envoyées à GTAnswer par l’intermédiaire de GTWeb.

Les données sont extraites de la base Client comme pour un lancement qui serait effectué à partir de l’action de synchronisation :

• Les données dans chacun des motifs sont triées suivant les informations de l’action de synchronisation
• Les items des axes de distribution et de l’axe de liaison (entre carnet d’adresses et relation d’affectation) utilisées au moment de l’envoi du document permettent de désigner les données du noyau et des tables/vues à extraire pour les compartiments.

Les items des axes de distribution et de l’axe de liaison doivent être préservés tout au long de la publication du document pour autoriser la synchronisation pour cette entité et ce document.

Utilisation

Modification de la synchronisation après envoi

La campagne lancée est liée à une action de synchronisation.

L’action de synchronisation peut être renommée, modifiée ou réimportée.

L’action de synchronisation ne peut être supprimée.

Dans l’action de synchronisation, les associations tables-compartiments peuvent être modifiées après l’envoi du questionnaire.

Si une association table-compartiment est supprimée, le questionnaire conservera le dernier état des données (lors de l’envoi ou lors de la dernière synchronisation effectuée avant l’enregistrement du questionnaire).

Il ne peut y avoir des documents lancés au sein de la même publication avec une action de synchronisation différente.

Performances et sécurité

• Rapidité des connexions : La communication est effectuée entre GTAnswer, GTWeb, GTServer et la base client (et dans une moindre mesure la base GT).
  Le temps de réalisation de la synchronisation est un temps d’attente pour le correspondant : les communications GTAnswer GTweb, GTWeb GTServer et GTServer SGBD doivent être rapides, l’extraction des données par GTServer doit également être rapide (précalculs dans des tables au besoin, tables in-memory, etc…)

• Données à synchroniser volumineuses : Si les données à réinjecter dans les motifs inertes sont nombreuses (lignes > 5000 et/ou volumétrie, les adaptations des motifs et les recalculs peuvent être lourds. Il est alors préférable de prévenir l’utilisateur. Optimiser les formules dans les calculs peut être une solution (cf Optimisation des performances)

• La communication GTAnswer<->Gtweb devrait être effectuée en https (en configurant le serveur Web hébergeant GTWeb pour autoriser les connexions chiffrées)
  A fortiori si GTWeb est destinée à communiquer en dehors de domaines « protégés ».

Contraintes et Préconisations

Connexion https

La mise en place d’une connexion sécurisée https pour l’url de GTWeb est très fortement conseillée. A fortiori si le serveur web communique avec l’extérieur.

Stabilité des items du noyau

Les éléments suivant doivent rester les mêmes entre l’exécution de l’action de lancement et l’exécution de l’action de synchronisation :

• Les axes de distribution de l’action de lancement et de l’action de synchronisation doivent être les mêmes.

• L’axe de liaison (entre carnet d’adresse et relation d’affectation) doit être le même.

• Les items des axes de distribution doivent être les mêmes tant qu’une synchronisation est requise sur le questionnaire.

• L’item de l’axe de liaison (entre carnet d’adresse et relation d’affectation) doit être le même tant qu’une synchronisation est requise sur le questionnaire. Ceci peut être difficile dans le cas d’une même entité envoyée à plusieurs individus ou si un changement d’adresse mail (impactant l’item de l’axe de liaison) peut être effectué après le lancement du questionnaire.

Conseil : Il est préférable, lorsqu’une synchronisation est requise, d’utiliser pour carnet d’adresse et relation d’affectation une seule et même table ayant pour clé les axes de distribution, d’ajouter au besoin (via une vue) un axe unique servant de clé et de se servir de cette clé comme axe de liaison (ainsi la synchronisation ne sera pas dépendante des modifications des individus affectés ou de leur adresse mail).
Envoyer une même entité à plusieurs individus peut se faire en concaténant les adresses mails avec un point-virgule dans le champ de l’adresse mail.

Concernant la date d’arrêté :

• L’action de synchronisation connaît une seule date d’arrêté. C’est la date d’arrêté de la table de date d’arrêté au moment de la demande de synchronisation qui sera utilisée pour extraire les tables/vues à synchroniser.

Dans le cas où les données à synchroniser peuvent être différentes suivant les dates d’arrêté (i.e. pour des campagnes différentes), il peut être utile d’incorporer un équivalent de la date d’arrêté dans les axes de distribution.

Visualisation et validation dans GTAnswer

Les données du questionnaire peuvent toujours être synchronisées après la transmission de la réponse ou après la validation.

Lorsqu’une validation est effectuée et qu’un questionnaire demande la synchronisation à l’ouverture, le questionnaire ouvert dans GTAnswe pourra contenir des données différentes des données au moment de la validation.
Dans les cas où la synchronisation porte sur des données ayant une influence sur la validation, il est préférable de désactiver la synchronisation à l’ouverture du questionnaire.{:}{:en}

Overview

This article presents the setting of synchronisation options for developers. For user help, see the article Document Synchronisation.

Synchronisation enables data from the Client database to be transferred from a document loaded into GTAnswer to the document compartments.

The synchronised data is transferred from the client database to GTAnswer: Client DB → GtServer → GtWeb → Answer.

Data synchronisation is only performed :

• with GTWeb, installed to ensure communication between GTAnswer and GTServer
• In a descending manner (BDClient/GTServer to Answer via GTWeb). The data does not ascend (only the transmission of the answer makes it possible to  » bring up the data « ).
• by choosing one of the following methods:
  • Synchronisation of inert patterns without multi-tabs and without transposition of the questionnaire: i.e. patterns outside multi-tabs, containing no transposition, and including only  » control  » or  » hyperlink  » type components (i.e. not modifiable by the correspondent), without addition or deletion of rows by the correspondent in the pattern.
  • Full synchronisation, supporting all components and compartments (except multi-tabs) and offering a conflict management wizard for users.

Synchronisation can be triggered :

• At any time by the user in GTAnswer (with a document open) using the Synchronisation button
• When the document is opened
• Before transmitting the response (to ensure the latest data status).

Design and operation

Synchronisation of inert patterns

Synchronisation of a document is activated in the « Publication » sheet of the launch action (collection or rendition)

The data to be synchronised can be :

• The same as those in the launch action (« Use this action » option)
• Defined via a campaign launch action for the same template: the synchronisation action.

The synchronisation action (defining the elements to be synchronised/descended in the questionnaire) can be chosen from the list of launch actions of the template.

The Synchronisation on questionnaire loading option instructs GTAnswer to perform a synchronisation when the questionnaire (or rendition) is opened.

The synchronisation can fail without hindering the correspondent’s use of the document.

The Synchronisation before sending the response option performs a synchronisation before the response is sent.

If an error occurs during this synchronisation, the response cannot be transmitted.

This allows operating constraints in the questionnaire to be updated according to changes in client database data status.

Full synchronisation

In contrast to the synchronisation of inert patterns, full synchronisation:

• allows all compartments (root, transposition, write patterns) to be synchronised, except multi-tabs.
• during execution, full synchronisation displays a wizard to manage conflicts (when data from the database can replace data entered in the questionnaire)

Synchronisation action

This is the campaign launch action pointed to by the campaign launch action actually executed by the user.

The synchronisation action can be the same action as the campaign launch action.

The synchronisation action must define an address book, an assignment relationship, a statement date table and one or more client database tables/views to be associated with the compartments to be synchronised.

Only inert patterns ( involving only control components without adding or deleting rows) and located outside the multi-tabs can be synchronised in a descending manner, and no conflict management takes place: the data of the document is replaced by that of the database.

Some advice:

• It is preferable to have a synchronisation action separate from the launch action so that updates can be made based on partially integrated data for example.
• The synchronisation action should be non-executable
• The synchronisation action for inert patterns should be preferred for restitution because it is executed directly, without displaying the conflict management wizard (which is of no interest in the context of a restitution).

Operation

When a synchronisation is triggered (by user action or automatically at the opening or before the transmission of the response) :

• GTAnswer requests GTWeb for a synchronisation for the currently opened document
• GTWeb requests GTServer for a synchronisation on the document opened in GTAnswer
• GTServer checks the validity of the document: open publication, open document.
• GTServer extracts data from the client database using the synchronisation action in the same way as for a campaign launch, i.e. as if this action were used to pre-fill documents and send them.
• The data extracted from the client database by GTServer is sent to GTAnswer via GTWeb.

The data is extracted from the Client database as if it were launched from the synchronisation action:

• The data in each pattern is sorted according to the synchronisation action information
• The items of the diffusion axis and the link axis (between the address book and the assignment relationship) used when sending the document are used to designate the core and table/view data to be extracted for the compartments.

The diffusion axis and link axis items must be preserved throughout the publication of the document to allow synchronisation for that entity and document.

Use

Modification of the synchronisation after sending

The launched campaign is linked to a synchronisation action.

The synchronisation action can be renamed, modified or re-imported.

The synchronisation action cannot be deleted.

In the synchronisation action, table-compartment associations can be modified after the questionnaire has been sent.

If a table-compartment association is deleted, the questionnaire will keep the last status of the data (at sending or at the last synchronisation performed before saving the questionnaire).

There cannot be documents launched within the same publication with a different synchronisation action.

Performance and security

• Speed of connections: Communication is performed between GTAnswer, GTWeb, GTServer and the client database (and to a lesser extent the GT database). The synchronisation time is a waiting time for the correspondent: GTAnswer GTweb, GTWeb GTServer and GTServer DBMS communications must be fast, and data extraction by GTServer must also be fast (pre-calculations in tables if necessary, in-memory tables, etc.)
• Large data to be synchronised: If the data to be re-injected into the inert patterns are numerous (rows > 5000) and/or voluminous, the pattern adaptations and recalculations can be cumbersome. It is, therefore, preferable to warn the user. Optimizing the formulas in the calculations can be a solution (see Optimizing performance)
• The GTAnswer<->Gtweb communication should be done in HTTPS (by configuring the web server hosting GTWeb to allow encrypted connections). Especially if GTWeb is intended to communicate outside « protected » domains.

Constraints and Recommendations

HTTPS connection

Setting up a secure HTTPS connection for the GTWeb URL is strongly recommended, especially if the web server communicates with the outside.

Stability of the kernel items

The following items must remain the same between the execution of the launch action and the execution of the synchronisation action:

• The diffusion axis of the launch action and the synchronisation action must be the same.
• The link axis (between address book and assignment relationship) must be the same.
• The diffusion axis items must be the same as long as synchronisation is required on the questionnaire.
• The link axis item (between address book and assignment relationship) must be the same as long as synchronisation is required on the questionnaire. This may be difficult in the case where the same entity is sent to several individuals or if a change of email address (impacting the link axis item) is made after the questionnaire is launched.

Tip: When synchronisation is required, it is preferable to use a single table for the address book and assignment relationship, with the diffusion axes as the key, to add a single axis as the key if necessary (via a view) and to use this key as the link axis (this way, synchronisation will not be dependent on changes to the assigned individuals or their email addresses).

Sending the same entity to several individuals can be done by concatenating the email addresses with a semi-colon in the email address field.

Concerning the statement date :

• The synchronisation action knows only one statement date. It is the statement date of the fixed date table at the time of the synchronisation request that will be used to extract the tables/views to be synchronised.

In the case where the data to be synchronised may differ according to the statement dates (i.e., for different campaigns), it may be useful to incorporate an equivalent of the statement date in the diffusion axis.

Visualization and validation in GTAnswer

Questionnaire data can always be synchronised after transmission of the response or after validation.

When a validation is performed and a questionnaire requires synchronisation at opening, the questionnaire opened in GTAnswer may contain data different from the data at the time of validation.

In cases where synchronisation is required for data that affect validation, it is preferable to deactivate synchronisation when the questionnaire is opened.{:}