Important Note: Each masking rule is considered by the Data Masker software to be an independent entity and its order of execution is not guaranteed. In fact, the Data Masker usually runs rules out of numeric sequence to optimize the masking process.

Often, it is necessary to ensure that a predetermined rule completes before a subsequent rule executes. This is especially true if the information in one field in a row must be correlated or synchronized with the contents of other columns in that row. Commonly a WHERE Clause option on the rule is used to achieve this effect. Here's a typical scenario:

A column of personnel information needs to be masked. It is required that the gender information 'M' or 'F' for the record be randomized and that the first name field of the masked rows be substituted with the Male First Names or Female First Name data set as appropriate.

The masking operation for the gender information is a simple shuffle of the columm data - this will randomize it sufficiently. The operation on the first name column consists of two substitution rules. Both use a WHERE clause on the gender field in the row (for example WHERE GENDER='M') and substitute values from the appropriate data set into the matching first name field.

Clearly it is essential that the rule shuffling the gender column completes before either of the two substitution rules start. The first names will not correlate to the gender if the substitution takes place and then the gender column is randomized. As stated above, it should not be assumed that masking rules will be executed in order of rule number. In fact, this rarely happens due to the optimization that is performed on the rules inside the Data Masker software.

There are two ways to make sure that a rule (or rules) execute in a required order: Rule Dependencies and Rule Blocks. The following sections will consider each mechanism.

Rule Dependencies

If a rule must execute after another rule completes, it is possible to build a dependency chain. Dependent rules cannot execute until their parent rule (or rules) has completely finished execution. The dependency state of a rule is displayed on the Set Rules tab in an indented form as shown below:

A View of Dependent Data Masker Rules

In the above illustration, substitution rules 3000 and 3001 will not execute until the shuffle operation of rule 4000 completes. It is possible to build chains of any depth and complexity. To make a rule dependent on another rule, select it in the Set Rules tab and press the Set Dependency button. The Rule Dependency dialog box will start and offer the option of selecting the new parent rule. The screen will reconfigure to show the appropriate indentation once the dependency has been configured.

Rule Blocks

Dependency chains are useful but there are dependency modes under which their utility becomes a bit awkward. Imagine a scenario in which three rules (A, B, C) must execute to completion before a fourth rule (rule D) can begin. Implementing this scenario with dependency chains configures a sequence like:

A-->B-->C-->D

in which each rule is dependent on the rule above it in the chain. This makes the chain very long and also falsely indicates that rules B and C are in some way dependent on rule A. This is not the case - rules A, B and C are independent. It is rule D that is dependent on all three.

To simplify things and to avoid implying false dependencies the Data Masker software implements a concept called Rule Blocks. A rule block is a two-digit numeric prefix listed before the rule number. Rule blocks are processed in strict numeric order and all rules in a given rule block will complete before any rule in the next highest rule block begins. Inside a rule block the rules execute in random order as determined by the optimization routines and their dependency chains.

The above scenario (with rules A, B, C and D) would be handled by placing rules A, B and C in a numerically lower rule block than rule D. No complex dependency chain is necessary. The image below illustrates a sequence of rules assigned rule block 10 which are designed to update a series of fields in a table before a Run Command rule executes in rule block 20 to call a custom procedure which provides some processing to populate a composite name field. The Run Command rule will not execute until every rule (including the dependencies) has completed in rule block 10.

A View of Data Masker Rule Blocks

Note: The rule blocks for dependent rules are always listed as xx. Dependent rules always take the same rule block id as the parent rule.