7/16/2021 Document 2076834.

1
Copyright (c) 2021, Oracle. All rights reserved. Oracle Confidential.

Using Oracle E-Business Suite Release 12.2 Data Masking Template with Oracle Database
11gR2 or 12cR1 with Oracle Enterprise Manager Cloud Control 13c (Doc ID 2076834.1)

This document provides an overview of data masking in Oracle E-Business Suite, along with instructions on how to set up
the Oracle E-Business Suite Release 12.2 data masking templates for the Oracle Data Masking and Subsetting Pack with
Oracle Enterprise Manager 13c. You should read and understand all content described here before you begin.

The most current version of this document is My Oracle Support Knowledge Document 2076834.1.

In This Document

This document is divided into the following sections:

Section 1: Overview
1.1 Introduction
1.2 Scope
1.3 Exempt Users
1.4 Packaging
Section 2: Using the Oracle E-Business Suite Template for the Data Masking and Subsetting Pack
2.1 Preparation and Setup
2.2 Using the Data Masking Template
Section 3: Customization
Section 4: Common Issues
Section 5: References
Appendix A: Types of Attributes Masked
Appendix B: Functionality Affected by Masking

There is a change log at the end of this document.

Section 1: Overview
1.1 Introduction
1.2 Scope

1.3 Exempt
Users
1.4 Packaging

1.1 Introduction

Data masking, also known as data scrambling or data anonymization, is the process of obscuring sensitive information
copied from a production database with realistic, scrubbed data based on masking rules, to a test or non-production
database. Data masking is ideal for virtually any situation where confidential or regulated data needs to be shared with
other non-production users who need access to some of the original data, but not necessarily to every column of every
table, especially if the information is protected by government or other regulations. Examples of non-production users
include internal application developers or external business partners such as offshore testing companies, suppliers, or
customers.

The Oracle E-Business Suite template for the Data Masking and Subsetting Pack, when applied with the Oracle Enterprise
Manager Data Masking tool, scrambles personally identifiable information (PII) and sensitive data in a copy of the
production system. The resulting database is devoid of specified PII and sensitive information but is still functionally useful
for customers to test patches or perform development. While some features may not behave consistently due to obscured
data, the intent of data masking is to leave the overall functionality of an application intact.

For more information on data masking, see the Oracle Data Masking and Subsetting Guide.

1.2 Scope

As with any security technology, you should understand the intended use cases of the Oracle E-Business Suite template for
the Data Masking and Subsetting Pack as well as its limitations. In addition, you should be aware of certain personally
identifiable information that is not masked.

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 1/14
7/16/2021 Document 2076834.1

Note: You are strongly encouraged to use the principle of least privilege when allowing users access to a masked
database. Give an end user only those privileges necessary to complete his or her work. For more information about
those privileges, refer to Before You Begin, Oracle Data Masking and Subsetting Guide.

Use Cases

The data masks from the Oracle E-Business Suite template are intended to:

Mask PII and other sensitive personal data associated with users.
Cover all product families shipped with Oracle E-Business Suite.
Run as a whole, since de-identification of a portion of a database is much less effective.

Limitations

The data masks provided do not handle the following situations:

While the data masks provided in the Oracle E-Business Suite template for the Data Masking Pack obscure exposed
public identifiers, they do not mask underlying IDs. As a result, if an attacker has a mechanism of associating an
internal database ID with an identity (for example, by having separate access to a custom application that exposes
a person ID along with a name) then that attacker, with access to the masked database, will be able to infer
identity to rows in the masked database.

A sufficiently knowledgeable attacker with full access to the masked database may still be able to infer the identity
of a user or row within the masked database by cross referencing other databases or by having outside knowledge
about a particular user's role or activities. For this reason, the data masks provided mask PII data and other
sensitive user information that alone is not considered PII but when associated with PII is considered sensitive. This
includes employment information, health information, personal information, or compensation.

Company-confidential information, such as financial results, financial forecasts, pricing, formulas, and so on, are not
covered by the Oracle E-Business Suite template for the Data Masking Pack.

The Oracle E-Business Suite template for the Data Masking and Subsetting Pack does not mask unstructured data.
While the data masks provided do remove some attachments and notes that are closely associated with people or
personal information, there may be sensitive data in notes, attachments, customer-defined flexfields, and other
unstructured data that are not masked. Since the provided data masks also do not cover data in custom tables or
custom applications that are not shipped with Oracle E-Business Suite, customers should provide their own
additional data masks to cover these cases. See the guidelines in Section 3: Customization before you create your
own data masks.

