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. For configuring restartability stores check datasource specific sections: Oracle, Microsoft SQL Server, DB2, Informix and Sybase.

The restartability store is a table of a default name RESTARTABILITY_ITERATORS where the statuses of the masking units are going to be stored during the package execution.

Restartability mode

Package execution can be started in selected restartability mode:

The first package execution should be in Clean mode.

Starting a restartable package execution

Package execution can be started from Visual Studio, from Portal and from the command line. Restartability mode is defined as an optional command line argument. If not written, the value will be Off.

• When started from Visual Studio, by going to Solution Explorer -> right-click on project -> Properties -> Debug -> Start options -> Command line arguments field, the restartability mode is defined in the following form: --RestartabilityMode:Clean

Figure 1: Visual Studio Properties

• When started from Portal, user must select one of the restartability modes before starting the package execution. The default offered mode is Do not use restartability.

• When started from the command line, the package is started in the following form: BizDataXPackage.exe --RestartabilityMode:Clean

Example: C:\Users\Administrator\source\repos\BizDataXPackage\BizDataXPackage\bin\Debug>BizDataXPackage.exe --RestartabilityMode:Off

Restartability process

Each package consists of masking units (package workflow steps, table partitions, table segments). During a package execution, the status of each unit is saved so that the next package execution includes only units that did not finish with success.

Statuses are Finished, Running, Queued and Failed.

Below is an example with a couple of records from RESTARTABILITY_ITERATORS table:

Masking of some values in one of the units was unsuccessful (State Queued). Therefore, no value in that unit is masked and execution needs to be repeated in order to do that. The values in other two units are masked successfully. In the next masking attempt, the values from only that units will be masked, of course, if other conditions for masking will be provided correctly.

If the package has more than one masking engine, if applicable, it is recommended to set their ContinueOnIteratorFail properties to true in order to continue the package execution by going to the next masking unit if the previous one failed.