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

Table of contents
Restartability store
     Restartability store in Wizard
     Restartability store in Design plan
Restartability mode
Starting a restartable package execution
     Masking the same table more than once

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

Step 3 - Restartability store configuration 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

Restartability tab 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".

General page Figure 3: Configure restartability store on the General page

Restartability mode

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.

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.

General page 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.


General page Figure 5: 'Settings' field for handler settings.