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.

Answers

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 answers regardless of their validation status
  • all answers except validated responses
  • all answers except invalidated responses
  • all answers except responses awaiting validation
• Answers selection: You can choose from the following options:
  • All answers
  • 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 answer was sent
  • Date time the answer 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 answers: This option allows 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, restitution), 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.