Unless the masked database goes through an import and export after masking the masked database may contain
the original data in unused blocks and in the free list. You should tightly control access to the database (.dbf) files
of the masked database at the OS level.

For more information, see Data Masking Task Sequence, Oracle Data Masking and Subsetting Guide. Refer to My
Oracle Support Knowledge Document 741818.1, Export/Import Process for Oracle E-Business Suite Release 12
Database Instances Using Oracle Database 11g Release 1 or 11g Release 2, for information on how to export and
import an Oracle E-Business Suite database.

Unmasked Personally Identifiable Information

The following objects, which may contain personally identifiable information, are scoped out of this version of the masks:

Grants data - While user names in Oracle E-Business Suite grants will still exist after masking, they cannot be
associated with other sensitive data.
Supplier names and PII - In the use case where suppliers are individuals, the data for suppliers may contain some
PII in these two specific scenarios:
Suppliers as Employees - These will be masked as part of the Employee Update Program concurrent
program launched at the end of the script.
Suppliers as External Users - PII associated with external users who are individuals is not masked.

1.3 Exempt Users

Since user names are considered PII, they are masked as part of the Oracle E-Business Suite template for the Data
Masking and Subsetting Pack. By default, however, certain seeded users such as SYSADMIN or GUEST are exempt from

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 2/14
7/16/2021 Document 2076834.1

masking. For example, an individual user name may become something like ASDSFKDFS after masking, but SYSADMIN
remains SYSADMIN. For a complete list of exempt seeded users, run the following SQL Select statement against your
instance:

select fu.user_id, fu.user_name

from applsys.fnd_user fu

where fu.user_id < 1000

order by fu.user_id;

Note: In the previous examples, user details represent a fictitious sample. Any similarity to actual persons, living or
dead, is purely coincidental and not intended in any manner.

Why Exempt Users From Masking?

It is necessary to exempt some users from data masking because if all user names are masked randomly, no username
will be available for testing after masking. Oracle E-Business Suite template for the Data Masking and Subsetting Pack
provides the ability to add additional users to the exemption list, allowing you to retain specific users in the target
database for testing purposes in the resulting masked database. Note, however, that exempt users are still masked in the
associated applications tables (for Oracle Trading Community Architecture and Oracle HRMS).

Creating a Pre-Masking Table Specifying Exempt Users

Before proceeding with the actual masking process, you can indicate which users to exempt by populating the
FND_USER_MASKING_EXEMPTIONS table. You can also use this table to change the names and/or passwords of exempt
users.

The Oracle E-Business Suite template for the Data Masking and Subsetting Pack provides two SQL scripts that you can use
to facilitate this exemption process:

fndusmaexcr.sql - Creates the FND_USER_MASKING_EXEMPTIONS table

fndusmaexpo.sql - Provides examples of how to populate the table

The following is a description of the FND_USER_MASKING_EXEMPTIONS table:

Name Null? Type

----------------------------------------- -------- ----------------------------

USER_ID NUMBER

SOURCE VARCHAR2(10)

CURRENT_NAME VARCHAR2(100)

NEW_NAME VARCHAR2(100)

NEW_PASSWD VARCHAR2(100)

The CURRENT_NAME column contains the name of the user to exempt from standard masking.
The NEW_NAME column is an optional column that when filled in, renames the user.
The NEW_PASSWD column is another optional column that when filled in, assigns the user a new password.

Use the fndusmaexcr.sql script to first create the FND_USER_MASKING_EXEMPTIONS table under the EBS_MASK
account before generating the mask and performing the masking operation. To exempt users beyond the default seeded
users, populate the FND_USER_MASKING_EXEMPTIONS table with the users you wish to exempt. The fndusmaexpo.sql
script contains examples of how to do this.

The fndusmaexcr.sql script adds certain seeded users to the exempt list, but does not change their passwords. If you
wish to change a seeded user's password, then update the value in the NEW_PASSWD column for that seeded user.

1.4 Packaging

The Oracle E-Business Suite template for the Data Masking and Subsetting Pack is delivered as an XML template and some
PL/SQL initialization scripts. These files are delivered through a zip file in Patch 30966900.

The Oracle E-Business Suite template for the Data Masking and Subsetting Pack contains the following components:

1. Application Data Model (ADM) template - Contains the description of the data model:

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 3/14
7/16/2021 Document 2076834.1

ADM_EBS12.2_JG_V2.0.X_EM_13c_Template.xml
or
ADM_EBS12.2_V2.0.X_EM_13c_Template.xml

2. Masking template - Contains the masking rules:

