Once you defined the summaries you want, follow these steps to promote them to the different environments (e.g. from testing to production):
A job to completely refresh the summary. During promotions, this job needs to be executed 1) the first time the summary is promoted and 2) every time the summary definition is modified.
If the summary allows incremental loads, define a second Scheduler job with the incremental load configuration.
This job will not be executed during a promotion. The incremental job will be executed periodically to keep the data up-to-date.
In Solution Manager, create a revision that includes the summary and the Scheduler jobs described above.
If the summary already exists on the target environment and you want to replace it using a new one with a different configuration or definition, do this:
Create the revision with the Replace existing elements option.
Include the Scheduler job that completely refreshes the summary (even if the job has not changed) and select Execute job when revision is deployed.
The following sections explain the promotion process in detail for new and modified summaries.
Promotion Process for New Summaries¶
The first time a summary is promoted, the VDP server sets the summary state to needs_refresh as the table with the summary content does not exist yet. You need to include in the revision the Scheduler job that completely refreshes the summary and select ‘Execute job when revision is deployed’:
Once the Scheduler job is executed on the first node, the table is created in the selected data source and the status of the summary changes to Valid.
Finally, the same summary is promoted to the second node. The second VDP server verifies the table already exists on the database and sets the new summary as Valid.
Promotion Process for Summary Updates¶
If you decide to change something in the summary definition, like the query or the data source where the summary content is stored, it is important to select Replace existing elements in the revision and to include the Scheduler job that refresh the summary completely on target.
In this case, the mechanism is the same but there are slight differences to take into account:
As before, the Solution Manager promotes the summary to the first VDP server. The server verifies the table already exists. If the data source details or the columns of the table have changed, the VDP server realizes the existing one is no longer valid and sets the status of the summary to “needs_recreate”.
Then, the Deployment process executes the Scheduler job that refresh the summary. The VDP server re-creates the summary table and changes the summary status to Valid.
Finally, the same summary is promoted to the second node. The second VDP server verifies the table already exists on the database and the schema is correct so it sets the summary status to Valid.
The query optimizer only uses a summary if its status is ‘Valid’. The status of a summary is only set to ‘Valid’ after a successful load. This means that if the summary has status ‘Needs Refresh’ or ‘Needs Recreate’ the query optimizer will not use that summary for query acceleration.