• State Verified Answer
  • Replies 4 replies
  • Subscribers 93 subscribers
  • Views 1593 views
  • Users 0 members are here
Options
Related

Understand the default DN syntax the SAP Connector uses for Person

muzammil
over 3 years ago

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
  • 0 over 3 years ago

    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.

  • 0 over 3 years ago in reply to Markus Weiss-Ehlers

    Thanks for the response Markus.

    What I had done earlier was made the EmployeeID as the primary rule and DistinguishedName as Alternative for object mapping.

    Also, I had enabled "Do not override" for DistinguishedName at the OneIM side. This had resolved the issue for me and it is able to match the objects correctly and update/insert correctly as well. However, we will not get the updated DistinguishedName.

    Will this have any undesired effect down the line? We are using the employeeID to identify the person, so will DistinguishedName (not being updated) cause any issues elsewhere within the Out of box connectors or workflows or processes, or it should be fine? Is it a requirement elsewhere?

  • +1 over 3 years ago in reply to muzammil

    Why not removing the secondary matching rule for the DN?

    Honestly, I do not know if there are any additional requirements in regard to the DN. But from my personal view only, this should be no issue.

Reply Children