*Restartability is a feature of the BizDataX tool that enables re-starting the package execution from the point where the previous execution attempt was interrupted and stopped for some reason.
Restartability is not enabled by default and needs to be configured by defining the restartability store. The restartability store is a table where the statuses of the masking units are going to be stored during the package execution.
The Restartability store can be configured on two occasions:
In the third step of the Wizard
In the Design plan, on General page
When designing a plan using the Wizard, in the third step the user can define Repeater store configuration and Restartability store configuration as optional steps. Restartability store configuration can be defined by populating the fields of the Restartability store configuration form.
Information for restartability store configuration is:
Enable restartability store configuration - Options:
Yes – restartability store configuration is enabled. All other fields are enabled.
No – restartability store configuration is disabled. Other fields are disabled.
Data source - Displays all created Data sources alphabetically. The user selects only one Data source.
Environment - Displays all Environments of the selected Data source. The user selects only one Environment.
Schema - Name of the Schema in which the information will be stored. The schema must exist but it doesn’t have to be imported.
Table - Name of the table created with restartability. The default value is "Restartability".
Figure 1: Step 3 of the Wizard - Restartability store configuration
Additionally, if the Wizard was not used when designing the plan or the user subsequently decided to use Restartability, the Restartability store can be configured on the General page in the Design plan process.
Basic Restartability data is shown:
Figure 2: Restartability tab on General page
To Configure the Restartability store, click the ‘Configure restartability store’ button. It will open a pop-up window with data to configure:
Figure 3: Configure restartability store on the General page
Package execution can be started in the selected restartability mode:
Restartability mode | Description |
---|---|
Do not use restartability (Off ) |
Restartability option is not enabled in package execution. This mode is typically used when it does not matter whether the package is going to be executed from the beginning or from the moment where the previous execution failed. |
Use restartability (Clean ) |
In this mode RESTARTABILITY table is created where during package execution unit statuses are saved. This mode cannot be used if statuses from previous runs exist. This mode is typically used in the first package execution with the restartability option enabled. |
Use restartability and delete any information from the last run (ForceClean ) |
Content of the RESTARTABILITY table is deleted and package execution starts from the beginning. This mode is typically used when some unit statuses exist, but they need to be ignored i.e. deleted. |
Continue from previous execution (Continue ) |
Package execution includes units that are in status Queued . The restartability option cannot be used with this mode if the previous execution finished all the work. This mode is typically used when it is assumed that the cause of the previously failed execution has been removed and that the next execution will pass successfully. |
The user defines if restartability will be used when executing the package. The package can be executed from Package details page by clicking on the Execute package button. A pop-up is displayed where the user can define the Restartability mode for that execution.
If the Restartability store is not configured. Restartability mode selection is disabled. It won’t be used while submitting a form and the iterator step will be skipped. If the Restartability store is configured, the Restartability mode selection is enabled.
The first package execution should be executed with the Use restartability (Clean
) mode. In case that execution fails (or doesn't get executed for some other reason), it will be possible to continue execution from the point it failed.
When a new version of the same Package is created (but with fixed errors or removed obstacles) and executed, execution can be continued from the previous point of failure. If 'Continue from previous execution' is selected, the 'Iterator control' step will be included and the user can select Jobs that will be executed again.
Figure 4: Iterator control step when using Restartabilty in Execution
If restartability is used, and the same table is masked more than once, then special handler settings need to be used (see the last part "Salt":"UniqueSaltExample). If multiple Jobs will mask the same table, handler settings need to be unique for each of them (for example, UniqueSaltExample in the example will be replaced with the name of the Job for which the settings are being defined).
Handler settings can be defined in the Settings field when registering/editing Job.
{"$type":"Ekobit.BizDataX.DataMasking.Interface.CompositeHandlerSettings,Ekobit.BizDataX.DataMasking.Interface","Ekobit.BizDataX.DataMasking.Interface.BulkCopySettings,Ekobit.BizDataX.DataMasking.Interface":{"$type":"Ekobit.BizDataX.DataMasking.Interface.BulkCopySettings,Ekobit.BizDataX.DataMasking.Interface","BatchSize":200000,"TableLock":null,"KeepIdentity":null,"Timeout":5400},"Ekobit.BizDataX.DataMasking.Interface.HandlerNamingSettings,Ekobit.BizDataX.DataMasking.Interface":{"$type":"Ekobit.BizDataX.DataMasking.Interface.HandlerNamingSettings,Ekobit.BizDataX.DataMasking.Interface","Salt":"UniqueSaltExample"}}
Figure 5: 'Settings' field for handler settings.