Principle

A ” Launch collection ” action allows the publication of questionnaires derived from a collection template when it is executed.

If the campaign (identified by a questionnaire template and a Statement date) does not exist, it will be created. Otherwise, new questionnaires will be published for this campaign.

Diffusion

The parameters of the diffusion particularly determine the destination entities and the affected correspondents.

• Address Book: Table / view providing the list of potential recipients of questionnaires. Technically, only one field containing the recipients’ email addresses is required. Other identifying fields may be useful to enrich the kernel.
  • Email axis: the address book field containing the email addresses of the correspondents.
• Assignment relationship: Table / view defining the assignment relationship.
  • Linking axis: field of the assignment relationship that allows joining with the address book.
• Diffusion axis: Select, among the fields present in the assignment relation, those defining the diffusion axis. Each unique combination of diffusion axis items will constitute an entity (see also the list of Axis Types).
  • Additional validation axis: Additional validation axis are fields in the root compartment which allow, for each entity, as many valid versions as the entity has defined additional validation axis items.
• Visualisation axis: Select, among the fields present in the root of the questionnaire, those defining the visualisation axis. The values of these components are displayed in the visualisation of responses of a campaign. Only components with a text format are accepted. The visualisation axis permit the display of a summary of the response directly in the discussion thread as well as in the response page and partly solve some informal workflows problems.
• Questionnaire name: Published file name. By default, the name is the template name, but you can customise it with system variables, kernel fields and form root compartment fields.
• Statement date table : Table / view containing the Statement date to be used for this campaign.
  • Source column: Table/view field containing the value to be used as the Statement date. This field must be a date field. If the table/view contains several records, only the first one is taken into account.
• Blocking customisation errors. If this box is checked, any error in the data feed of the campaign will block the launch of the campaign.
• This action is not executable. If this box is checked, the action cannot be executed, either manually or by automation). This option is useful for actions intended to feed a synchronisation. It allows the source data during synchronisation to be different from the data used by the launch action (for example, the launch action may use a restricted dataset to speed up publication, but the synchronisation will use the full dataset).

Data

This tab allows you to specify the data feed for the form. At least one compartment and at least one field of the form must be filled with data.

For each compartment you can specify a feed table/view and a sort.

In this example, the root compartment is fed by the “HR_DEMOS_Sites_Flags” view. Only 2 of the 3 fields in the view are used. On the other hand, for the “Newcomers” compartment, all (15/15) fields of the “HR_DEMO_Newcomers” table are used. The icon on a yellow background indicates a sorting of the data.

Messages of the template

This sheet lists the messages of the template from which the campaign originates. You can modify them, and it is generally preferable to edit the messages from this window rather than when editing the template. This is because you can have the variables from the kernel as well as the root compartment available here.

You can also reference the values received in the questionnaire responses (instead of the values sent) by prefixing the axis/header with a #.

