Importing References in One Identity

Question

I've got a SQL HR database with two tables. One table has general HR data, the other has departments. The HR table contains a field department that contains the number of the department in the departments table. Basic foreign key reference. I can import the users into One Identity and I can import the departments but I'm not sure how or where I can flow the reference so that uid_department on the user is set to the correct department as indicated by the HR table. One way I could go it is to flow the number into One Identity on the person object then create a template and I think I can cajole it into selecting the right department and updating the uid_department field. Is there a better way to do this where I can import and it will automatically populate the department properly? If you can point me at any documentation that would good to. 
 
 Thanks

Markus Weiss-Ehlers · Accepted Answer

Hi, 
 you could check some of the videos on the One Identity channel to get some more information https://www.youtube.com/playlist?list=PL242czeZwlAlLnykigzKSjywrA8ZkaxLA . 
 For your case, I suggest to take a look at videos number #9 and #10 from the 7 Bits series. 
 https://www.youtube.com/watch?v=hyt1gkkwlrc&index=9&list=PL242czeZwlAlLnykigzKSjywrA8ZkaxLA 
 https://www.youtube.com/watch?v=k2JJbfOLZSU&index=10&list=PL242czeZwlAlLnykigzKSjywrA8ZkaxLA 
 What you need is a virtual property on the left (the OneIM side) of your mapping from type "Key resolution by reference". 
 If you specify the relations in your SQL HR database connection, the system should ask you about replacing the normal mapping rule with reference mapping during a drag-n-drop operation to create a mapping rule (like the following). 
 
 Take a look at the following screenshot demonstrating a similar case where the country code coun_code from my MySQL database has to be mapped to Person.UID_DialogCountry in my OneIM database. 
 
 Hth

TimStaddon · Answer

Hi, 
 
Are you using Version 7.1 or later? 
 
I have set up something similar to this in a test lab with a dummy HRMS database. In mine, the department ID is an autonumber. So, a description of a department might change, but the number assigned to it is permanent. For this reason, the department table sync didn't need to do object matching on any attribute other than the autonumber. 
 
So I created a virtual property for a custom property as follows on the "HRDepartment to OneIM Department" mapping: 
 
Virtual Property Name: VRT_CustomProperty03AsDecimal 
Display Name: DeptID in CustomProperty03 
Base Property: CustomProperty03 
New Data Type: Decimal - fix point number 
 
The object matching rule was added as follows: 
 
Rule Name: VRT_CustomProperty03AsDecimal_DeptID 
Display Name: Spare field no. 03 <-> DeptID 
Case Sensitive: checked 
 
One Identity Manager Schema Property: VRT_CustomProperty03AsDecimal 
Target System Schema property: DeptID 
 
Step 2: on the Person sync, create a "key conversion by reference" custom property: 
 
Virtual Property Name: UID_Department_from_CustomProperty03 
Base Property: CustomProperty03 
 
Once you've got this, then you can resolve UID_Department from DeptID. 
 
One way to do that is translate the DeptID to a virtual property in your Person import, and use that to look up the UID_Department during the sync. 
 
Another way to do it is by setting a custom property with DeptID from the employee table, and then use a template on the custom property to look up UID_Department. 
 
I cannot advise which of the two approaches is best to take; the answer to that question depends on factors like, how often does your department structure change and how often do people move from one department to another; how many departments and people do you have....

Markus Weiss-Ehlers · Answer

You are missing the schema classes these UIDs are pointing to in your sync project. 
 Perhaps, they have been removed from the project during the last project activation, because you haven't used them. 
 Just reload the schema for the OneIM connector and things start to work as expected. 
 To prevent a schema class from being removed, you can pin it during the activation / shrink operation.