Every implementation of our software can throw up unique test data masking requirements. In this blog, one of our senior consultants Adan Willemse explains how Infotype 41 data had to be accurately masked in the test system, without devaluing the quality of the test data. In years gone by, this would have had us reaching for the ABAP exit functionality to code a solution, but with Data Secure 3, powerful masking rules can be built by anyone with knowledge of the data model, without the need for programming skills.
- Paul Hammersley, VP of ALM Portfolio at EPI-USE Labs
SAP HCM customers are familiar with the Infotype 41 Date Specifications screen that stores many of an employee's key dates. We have blogged about the challenges of working with this infotype in the past from a reporting standpoint (see this blog about Fixing duplicate line reporting in SAP HCM).
As we explain in that blog, Infotype 0041 permits storage of customer-specific dates. During configuration, each customer determines the date types that work best for them. In the example shown above, the associate has seven different date types stored as Date type 01, 04, 25, 50, C1, F3 and Z1, listed in alpha-numerical order. However, unlike traditional infotypes such as infotype 0002 Personal Data, in which each field only stores a singular value (for example, the first name field only stores first names in the P0002-VORNA field), the fields on this screen can store variable data. In Infotype 41, date type 50 could appear in the first box, the fourth box, the last, etc. depending on how many date types are on the screen.
This presented a challenge recently when I needed to mask the values of only certain sensitive dates stored on the Infotype 41 Date Specifications infotype. Because of the way that Infotype 41 Date Specifications are designed, I couldn’t be sure which field the date I needed to mask would be saved in (DAT01 - DAT12), only that it would be in one of the the “DAT**” fields that corresponds to the “DAR**” field that equals “50” in my case. In other words, the date field that corresponds to Date Type 50 for Service year entry.
To give you an idea of what this looks like behind the scenes, I’ve included below a screenshot as viewed from the SAP Data Browser (transaction code SE16N) showing the values from this infotype and how its corresponding DAT** field assignment varies from employee to employee. As you can see, Date Type 50 values are saved in DAT05 for some employees, DAT06 and DAT07 for others.
I used Data Secure 3 to solve the problem, using a standard date randomizing function, twelve filtered integrity maps and one rule added into my redaction policy.
I created twelve Integrity Maps, one for every Date Field on infotype 0041. (DAT01 through DAT12). Each Integrity Map had a Date Type Filter on the corresponding DAR** field, only allowing through records of Date Type 50.
Twelve Integrity Maps
To ensure dates were always masked, I associated each integrity map with the default Random Date transformation function.
To be able to roll back data after I test my masking rule, I used Data Sync Object Sync to back up my set of employees to a file on the Application Server. I tested, using Object Masking for the ERP_PERSON Object, and specifying my policy, only activated the rule I was interested in. Because I selected Field Level Audit for in-place Object Masking, I could easily see the ‘before’ and ‘after’ values; the original date values, and again after they were randomized.
Data Secure is a flexible product that is easy to use for ‘interesting’ cases such as these, where the exact field that must be masked varies from employee to employee. WIthin less than an hour, I could set up and test the masking of infotype 0041.