Mask_EBS12.2_JG_V2.0.X_EM_13c_Template.xml
or
Mask_EBS12.2_V2.0.X_EM_13c_Template.xml
 
3. ebs_masking_user_sysdba.sql - A script to create a new PDB user (EBS_MASK) that will perform the masking.

4. ebs_masking_user_apps.sql - A script to grant privilege to EBS_MASK user from the apps user.
 
5. ebs_pre_generate.sql - A script to run before the generation phase.
 
6. ebs_post_generate.sql - A script to clean up after the generation phase.
 
7. fndusmaexcr.sql - A script that creates the FND_USER_MASKING_EXEMPTIONS table.
 
8. fndusmaexpo.sql - A script that provides examples of how to populate the FND_USER_MASKING_EXEMPTIONS
table.

9. wf_hr_user_synch.sql - An optional script to synchronize data between the Workflow, FND and HR products
(specifically the FND_USER,PER_PEOPLE_F, AND WF_LOCAL_ROLES tables), post-masking. Use of this script is
described in Section 2.2.3.

Note: Depending on your current patch level, the data masking template may include columns that do not
exist in your production database. The instructions in 2.1.6 Pregenerate explain how to identify and remove
those columns from the template.

Note: The Oracle E-Business Suite template for the Data Masking and Subsetting Pack includes two versions
each of the ADM and Masking templates: a standard version and a JG version.
 

Use the standard version of the template if your production database includes the table
JE_ES_MODELO_190_ALL in the JE schema. Use the JG version of the template if your production database
includes the table JE_ES_MODELO_190_ALL in the JG schema. To find out which template to use, run the
following query:

select OWNER from all_tables where TABLE_NAME = 'JE_ES_MODELO_190_ALL';

Section 2: Using the Oracle E-Business Suite Template for the Data Masking and
Subsetting Pack

Prerequisites

Before you begin, familiarize yourself with the content in Masking Sensitive Data, Oracle Database Real
Application Testing User's Guide.
You must also have Oracle E-Business Suite and Oracle Enterprise Manager with the DB Plug-in installed.

The following is an outline of the steps for using the Oracle E-Business Suite Data Masking Pack. For an overview of
each specific step, please see Recommended Data Masking Workflow, Oracle Database Real Application Testing
User's Guide.

2.1 Preparation and Setup

2.1.1 Prepare Oracle Enterprise Manager 13c
2.1.2 Prepare Oracle E-Business Suite (Conditional)
2.1.3 Prepare the Database

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 4/14
7/16/2021 Document 2076834.1

2.1.4 QA Analysis
2.1.5 Create Masking User
2.1.6 Pregenerate
2.1.7 Generate the Mask
2.2 Using the Data Masking Template
2.2.1 Clone the Production Database
2.2.2 Execute the Mask
2.2.3 Post-Masking

2.1 Preparation and Setup

Perform the required steps in this section to prepare your Oracle Enterprise Manager 13c environment.

2.1.1 Prepare Oracle Enterprise Manager 13c

1. Ensure you have Oracle Enterprise Manager 13c.

2. Ensure that the Oracle Enterprise Manager Grid Control Agent is installed on the Oracle E-Business Suite
Release 12.2 database node you intend to mask. Refer to the Oracle Enterprise Manager 13c documentation
for more details.

3. Ensure the target database to be masked is discoverable from the Oracle Enterprise Manager 13 console.
Refer to the Oracle Enterprise Manager 13c documentation for more details.

Release Update:
4. The following table lists the minimum required Oracle Enterprise Manager (EM)

EM Database Plug-in Releases for EM 13c Minimum Required Release Update

13.4 13.4.0.2

13.3 13.3.x.x

13.2 N/A

You may apply the latest Release Update described in Enterprise Manager Cloud Control Updates: List of
Available RUs (Release Updates) and PSUs (Patch Set Updates) (Document 1605609.1).

2.1.2 Prepare Oracle E-Business Suite (Conditional)

Unzip the contents of the 12.2 Oracle E-Business Suite Data Masking and Subsetting Pack for Oracle Enterprise
Manager 13c, Patch 30966900.

2.1.3 Prepare the Database

There are currently no additional database patching requirements for using the data masking templates with Oracle
Database 11g Release 2 (11.2.0.4) or 12.1.

2.1.4 QA Analysis

Perform an analysis to determine which users to exempt from data masking and whether you need to populate the
pre-masked database with additional users. Create a pre-masking script to specify "exempt users" that will not be
masked in the FND User tables. See 1.3 Exempt Users for more details.

2.1.5 Create Masking User

