Data Masker Create/Edit Synch. Manager Rule Form

Sometimes it is necessary to anonymize the values in the columns of tables which form the join keys between those tables. This type of masking and synchronization requirement can be problematic when done manually since both the masking and synchronization operations have to be performed at the same time. If the classic Substitution and Table-To-Table sync method is used the Table-To-Table rule will fail because the join keys are no longer identical due to the masking operations of the Substitution rule.

The Sync. Manager Rule help page contains a detailed discussion of how the Synch. Manager rule works and why you might need it.

The Edit Synch. Manager rule form presents options which enable you to modify or configure the behavior of a Synch. Manager rule. The form displays a series of tabs across the top of the page. The function of these tabs is explained below:

The Sync. Mgr Rule Sequence Tab

When the Synch. Manager rule is executed it actually runs a sequence of rules. The discussion below contains more information regarding this sequence.

The Rule Generation By FK Tab

This tab enables additional tables to be added to the Synch. Manager (and hence masked) by following foreign key relationships. The tools on this page make it easy to add chains of tables related by foreign keys to the rule.

The Rule Tools and Options Tab

This tab provides tools to manually trigger a rebuild of the various rule blocks contained on the Rule Sequence Display. Also provided on this tab is a way to manually add tables to the PFFK masking sequence.

The Source Column Options Panel

The basic operation of the Synch. Manager rule is to build a temporary table, populate that table with a distinct set of rows from each of the tables which will be updated. If there are many tables in the rule, then the acquisition of the distinct set of rows can take some time. If the primary table (the one which served as the original source of the Sync. Mgr. rule) contains a full and distinct set of the rows to be masked, then the checking of the secondary fan-out tables for missing rows is redundant. Checking the Do NOT Test Secondary Tables for Missing Values will cause the PFKF Change Manager to automatically adjust its rule sequence in order to skip the check of data in the secondary tables. This can make the execution of the Command rules in Rule Block 20 much faster.

This option should be used if, and only if, it is certain that the primary table contain a complete set of every possible value to be masked. If this option is checked, and the secondary tables actually contain values not present in the primary tables, then those values will not get masked.

The Rule Sequence Display Panel

The Rule Sequence Display Panel

When viewed on the main Rules Tab of the Data Masker software, a Synch. Manager rule appears as a single entry - like any other rule. However, the Synch. Manager Rule is designed to perform a complex sequence of actions and it does this by acting as a container which ecapsulates a series of other rules. When the PFKF Change Manager Rule is executed it will run its encapsulated rules. These encapsulated rules will take advantage of the parallelism of the Data Masker software and other rules which are in the same rule block as the PFKF Change Manager rule can, and will, execute along side them.

The Rule Sequence Display Panel shows the rules which will be executed when the Synch. Manager rule is activated. Note that these rules also have rule block values associated with them. These rule blocks are only significant within the PFKF Change Manager. They, and their dependency relationships, determine the order of execution within the PFKF Change Manager. The entire set of rules, as a whole, executes within the rule block of the Synch. Manager itself.

In other words, when the Synch. Manager is run it will put its rules on the execution queue in the appropriate order. These rules will be scheduled to run according to their own internal order and they will also run in parallel with any other rules which happen to be in the same rule block as the Synch. Manager rule.

The Rule Sections

Rule Block 10

These two Command rules create a temporary table with two pairs of columns. The first column will contain the original data and the second column will contain the masked data. If the temporary table already exists it will simply be truncated when these rules execute.

Rule Block 20

These section populates the temporary table created in Rule Block 10. There will be one Command rule for each target table unless the Do NOT Test Secondary Tables for Missing Values is checked (see the Source Column Options discussion above). These Command rules contain SQL statements which will build a distinct, complete set of values in the columns to be masked.

Rule Block 30

This section contains a Substitution or Row-Internal Synch. rule. The exact rule type used here will be identical to the rule originally in place when it was converted to a Synch. Manager. The primary difference is that the masking operations now happen on the target columns of the temporary table created in Rule Block 10;

Rule Block 40

Foreign keys must be disabled on the target tables during the masking operations otherwise the updates might fail. This section contains a Foreign Key Manager which disables those foreign keys (if present).

Rule Block 50

This section contains the Table-to-Table rules which perform the actual masking operations on the target tables. If you open them up for viewing (just double click on the rule) you will see that the source of the rule is the masked columns of the temporary table and the target columns are on the target table. The join condition is set to use the original (unmasked) columns in the temporary table. In this way, the masking operations are synchronized.

Rule Block 60

This section just re-enables the foreign keys disabled by the opeations in Rule Block 40. All of the foreign keys should enable - because the values in the child and parent columns have changed in a synchronized way and, although they have different values, the rows they join still correlate with each other.

Rule Block 70

The last rule block contains a command rule which drops the temporary table - thus recovering the resources it used and also removing the correlation relationships between the original and masked names.

The Rule Statistics Button

The Rule Sequence Display Panel

The Rule Statistics button changes the Rule Sequence display to a Rule Statistics display. The screen enables the current progress of each individual rule to be monitored. Note that the Rule Statistics panel on the main form will only display the statistics for the PFKF Change Manager Rule as a whole. Statistics on each individual rule can only be found by looking at this panel.

The image above shows the available statistics. A discussion of the meaning of the values in each of the columns can be found on the main form Rule Statistics Tab help page.

Creating a New Synch. Manager Rule

Synch. Manager rules are not created using the usual New Rule button located on the bottom of the Rules in Set tab. Instead a template Substitution or Row-Internal Synch. rule is created on a table and then this rule is converted into a PFKF Change Manager rule using the putton on the Change Mgr. Tab of those rules. Once the Convert to Sync. Mgr. Rule button is pressed the existing rule will be closed and a Synch. Manager rule will be created in its place. The discussion on the PFKF Change Manager Rule help page contains more information on this conversion process. Existing Synch. Manager rules can be edited by double clicking on them with the mouse.