How can we help?
Search for answers or browse our knowledge base
Synchronization
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.