Note: From this point on, you should perform the following tasks only on a cloned environment. We do not
recommend you execute these steps against a production environment.

On the cloned database which is targeted for masking, create a new user (EBS_MASK) with the
ebs_masking_user.sql script. You will be prompted for a password for new user EBS_MASK. This script should be
run as SYS:

oracle>sqlplus / as sysdba @ebs_masking_user.sql

Enter value for password: <enter password>

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 5/14
7/16/2021 Document 2076834.1

The generation and masking will be run as this user and the user should be dropped after a successful masking
run.

Note: If running on Oracle Database 11g Release 2, you may see the following error:
grant INHERIT PRIVILEGES ON USER ebs_mask to apps
      *
ERROR at line 1:
ORA-00990: missing or invalid privilege

This is expected as this privilege was introduced in Oracle Database 12c.

2.1.6 Pregenerate

1. Compile the objects in the database as follows:

select count(*) "nInvalidBefore", to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "TimeStamp"

from DBA_OBJECTS where STATUS = 'INVALID'

exec sys.utl_recomp.recomp_parallel;

select count(*) "nInvalidAfter", to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "TimeStamp"

from DBA_OBJECTS where STATUS = 'INVALID'

Rerun these two SQL statements until the results from the first statement, which selects the count of
invalids, remains the same.
 

2. Run the fndusmaexcr.sql script as the EBS_MASK user to create the FND_USER_MASKING_EXEMPTIONS
table so that the generation step that follows can successfully validate the mask. Note that for this step you
do not need to populate additional exempt users, as only the table structure is required.
 

3. Run the ebs_pre_generate.sql script as the EBS_MASK user to temporarily create tables required so that the
generation step that follows can successfully validate the mask.

2.1.7 Generate the Mask

Generating the mask is a multi-step process that is comprised of three main tasks:

Task 1: Importing the ADM template and verifying it

Task 2: Importing the Data Masking template
Task 3: Generating the masking script

Task 1: Importing the ADM Template and Verifying it

1. In Oracle Enterprise Manager, navigate to the Enterprise menu > Quality Management > Application
Data Modeling.
Import the XML Application Data Model (ADM) template. This template was downloaded with Patch
30966900. See 1.4 Packaging for more information on how to choose the correct file.
Make sure to specify a name, such as "EBS V1.1 - myDB", and database when you import the template.
Refer to Importing and Exporting an Application Data Model, Oracle Database Testing Guide 12c Release 1
(12.1), for more details.

Note: You may get a long list of warnings of the following form, which you may safely ignore:

Import completed, but with the following issues:

...

Duplicate or invalid sensitive column type:

Account Name

...

Duplicate or invalid sensitive column type:

Work permit Number

...

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 6/14
7/16/2021 Document 2076834.1

2. From the Application Data Modeling page, perform a Verify action using the Actions menu on the
Application Data Model that you just imported. Create and launch a Verification Job against the APPS
account on the next page. After successful completion of the job, the Source Database Verification Status for
the Application Data Model should display as Valid.
 

Note: You may get the following message in Oracle Enterprise Manager while trying to verify the
Application Data Manager:
 
"You do not have sufficient privileges for deploying or accessing the Test Data Management package
needed to perform this action. The privileges needed are: Create Any Procedure and Grant Any Object
Privilege (for Deployment), Execute Any Procedure (for Access)."
 
If you get this message, grant the APPS user these privileges and then run the Verify action. You may
revoke the privileges after verification.

Task 2: Importing the Data Masking Template

1. In Oracle Enterprise Manager, navigate to the Data Masking Definitions page. Import the XML Masking
Template, selecting the Application Data Model (ADM) from the list of available ADMs created earlier. You
may optionally enter a new name for the mask.
2. As the EBS_MASK user, edit the masking definition (it may take a few minutes to open). The UI reports any
columns that do not exist in the associated database. Note these columns and remove them from the
masking definition. If the column JE_ES_MODELO_190_ALL.VENDOR_NIF is missing, refer to the note in 1.4
Packaging.

Task 3: Generating the Masking Script

1. Generate the script as the EBS_MASK user, choosing Mask In-Database for the Script Generation Options.
Since this step may take up to 4 hours, be sure to keep your browser window open and active for the entire
generation period.

Note: You may optionally use EM CLI for the generate step. See Oracle Enterprise Manager
Command Line Interface for more information.

Sample commands:
Admin login:

emcli login
-username=<maskadmin>

List all the definitions that match the search criteria:

emcli list_masking_definitions -definition_name=Mask%

Create Named Credential:

emcli create_named_credential -cred_name=MYCREDS

