The Data Masker Create/Edit XML Masker Rule Form

This form is used to create and edit Data Masker XML Masker rules. XML Masker rules are designed to update the text content of an XML Element in a column of the XMLTYPE datatype with a values from one of the many available datasets. The title text and button label on the form will change as is appropriate to the create or edit mode. In the example screen shot above, the form is editing an existing XML Masker rule.

An XML Masker rule can be configured on a target table with a column of the XMLTYPE datatype or on a column with a text based datatype such as VARCHAR2 as long as the XML contained within that column has a valid format.

As discussed in detail in the XML Masker rule help file, there are four things which need to be specified when masking XML data. First the rule needs to know how to find the element of to be masked. Second, the rule needs to know what information needs to be masked - this is not necessarily the text value of the element as it could also be the text value of an attribute belonging to that element. Thirdly, the rule needs to know how to deal with XML namespaces and lastly the rule needs to know what information to use to mask the found element or attribute text - this last data is generated from the specified dataset. As can be seen in the image above, the XPath tab of the XML Masker rule form enables the first three options to be specified. The fourth option is specified on the DataSet tab.

Note: When the Mask by Wildcard Element Name option is chosen, the rule will mask the contents of every element with that name - no matter where it is found in the XML - including multiple XML elements of that name contained within the same record. If you require a more fine grained approach in which some elements are masked and some are not, then the Use Full XPath Specification option can be chosen. Any valid XPath statement can be specified for this option. For most XML masking operations, the simple Mask by Wildcard Element Name mode should be sufficient. if you have specialized requirements which necessitate the use of the Use Full XPath Specification option please contact the Data Masker Support Team for advice and assistance.

Important Note: XML namespaces, if used, strictly determine the processing rules in force and a XML processor configured with one namespace cannot process XML which has a different namespace - even if the XML structure is identical. The value will simply be ignored and no error will be returned - the data will not be masked. This is quite problematic if multiple namespaces are present in the XML in the individual rows of the table or if multiple namespaces are used within one XML entity. If the namespace is specified in the first element of the XML, the XML Masker rule has an option to figure this out and use the specified namespace for each XML row. If the namespace is not specified in the first element of the XML then you can specify a namespace manually - if there are multiple namespaces present in any one XML construct the data can still be masked - however this is very advanced topic and you should contact the Data Masker Support Team for assistance prior to attempting this.

Configuring the target table and column is a straightforward process. Use the mouse to select the table and column from the Table and Column tab. The choice of available tables is entirely determined by the Rule Controller with which the XML Masker rule is associated. Only tables from within the database and schema for which the Rule Controller is configured will be visible. If you do not see the tables you require, the database structure can be refreshed using the Refresh Tables and Indexes button on Options tab of the edit Rule Controller form.

The XML Masker Rule Dataset Tab 

The dataset which provides the replacement values is entered on the DataSet tab. It's use is identical to that of any other masking rule such as the Substitution rule. Each dataset has its own options and these will appear in the panel to the right of the selected dataset.

During execution, as the XML Masker rule processes each row, the generated replacement values will be substituted in place of the existing data in the XML element specified by either the element name or the full XPath (depending on the mode). The XML Masker rules help file has more information and examples.

The XML Masker Rule Where Clause Tab

Where Clause and sampling options are configured on the Where Clause tab and provide options which can be used when the choice of rows affected by the operation is to be based on a specific criteria. The Where Clause and Sampling help file contains a detailed discussion of these options. In the above example the NOT NULL option is set. This means that only the rows in which the XMLCOL value is NOT NULL will be affected by the masking operations.

Important Note: If multiple XML Masker rules are being applied to the same column (each with a different Where Clause) then the Where Clause Skip avoidance techinique discussed in the Where Clause and Sampling help file must be used. This methodology will ensure that implicit assumptions about the data content (for example, a GENDER field always contains only 'M' or 'F' when in fact some are NULL) do not result in some data items not having masking operations applied to them.

The XML Masker Rule Error Manager Tab

Usually any error returned by the running masking rule will cause the running masking set to halt and no further rules will be run. Occasionally it is desirable to "handle" such errors and permit execution on other rules to continue. For example, a common reason to ignore errors are masking rules which act on a table which may not be present in the target database. In the sample above, the rule is configured to ignore any errors which contain the text ORA-00942 or the text table or view does not exist. Any errors which do not contain this text will still cause the masking operations to halt.

The Change Managers Tab

Some rules can be imbedded in other rules which operate on them to massively parallelize the execution of the rule or to cascade changes in one table out to other tables. The XML Masker rule type can be converted to a type of change manager known as a Range Splitter rule. This rule type, will convert the normal XML Masker rule which operates in a single thread to a rule which will run multiple XML Masker rules on the same data. Inside the Range Splitter rule each copy of the XML Masker rule operates on a subsection (a range) of the normal data and all rules execute in parallel. 

Existing XML Masker rules can be edited by double clicking on them with the mouse. XML Masker rules are created by launching the New XML Masker rule form using the New Rule button located on the bottom of the Rules in Set tab.

How to Create a New XML Masker Rule