Skip to main content
Skip table of contents

Anonymization of the data

Basics

In principle, there are two different use cases for anonymization:

  1. The data should be passed on to CURSOR or a partner of CURSOR, so that errors can be reproduced on this data basis

  2. The data is to be imported into a development or acceptance system in a GDPR-compliant manner

The following goals are now to be achieved:

  • moving the tool to the server

  • processing of data as mass data updates as well as the execution of these statements in individual transactions

  • the configuration of the anonymization (preferably via the metadata of the application)

  • ensure that anonymization is performed on a database copy

configuration of the anonymization settings

  • The configuration is preset by CURSOR.

    • Only entities with transaction data can be anonymized.

    • Data marked as Customizing, Internal or System is retained because it is needed in both scenarios.

    • Key fields and primary keys cannot be anonymized (example: a lookup field on a business partner)

  • The configuration of transaction data can be changed by the customer administrator.
    In particular, the administrator can

    • Exclude entities from anonymization

    • Exclude fields from anonymization

    • There are two PropertyMapper entries
      one to define the maximum text length of the fields to be anonymized
      one to get the first n characters of the texts (performance critical)

  • The redundant fields in corresponding person and business partner are drawn equal if both are anonymized.

Starting anonymization

  • Via the Windows client you can use the call in the CMD environment in the bin directory of the Windows client

    POWERSHELL
    run anonymization

    a GUI can be opened, which first logs on to the productive system, as well as establishes the database connection to the database to be anonymized.
    The connection to the database to be anonymized is considered successful when it has been verified that

    • The database is not identical to the logged in database via the GUI

    • The version included in the database is of the same status as the registered version

    • The database is not configured as a productive database

  • Anonymization can also be started via automation without GUI

    POWERSHELL
    run anonymization <db username> <db password> <db jdbc-url> <crm user> <crm password>

    The connection to the database to be anonymized is considered successful when it has been verified that

    • The database is not identical to the logged in database via the GUI

    • The version included in the database is of the same status as the registered version

    • The database is not configured as a productive database

    • For the jdbc-url, note that there ; must be replaced by {SEMICOLON} and = by {EQUALS}. At these two characters the parameters are cut apart in batch files. Without this replacmenet, an execution is not possible!

  • A database is considered a non-productive database if the PropertyMapper entry has no
    id = '/de/cursor/jevi/server/system/SystemInfo$!!$Systemtype'
    value 'production system'.

Special logic for natural / legal persons

Main differences:

  • The logic of natural/legal person also applies to employees.
    Background of the changes: The processing of natural persons is now consistently the same for all roles (BP, AP, employ.). We do not consider an exception for the employee to be reasonable for the standard. Moreover, this would increase complexity and negatively affect runtime.

  • Other fields such as short name, salutation and signature have been included.

Introduction:
The names and first names of natural persons must be anonymized. This is not required for legal entities and should not be done for better traceability (e.g. for tests in the test system). The distinction is made by type (Mr. (M), Ms. (F), Divers (D), or Company (C)) on the Person, Business Partner, and Contact Person entities. M, F, D are natural persons. C is a legal entity. The project-specific flag (C2IsPrivPerson.Customer) is ignored here.

Person:

  • The field property "Data anonymization" is activated for the fields Name1-3 and MatchCode in the person. These fields are delegated to the business partner, contact person, and employee roles. Means the values are saved physically at the person and at the roles. If these are anonymized in the person, they are automatically anonymized in the role as well.

  • For natural person (type: M, F, D): Last name, first name, suffix, short name will be anonymized.

  • For legal entity (type C): Company, additional1, additional2, short name will NOT be anonymized.

Business partner:

  • The field property "Data anonymization" is activated for the fields Name1-3 (last name/company, first name/addition1, addition/addition2) and MatchCode (short name) in the Customer. These are not the delegated fields from the person, but additional fields in the BP parallel to the delegated fields from the person.

  • For these fields, the values would be taken from the corresponding person.

Contact person:

  • In the AP, the Last name/Company, First name/Add1, Addition/Addition2 and Short name fields are delegated from the person only. So if the corresponding person is anonymized, the fields in the AP are automatically anonymized as well.

  • In the AP there are additional fields Salutation (Salutation.ContactPerson) and Letter Salutation (LetterSalutation.ContactPerson). These would also be anonymized depending on the type for natural persons and not for legal entities.

Employee:

  • In the employee, the name, first name and short name fields are delegated from the person only. So if the corresponding person is anonymized, the fields in the AP are automatically anonymized as well.

  • The shortcut (login) would not be anonymized. This could still identify the employee.

  • In the employee itself there are additional fields Salutation.Employee and LetterSalutation.Employee and Signature.Employee in which the names are contained.
    For these fields, we do not see the need not to anonymize them for legal entities, as there are usually no type C (legal) employees. If desired, this is of course possible. In this case, we ask for a corresponding note.
    If these fields are not marked for anonymization in the employee, you can also see who it is here, as with the shortcut.

Generally for the entities person, business partner and contact person:
All other fields on the above entities are anonymized regardless of the natural or legal person if the "Data anonymization" field property is set accordingly. The logic is bound to the JurisitcPerson.PersonType field.

The functionality can be enabled with the PropertyMapper entry. Another requirement is that the fields should be anonymized at all (this is the default setting for these fields).

Oracle
SQL
INSERT into PropertyMapper (Pk, id, property, propertyType, principal, Active, CreateUser, UpdateUser, CustLayer, CreateDate, UpdateDate, propertyValue) 
VALUES ('AnonymizationHandler$!!$keepJuristicPersons', '/de/cursor/jevi/server/admin/anonymization/AnonymizationHandler$!!$keepJuristicPersonNames', '', 'SYSTEM', '', 1, 'TECH_USER', 'TECH_USER', 'CN', sysdate, sysdate, 'true') ;
MS-SQL
SQL
INSERT into PropertyMapper (Pk, id, property, propertyType, principal, Active, CreateUser, UpdateUser, CustLayer, CreateDate, UpdateDate, propertyValue) 
VALUES ('AnonymizationHandler$!!$keepJuristicPersons', '/de/cursor/jevi/server/admin/anonymization/AnonymizationHandler$!!$keepJuristicPersonNames', '', 'SYSTEM', '', 1, 'TECH_USER', 'TECH_USER', 'CN', getdate(), getdate(), 'true') ;



JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.