-auth_target_type=oracle_database -cred_type=DBCreds

-attributes="DBUserName:ebs_mask;DBPassword:<password>;DBRole:NORMAL"

Generate Masking Script:

emcli generate_masking_script -definition_name=EBS_Mask1 -

credential_name=MYCREDS

2. Check for errors. You may see warnings about the data distribution for certain columns being masked using
the Shuffle format.
3. If you plan to execute the masking script generated in the prior step (step 1) on a different instance of the
database, you must run the ebs_post_generate.sql script as the EBS_MASK user to remove the
temporary tables created in 2.1.6 Pregenerate steps 2 and 3 by the ebs_pre_generate.sql script.
Otherwise, the masking script execution itself performs the cleanup for you.

2.2 Using the Data Masking Template

Perform the steps in this section to apply the data masking template to a clone of the production database.

2.2.1 Clone the Production Database

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 7/14
7/16/2021 Document 2076834.1

1. Clone the database you are planning to mask. See My Oracle Support Knowledge Document 1383621.1,
Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone, for additional information.

Warning: Data masking is irreversible, and should never be run on a production database.

2. It is important to change the credentials associated with the database in your test environments. For a list of
the database users who should have their passwords changed, refer to Secure Configuration, Oracle E-
Business Suite Security Guide.
3. Switch the database over to using local users. Since the masking process changes the user names, you
should not associate the database with LDAP, Oracle Single Sign-On (SSO), or Oracle Access Manager (OAM)
during or after a mask. If you have registered Oracle E-Business Suite with Oracle Internet Directory and
Oracle Access Manager or Oracle Single Sign-On for access management integration, you need to remove
the references from this environment prior to deploying data masking. To remove the references from an
Oracle E-Business Suite Environment to Oracle Internet Directory and Oracle Access Manager or Oracle
Single Sign-On, execute the following steps:
a. Remove the references to the Oracle Access Manager environment:

$txkrun.pl -script=SetOAMReg -removeoamreferences=yes

b. Remove the references to the Oracle Internet Directory environment. For details, refer to "A3.
Remove References" in My Oracle Support Knowledge Document 1371932.1, Integrating Oracle E-
Business Suite Release 12.2 with Oracle Internet Directory 11gR1.

$FND_TOP/bin/txkrun.pl -script=SetSSOReg -removereferences=yes

Refer to My Oracle Support Knowledge Document 1576425.1, Integrating Oracle E-Business Suite
Release 12.2 with Oracle Access Manager 11gR2 (11.1.2) using Oracle E-Business Suite AccessGate,
for more information.

Note: After performing the 'removereferences' command in an environment with an Oracle

Access Manager 11gR1 with mod_osso configuration, you should also delete the Oracle E-
Business Suite environment (OSSO Agent) from the Oracle Access Manager console. Refer to
Deleting an Application Domain and its Content, Oracle Fusion Middleware Administrator's Guide
for Oracle Access Manager with Oracle Security Token Service 11g Release 1 (11.1.7), for more
information.

Note: If you have a multi-node deployment then run the deregistration utility mentioned in 3.1
of Document 1370938.1, Registering Oracle E-Business Suite Release 12 with Oracle Internet
Directory 11gR1 and Single Sign-On, on each Web Node. The middle-tier services need to be
restarted after removing the references.

2.2.2 Execute the Mask

Tip: If you encounter a failure and are able to correct the cause of error, such as by extending a tablespace,
you may be able to rerun the script from where you left off without a refresh. If the primary masking completes
successfully but errors in post-masking, you may need to re-create and re-populate the
FND_USER_MASKING_EXEMPTIONS table before you run the mask each time (see step 3 of this section).

1. Ensure there is enough free space in the TEMP and SYSTEM tablespaces to accommodate 1-2 times the
largest table being masked. The table that is the largest will depend on your implementation, but it is often
the WF_USER_LOCAL_ROLES, WF_LOCAL_ROLES, or HZ_PERSON_PROFILES table.
2. Install the predefined masking formats as the EBS_MASK user. See Installing the DM_FMTLIB Package,
Oracle Database Real Application Testing User's Guide 11g Release 2 (11.2).

Note: Please run dm_fmtlib_pkgbody.sql instead of dm_fmtlib_pkgbody.plb as described in

the previous documentation reference. The two scripts to install are:
$PLUGIN_HOME/sql/db/latest/masking/dm_fmtlib_pkgdef.sql
and
$PLUGIN_HOME/sql/db/latest/masking/dm_fmtlib_pkgbody.sql

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 8/14
7/16/2021 Document 2076834.1

