TIM is a little strange when it comes to feeding supervisors into the system. It all boils down to the fact that objects in TIM get assigned a random ID as part of their DN called the erglobalID. So in order to specify who a supervisor is on a persons' record, you must first create a record for that supervisor in TIM. It's sort of a chicken or egg problem. To solve this problem users are fed into TIM in two phases. The 1st round brings all users into TIM regardless of whether they are management or not. The next phase should update the supervisor attribute for all the users. To do that your second Feed into TIM must do a lookup to the TIM LDAP to resolve what the manager DN actually is. It might look something like:
erglobalid=8587940495056130390,ou=0,ou=people,erglobalid=00000000000000000000,ou=CA,dc=ca,dc=com
So the assembly line must get an attribute about the manager that it can then do a lookup on to get this DN. This then gets populated in the manager attribute in the TIM LDAP. Keep in mind that in TIM it is referred to as ersupervisor, but it's really manager on the back end. In my sandbox system, my employee feed source contains the employee ID for the manager in user record so when I run an assembly line to update the manager attr in TIM I simply do a lookup for the DN where the manager attribute in Work matches the employeenumber attr in TIM. For that person I get the DN which is what the Feed populates into TIM. This is done using the DSMLv2 Event Handler.
In class today we did the feed a bit different. While the initial feed used the event handler the second feed for the managers was done using TDI to push people right into LDAP. There were a couple of lookups to LDAP to resolve the DNs of the user and then the manager, then one finally update connector to the LDAP top update the record.
It seems like none of these training classes really go into what solutions work best in what scenarios. So far none of the classes I've been to talk much about the best way to develop a solution given a particular case. Supposedly the Advanced ITIM 4.6 Implementation Workshop goes into that level of work. We shall see because I plan on being there.
3 comments:
Hi Charles,
This means only one level of hierarchy (Supervisor <- Employee) can be fed to ITIM via the Feed, right?
If I have complex reporting hierarchies for erSupervisor (Multi-level top-to-bottom or random assignment of supervisors), I find it hard to extract our ALL the Supervisors and feed them first, BEFORE the actual employees who report to those Supervisors.
Somehow I find this architecture governed by the product very limiting.
Your thoughts?
I guess the idea is that everyone has a direct report. So the initial feed simply loads all people into TIM whether they are management at any level or non-supervisor type employees. So the second feed or iteration populates each persons' Manager attribute with their direct report. This way any multiple levels are handled simply because everyone reports to somebody.
Now I'm sure it's possible that an employee reports to more than one person. But there is usually one "primary" supervisor for an employee. I mean can you imagine asking two bosses for a vacation day and letting them fight it out between them whether to approve or disapprove of your day off?
TIM is capable of routing approvals to any user, manager, asset owner, etc.... And a manager can delegate the approval responsibility to others as well. So at the end of the day when you look at an employee record there is usually a single manager/supervisor acting as that persons direct report.
Hi Charles,
That's true. I agree about 'random supervisor assignments'.
However, i was more concerned with multiple level of hierarchy.
I ended up doing multiple feeds for Level 0 Supervisors, followed by Level 1, followed by Level 2 and so on.
Thanks for your insight.
Post a Comment