For example, in an acknowledgement message, [[Comment]] will be substituted with the value of the Comment component of the questionnaire root at the time of sending, while [[#Comment]] will be substituted with the response to the Comment component provided by the correspondent.

System variables can also be used

Publication

• HTTP Check: If this box is checked, the document will connect to the GTServer web server to verify :
  • That the campaign is still active (not closed or deleted)
  • That the questionnaire has not been closed for the entity to which it is attached
  • That a new version of the questionnaire has not been sent.

If the HTTP check could not be performed (for example if it is not possible to access the GTWeb url), the questionnaire cannot be opened.

• HTTP diffusion: If this box is checked, the PUBLISH_URL variable is resolved and no attachment is added to the mail. Otherwise, the variable is not resolved and the form is provided as an attachment.

The link substituted to the PUBLISH_URL variable always points to the last version of the questionnaire sent for the email address and the items of the diffusion axes: if a questionnaire has been sent again for this entity, the correspondent will use the url of the first message to load the last version of the questionnaire if the questionnaire has been sent for the same email address

• HTTP response: If this box is checked, the data of the form will be sent back to GTServer using the HTTP channel; otherwise, the data will be sent back using the email channel: GTAnswer will detect the email protocol available on the workstation, generate an email containing the data of the form as an attachment as a compressed file and will send this email to the consolidation address specified in the instance settings.
• HTTP response: Send by mail if response fails: GTAnswer tries to transfer the response by HTTP, if the response is not successful (if the url cannot be reached from the GTAnswer workstation), GTAnswer tries to send the response by mail.
• Downward Synchronisation of inert patterns: Permits the synchronisation from GTAnswer. The designer can choose whether the list of patterns to be synchronised is defined by the current launch action or by another launch action (which can only be used for synchronisation if required).
• Authorising full synchronisation: permits all compartments (except the multi-tab) to be synchronised and activates the conflict resolution wizard for users.

The developer can request that a synchronisation is performed when the questionnaire is opened in GTAnswer and impose that a synchronisation is performed before the response is transmitted (in the latter case, the transmission of the response cannot take place if the prior synchronisation has failed).

Authentication

This sheet outlines the various options for authenticating respondents via Active Directory (AD) for users who do not have an account.

• No authentication: No authentication required.
• Active Directory: Authentication of the user account opening the document: When opening the document, GTAnswer will ask for the password of the user who is logged on to the active session via AD.
• Active Directory: authentication of the user account that opens the document and verification that its email address is that of the correspondent: When the document is opened, GTAnswer will ask for the user’s password who is connected to the active session via the AD. Then GTAnswer checks that the email address registered in the AD for the user is the same as that of the recipient registered by GTServer when the campaign was launched. This option does not allow the transfer of the questionnaire to a third person.
• Active Directory: only the user account associated with the correspondent’s email address will open the document: GTAnswer will ask for the password of the user name that corresponds to the email registered by GTServer and will use this account for authentication. This option does not allow the transfer of the questionnaire to a third person unless this person knows the password of the AD account associated with the email of the initial recipient (for example, in the case of a generic address and a generic account).

In the last two cases, it is the email address actually used by GTServer to send the email that is used as a reference for verification in the AD.

If the questionnaires have been redirected, the redirection address will be checked in the AD.

If the sending address is a comma or semi-colon separated list of addresses, this string will be checked in the AD.

In case of runtime errors

This paragraph summarises some of the tests to be carried out to ensure that the launch action is working correctly.

It only concerns problems with the data feeding the questionnaire.

In all cases, as for all types of actions (launch, integration, restitution), the action can be copied (right-click then “Duplicate action”) to be able to make modifications on the copy (in general to simplify the action) to locate the causes of dysfunction more easily.

See the details of the error messages displayed.

Launch action does not execute

• If there have been any changes to the field, etc., since the last time the launch action was modified. Edit a copy of the launch action and check that you can commit a small change to the action.
• If there is an error during transposition, consulting the temporary files may help to diagnose the error. See the corresponding point in the next paragraph.
• If the mails do not go out because of connection problems between GTServer and the DBMS or between GTServer and the mail server, see the connections paragraph in the Errors article.
• Check that each of the tables/views pointed to by the launch action is operational in the DBMS (the execution of a SELECT on each table should not return an error but may not return any data).
• If a multi-tab is used, the multi-tab compartment (or one of its sub-tabs) must be associated with a table containing the multi-tab axis. This multi-tab axis must not contain NULL data.
• Check the typing of the fields that are used in the joins: axis for linking with the address book, diffusion axes. These fields must have compatible types (for equality criteria) between the two tables.
• Check that the pattern keys are respected in the data supplying these patterns. 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. Enter a value in seconds in the registry on the GT Server in the HKLMSOFTWARECalameGTServerCommandTimeout key (by default, this value is 600 seconds or 10 minutes). However, it is always preferable to optimise beforehand by adding indexes to tables, building indexed views, pre-calculations in tables, etc., or limiting the data volume.

The launch action is executed, but the questionnaire does not contain the expected data

• Run the action in diagnostic mode
• Run the action while previewing the data. Without closing the preview box, go to the most recent sub-directory of the GT temporary directory to view the data files produced (.csv) (this directory can be shared as read-only on the server). All temporary files opened for diagnostic purposes should be closed after review and should not be modified.
• Remove all table/view associations to compartments except the compartment with incorrect data. Perform the modified action. Of the previously removed tables/views, add only those tables/views associated with the parent compartments of the compartment with incorrect data and then re-perform the modified action.
• If you are concerned about provisioning a transposition, check the temporary files produced in preview (see above). Delete any fields in the table/view that are neither fields in the parent compartments of the transposition nor fields declared in the transposition definition. This last recommendation excludes the case where a transposition in a pattern takes up all the fields of a pattern: In this case, the table/view must double all the key fields of the pattern, possibly use fields of the parent compartments and exclude the other fields (see Pattern and transposition).
• Interactions between compartments can occur. The rows of a pattern or the tabs of a multi-tab are determined by only one of the tables/views in the pattern or multi-tab: this is generally the table at the root of the compartment or, if this is absent, the first table associated with a compartment in the alphabetical order of the compartments (see Data assembly).
• The kernel fields have priority over the other fields: if a field is present in the address book or the assignment relation, only the values of this field will be taken into account, any field with the same name and belonging to a table/view associated with a compartment of the qst will simply be ignored (see Data assembly).
• In case of a pattern with a transposition, check that there are no incorrect use cases as described in the article Pattern and transposition
• If you have performance problems, try running a DBMS SELECT on each of the tables/views. If the DBMS SELECT is causing performance problems, accessing the same data through GTServer may also cause performance problems. If the SELECT is not causing performance problems, configure the instance to view the SQL sentences sent and test the SQL sentences sent and adapted for the entity in question.