3. Run the fndusmaexcr.sql script as the EBS_MASK user to create the FND_USER_MASKING_EXEMPTIONS
table. Add any additional exempt User IDs by running the pre-masking script created previously. The
fndusmaexpo.sql script contains examples of how to populate the FND_USER_MASKING_EXEMPTIONS
table.
4. Shut down the application tier server processes using the adstpall script. For more information about this
script, refer to the Oracle E-Business Suite Maintenance Guide.
5. Within the data masking console in Oracle Enterprise Manager, run the mask for the script generated
previously using the EBS_MASK user. Check "The selected target is not a production database" option on the
schedule masking job page.
6. Rerun 'Compile the objects in the database ' as described in step 1 of 2.1.6 Pregenerate. Make note of any
additional uncompiled objects.
7. Start up the middle tier server processes using the adstrtal script. For more information about this script,
refer to the Oracle E-Business Suite Maintenance Guide. Note that several concurrent requests are started
during the mask (Employee Update Program and DQM Staging Program). Verify that these programs
complete successfully after bringing up the Concurrent Manager. Note that the Employee Update Program
may log errors of "Update of Name was not done as the update would result in a duplicate supplier record".
8. (Optional) Save the script for later use. You can now run this script to mask a clone of the same database
without requiring an Oracle Enterprise Manager agent. Run the script using SQL*Plus against any database
containing the same exact objects.

Note: Refer to Section 4: Common Issues for a list of known issues that may arise during the execution of the
mask.

2.2.3 Post-Masking Steps

You should now test the mask for any functional issues. Be aware that regression tests may not work in this case
because many of the names in the database have changed values.

Note: Refer to Section 4: Common Issues for a list of known issues that may arise during the testing of the
mask.

Optionally, you may perform a further step as follows. By default, Oracle E-Business Suite data masking does not
synchronize scrambled personal data (such as names, phone numbers, and email addresses) between the Oracle
Workflow, FND, and HR products — specifically, the FND_USER, PER_PEOPLE_F, and WF_LOCAL_ROLES tables. If
such synchronization is required, after the primary masking job has completed you can run the included
wf_hr_user_synch.sql script as the apps user to synchronize these tables using a parallel process. After running
this script, you should check the generated log file (wfhrusersynch.log) for any ORA- errors.

Section 3: Customization
The Oracle E-Business Suite data masking templates are intended to provide a basis for your masking
requirements. You will likely need to add, delete, or modify rules in the templates to satisfy your specific
requirements. You should do so in a manner that minimizes effort when bringing in new versions of the Oracle E-
Business Suite data masking template.

To remove a rule from the Oracle E-Business Suite data masking template, be sure to track the rule that you
remove.
To make an addition to the template, whether to mask custom or Oracle E-Business Suite tables, add it to a
new template.
To update a rule that already exists within the template, remove the rule from the Oracle E-Business Suite
template and add it to a new template before updating the rule.

Note: See Section 4: Common Issues for the description of a possible problem and its
workaround with columns reordering after an export and import of a custom mask.

Warning: Due to the complexity of the Oracle E-Business Suite data model, customizing data masking
templates can lead to unpredictable results. Oracle Support and Oracle E-Business Suite Development cannot
provide instructions or diagnostic assistance for any issues that may arise from deploying a custom data

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 9/14
7/16/2021 Document 2076834.1

masking template. See My Oracle Support Knowledge Document 122452.1, Global Customer Services
Customization Guidelines, for more information.

Section 4: Common Issues

The following tables list known issues that may arise during the execution and testing phases of the mask as well
as possible causes and solutions.

Execution Phase

Issue Cause / Solution

ORA-01427 (single-row subquery

returns more than one row) or ORA-
01422 (exact fetch returns more than
This issue is fixed in the latest template patch.
requested number of rows) while
running ebs_pre_generate.sql or
running the mask

Perform a new clone and execute the template without the

customizations by running only the Oracle E-Business Suite-supplied
Customizing template results in failure
template. If the template executes and passes tests with no errors,
verify the customizations that were previously applied to the template.

ORA-00060: deadlock detected while Usually caused by another process still running. Make sure there are
waiting for resource no application tier or LDAP services still up.

You may need more space in the <Tablespace> tablespace to

Unable to extend ... in tablespace
accommodate the masking process. See 2.2.2 Execute the Mask for
<Tablespace>
more information.

This is often just a spurious, non-reproducible error. If this occurs as

ORA-03114: not connected to ORACLE part of the pre-generate or post-masking steps, you may often work
during 'exec around this issue by bouncing the database. If this happens during the
sys.utl_recomp.recomp_parallel' masking itself, you can usually reclone or refresh and successfully
rerun the masking.

