Post-job scripts
Last updated
Last updated
Required license: Professional or Enterprise
Tonic Structural can execute custom SQL scripts on the destination database when a database generation job is complete.
Post-job scripts allow you to make adjustments to the destination database. For example, you might have a set of regular demo users that you always want to have available. You can use a post-job script to add these demo users to the destination database after each data generation run.
You manage post-job scripts from the Post-Job Actions view. To display the Post-Job Actions view, either:
On the workspace management view, in the workspace navigation bar, click Post-Job Actions.
On Workspaces view, from the dropdown menu in the Name column, select Post-Job Actions.
On the Post-Job Actions view, the Scripts list contains the list of post-job scripts.
For each post-job script, the list contains:
A toggle to enable or disable the script
The name of the script
The user who created the script
The date and time when the script was most recently updated
Options to edit or delete the script
Required workspace permission: Configure post-job scripts and webhooks
To create a post-job script, in the Post-Job Scripts panel, click Create Post-Job Script.
On the script configuration dialog, provide the script details, then click Save.
On the script configuration dialog:
In the Script Name field, provide a name for the script.
In the SQL Script field, type or paste the SQL script.
For a MySQL database, you must explicitly pass a USE statement to define the database.
To format the script for readability, click Beautify.
By default, if a post-job script fails, then the entire data generation job fails. To instead register a warning without failing the data generation job, toggle Enable Warnings to the on position.
To save the script configuration, click Save.
To edit a post-job script:
In the Scripts list, click the edit icon for the script.
On the script configuration dialog, make the updates to the script.
Click Save.
Required workspace permission: Configure post-job scripts and webhooks
To delete a post-job script configuration:
In the Scripts list, click the delete icon for the script.
On the confirmation dialog, click Delete.
Required workspace permission: Configure post-job scripts and webhooks
In the Scripts list, the scripts are displayed in the order in which they are executed. The script at the top of the list is executed first, and the others follow in order from top to bottom.
To change the execution sequence, change the list order.
To execute a script earlier, drag it to a higher location in the list.
To execute a script later, drag it to a lower location in the list.
You use the toggle at the left of each script to control whether the script is enabled.
When the toggle is in the on position, the script runs.
When the toggle is in the off position, the script does not run.
Required license: Enterprise license.
By default, a child workspace inherits the configured post-job scripts from its parent workspace. If you make any changes to the child workspace configuration, including adding, editing, or deleting a script, the inheritance is removed. The child workspace no longer inherits any post-job script changes from its parent workspace.
For a child workspace, the Post-Job Scripts view indicates the current inheritance status.
Inherits parent configuration means that the child workspace inherits the post-job scripts from the parent workspace.
Overrides parent configuration means that the child workspace does not inherit the post-job scripts from the parent workspace.
To reset the inheritance, in the Overrides parent configuration notice, click Reset, then on the confirmation dialog, click Reset again.
The overrides are removed. The child workspace inherits any subsequent configuration changes from the parent workspace.
For a parent workspace, you can view the current inheritance status of the child workspaces.
The Child Workspaces tab contains the list of child workspaces.
For each workspace, the list includes:
The workspace name.
The inheritance status. Inheriting indicates that the child workspace inherits the configuration from the parent. Overriding indicates that the child workspace overrides the configuration and does not inherit it from the parent.
Your role in the child workspace.
The owner of the child workspace.
You cannot reset the inheritance status from the Child Workspaces tab. If you have access to a child workspace, to switch to that workspace, click the arrow icon in the rightmost column.
