How can we help?

Search for answers or browse our knowledge base

< All Topics
Print

Restitution

Principle

A restitution action allows the publication of dashboards derived from a template when it is executed. The tool does not distinguish between templates dedicated to collection and those dedicated to rendering. The action for launching a rendition is similar to the one dedicated to launching a collection, but it does not offers the settings related to the reception of answers. Moreover, on the publications page, the reports are displayed differently.

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

Diffusion

The diffusion settings particularly determine the destination entities and the correspondents affected.

  • Address Book: Table/view providing the list of potential recipients of questionnaires. Technically, only one field containing the email address of the recipients 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 the joining with the address book.
  • Diffusion axis: Select, among the fields present in the assignment relationship, those defining the diffusion axis. Each unique combination of items of the diffusion axes will constitute an entity (see also the list of Axis Types).
  • File name: Name of the published file. By default, the name is that of the template, but you can customise it with system variables, kernel fields and document 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 to the campaign will block the launch of the campaign.

Data

This sheet allows you to specify the data feed of the document. At least one compartment and one field of the form must be fed 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.

 

 

Template messages

This sheet lists the template messages from which the return is derived. 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.

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 (e.g. 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 delivered as an attachment.

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

  • Descending synchronization of inert patterns : Allows Synchronisation from GTAnswer. The developer 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).

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

In case of runtime errors

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

It only concerns problems with the data feeding the document.

In all cases, as for all types of actions (launch, integration, rendering), the action can be copied (right click then “Duplicate action”) to be able to carry out modifications on the copy (in general to simplify the action) so as 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 this error. See the corresponding point in the next paragraph.
  • If the mails are not sent because of problems with the connection 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 (running 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 have NULL data.
  • Check the typing of the fields that are used in the joins: axis for linking with the address book, diffusion axis. 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 by limiting the data volume.

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

  • Run the action in diagnostic mode
  • Run the action while previewing the data, then without closing the preview box, go to the most recent subdirectory of the GT temporary directory (this directory can be shared in read-only mode on the server) to view the data files produced (.csv). 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 have a concern 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 transposition’s parent compartments nor fields declared in the transposition definition. This last recommendation excludes the case where a transposition in a pattern absorbs all the fields of a pattern: in this case, the table/view must double all the key fields of the pattern, use fields from the parent compartments if necessary, and exclude the other fields (see Pattern and transposition).
  • Interactions between compartments can occur. The rows of a pattern or the sheets 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 relationship, 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 you have a pattern with a transposition, check that the incorrect use cases described in the Pattern and Transposition article are not present
  • 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.
Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.
Previous Combined Action
Next SQL Action
Table of Contents