This can occur when an Oracle Text index is corrupted or in an invalid

state. Use "alter index <index_name> rebuild" before running the
script. You can query indexes in failed status using the following SQL:

select index_name, domidx_status, domidx_opstatus,

funcidx_status, status from dba_indexes

where index_type='DOMAIN';

ORA-29855: error occurred in the

execution of ODCIINDEXCREATE If this does not work, it is likely because you have a corrupt DOMAIN /
routine TEXT index. These indexes should be dropped and recreated. For
specific issues with HR.PER_EMPDIR_PEOPLE_N1, drop and recreate it
before generation due to a reference in post masking. All other
DOMAIN indexes may be dropped before generating and replaced
afterwards if used. See My Oracle Support Knowledge Document
743720.1, Oracle Text: Re-installation and Rebuilding of Applications
R12 Oracle Text Indexes, for instructions on how to re-create Oracle E-
Business Suite Text indexes.

ORA-00054: resource busy and acquire Either of the listed errors may occur when executing the data masking
with NOWAIT specified or timeout job. There are two potential causes with separate resolutions:
expired

Cause: Another process is running that conflicts with the data
ORA-0060: deadlock detected while masking job.
waiting for resource
Solution: Shutdown the database, then restart in RESTRICTED mode
before restarting the data masking job. This should eliminate any
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 10/14
7/16/2021 Document 2076834.1

future occurrence of these errors. After the data masking job

completes, shutdown the database and restart it in NORMAL mode.

Cause: This error may occur when executing the data masking job in
parallel.
ORA-00942: table or view does not
exist Solution: Add the following statement to the beginning of the data
masking script:

ALTER SESSION SET QUERY_REWRITE_ENBLED=FALSE;

This error occurs during the execution of the data masking job after
the population of the FND_USER_MASKING_EXEMPTIONS table.

To test for this issue, execute the following:

select fume.current_name, count(1)

from system.fnd_user_masking_exemptions fume

ORA-01422: exact fetch returns more group by fume.current_name

than requested number of row

having count(1) > 1;

If the SQL returns one row, then you have duplicate entries in the
FND_USER_MASKING EXEMPTIONS table.

Solution: Remove duplicate names from the

FND_USER_MASKING_EXEMPTIONS table.

ORA-04088: error during execution of

trigger
'APPS.PAY_ELEMENT_ENTRIES_F_WHO'

alter table The cause of this error is unknown.

HR.PAY_ELEMENT_ENTRIES_F enable
constraint Workaround: Re-execute the post-masking scripts manually against

PAY_ELEMENT_ENTRIES_F_FK3 the EBS_MASK account.

ERROR at line 1: If you encounter this issue please log an SR with Oracle Support.
ORA-02298: cannot
validate
(HR.PAY_ELEMENT_ENTRIES_F_FK3) -
parent keys not
found

Testing Phase

Issue Cause / Solution

Tables and columns in a data mask may get out of order after an
export and then an import. PER_ALL_PEOPLE_F should always be the
first table listed for the columns to be masked in the template.

Certain columns (such as Workaround:

BEN_CWB_PERSON_INFO.BRIEF_NAME)
are not masked correctly after an export 1. If you are adding columns that have no dependencies on the
and import. current mask, use a separate mask to add them.

2. If you need to export and import an Oracle E-Business Suite

mask, ensure that the PER_ALL_PEOPLE_F columns are on top
before you re-import. Reorder the XML if necessary.

Columns that used to contain values are Generally caused by 'orphan rows', where the mask has defined a
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 11/14
7/16/2021 Document 2076834.1

now null column that should be a foreign key or child of a masked column, but
the value in the child table did not have a match in the parent. The
'orphan rows' can be caused by corrupt data within the system. With
the default setting that the Oracle E-Business Suite data mask runs
with, these values are replaced with null if the column is nullable. If
the column is not nullable, the value will be replaced with a fixed
masked value.

You may need to restart your browser if you have been using the
'Invalid Session' at the login screen browser to connect to the pre-masked database. If that's not the
problem, then you may need to run AutoConfig.

Section 5: References
The following resources may be helpful in learning more about and setting up data masking:

Data Masking, Oracle Data Masking and Subsetting Guide

