Understand the default DN syntax the SAP Connector uses for Person

Hi,

Trust you are safe and healthy.

The variable "vrtdistinguishedName" in the mapping "Employee" from the SAP Connector using the HCM employees objects template, generates a default value like "CN=<EmployeeID>,OU=000,OU=2020-03-01,OU=9999-12-31,O=HREmployee_Active,DC=XXX,DC=XX,DC=XXX".

Anyone knows which SAP date variables is it using within the syntax for vrtdistinguishedName and why? I believe they are either one of the startdate/validitystart/joindate variables.

The issue is everytime these date change, it will try to create a new employee record since the distinguishedName changed., which isn't desired.Just wanted to understand why have dates within distinguishedName that will change instead of something more unique tat won't change?

Is it advisable to change the syntax of distinguishedName? Are there any dependencies elsewhere? and how can I update all the distinguishedName column for Person records since it is a locked column without removing and re-synchronizing the employees?

Version: 8.1 SP1.

Parents
  • The DN uses the SAP HR fields BEGDA and ENDDA.

    The thing is that SAP HR creates a new entry for the personal data if anything changes. This could be the work contract, the address, the assignment to a new department, or the assignment of a new job position. At this point in time, the old personal data record will be terminated and a new one will be created for the same personal ID. Therefore the personal ID is not a unique key, hence the use of the DN as a unique key is a requirement for the synchronization.

    So it's up to you to adapt your mapping accordingly, if you do not want to import the historical data. But the virtual DN shouldn't be touched.

Reply
  • The DN uses the SAP HR fields BEGDA and ENDDA.

    The thing is that SAP HR creates a new entry for the personal data if anything changes. This could be the work contract, the address, the assignment to a new department, or the assignment of a new job position. At this point in time, the old personal data record will be terminated and a new one will be created for the same personal ID. Therefore the personal ID is not a unique key, hence the use of the DN as a unique key is a requirement for the synchronization.

    So it's up to you to adapt your mapping accordingly, if you do not want to import the historical data. But the virtual DN shouldn't be touched.

Children