Restartability

*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 store

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:

1. In the third step of the Wizard

2. In the Design plan, on General page

Restartability store in Wizard

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:

1. Enable restartability store configuration - Options:

   1. Yes – restartability store configuration is enabled. All other fields are enabled.

   2. No – restartability store configuration is disabled. Other fields are disabled.

2. Data source - Displays all created Data sources alphabetically. The user selects only one Data source.

3. Environment - Displays all Environments of the selected Data source. The user selects only one Environment.

4. Schema - Name of the Schema in which the information will be stored. The schema must exist but it doesn’t have to be imported.

5. Table - Name of the table created with restartability. The default value is "Restartability".

   • Name restrictions:
     • The first character can be a letter (a-z or A-Z) or underscore (_)
     • All characters after first can be a letter (a-z or A-Z), an underscore (_), a dollar sign ($), a hashtag (#) or at sign (@)
     • Max allowed length is 50 characters

Figure 1: Step 3 of the Wizard - Restartability store configuration

Restartability store in Design plan

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:

1. Configure restartability store
2. Data source
3. Environment
4. Schema
5. Table

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:

1. Configure restartability store - defines whether the restartability store is configured. If it's set to ‘Yes’, other fields will be enabled. If it's set to 'No', other fields will be disabled.
2. Data source - defines in which Data source will the restartability be stored.
3. Environment - defines in which environment of the chosen data source will the restartability be stored.
4. Schema - defines in which schema of the chosen environment will the restartability be stored.
5. Table - defines the name of the table in which the restartability will be stored. The default value is "Restartability".

Figure 3: Configure restartability store on the General page

Restartability mode

Package execution can be started in the selected restartability mode:

Starting a restartable package execution

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

Masking the same table more than once

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.