Secure Configuration, Oracle E-Business Suite Security Guide
Oracle Enterprise Manager Command Line Interface 13c Release 1
Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token
Service 11g Release 1 (11.1.1.7)
Oracle E-Business Suite Maintenance Guide
My Oracle Support knowledge documents:
Document 1383621.1, Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone
Document 1371932.1, Integrating Oracle E-Business Suite Release 12.2 with Oracle Internet Directory
11gR1
Document 122452.1, Global Customer Services Customization Guidelines
Oracle Data Masking and Subsetting Pack
Oracle E-Business Suite Release 12.2 Data Masking Pack, Patch 30966900
Oracle Enterprise Manager 12c with Database Plug-in 12.1.0.3
Oracle Enterprise Manager 12c with Database Plug-in 12.1.0.2
Oracle Enterprise Manager 12c Release 12.1.0.2 with OMS Patch 14460708 and Agent Patch 14725552
Oracle Contracts Core (OKC) Patch 10053630

Appendix A: Types of Attributes Masked

The following information lists the attributes that are masked in the Oracle E-Business Suite Data Masking Pack.

Sensitive Data Attributes

Compensation
Employment Details
Nationality / Citizenship
Health Information
Personal Information
Mother's Maiden Name
Password
Encryption Keys
Security Vulnerabilities
Audit Information
Session Information

Personally Identifiable Attributes (PII)

Person Name
Maiden Name
Business Address (Note that addresses are masked by obscuring the number at the street level (or country
equivalent), but not at the city/county, state, or zip code level.)
Business Telephone Number
Business Email Address
Custom Name
Employee Number
User Global Identifier
https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 12/14
7/16/2021 Document 2076834.1

Party Number or Customer Number

Account Name
Mail Stop
GPS Location
Student Examination Hall Ticket Number
Club Membership ID
Library Card Number
Identity Card Number
Instant Messaging Address
Web Site
National Identifier
Passport Number
Driver's License Number
Personal Address (Note that addresses are masked by obscuring the number at the street level (or country
equivalent), but not at the city/county, state, or zip code level.)
Personal Telephone Number
Personal Email Address
Visa Number or Work Permit
Bank Account Number
Card Number (credit or debit card number)
Tax Registration Number or National Taxpayer Identifier
Person Identification Number

Appendix B: Functionality Affected by Masking

The following list describes functionality known not to work properly in a masked database.

General

Third party integrations generally will not work after masking as they often contain or reference data and
credentials that have been obscured in the masked database. Specific instances of these integrations are
called out in the remainder of this section.

Applications Technology

Masking disables login and disassociates responsibilities for all accounts that are masked. The only accounts
that are not masked are:
Seeded accounts (such as SYSADMIN, GUEST, etc.)
Additional accounts listed as exempt from masking.

Workflows that contain masked users will not work correctly. Workflows will work only if all participating
workflow users are exempt from masking.
Single Sign-On (SSO), Oracle Access Manager (OAM), and LDAP-synch should be turned off, as they will not
work correctly after masking. See step 3 in 2.2.1 Clone the Production Database for information on
converting users over to local mode.

Oracle HRMS

Payroll results will not be in sync with the payroll engine calculations.

Oracle Trading Community Architecture

Dun & Bradstreet integration will not behave correctly after masking.

Financial Management

Oracle Payments Credit Card functionality will be affected as follows:

Credit card encryption will be turned off after masking.
Processing of payment files by external systems will fail.
Certain Payments functionality (such as searches) will require the IBY_REGENERATE_HASH
concurrent program to be run ('Re-generate Payments Hash Data').

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 13/14
7/16/2021 Document 2076834.1

Country Specific Bank Account Number validations may fail. Because of this, the profile option
CE_DISABLE_BANK_VAL should be set to Yes.

Change Log

Date Description

2020-10-
Updated step 4 in Section 2.1.1.
21

2020-10-
Added one issue for ORA-01427 and ORA-01422 in Section 4.
02

2020-10-
Added information about the new masking template patch 30966900 and related details.
01

Updated to Oracle Enterprise Manager Cloud Control 13c throughout document, adding
2020-02-
certified versions 13.3 and 13.2.
06
Made minor formatting fixes throughout document.

2018-07-
Step 3 of section 2.2.1 Clone the Production Database.
25

2016-07- Added notebox to 2.1.7 task 1 step 2 in Section 2.

08 Removed second cause/solution for ORA-00054/ORA-00060 in Section 4.

2016-06-
Initial publication.
22

My Oracle Support Knowledge Document 2076834.1 by Oracle E-Business Suite Development.

Copyright © 2016, 2020, Oracle and/or its affiliates.

Didn't find what you are looking for?

https://support.oracle.com/epmos/faces/DocumentDisplay?_adf.ctrl-state=hu68jvci1_4&id=2076834.1 14/14