User not in Luminis - talkback to Banner?
Here at BCIT, we imported a subset of our Banner accounts to populate our Luminis database. One of the reasons we did this is that we have accounts going back to the 1980s and don't really need the vast number of accounts filling up the Luminis LDAP.
However, occasionally we run into problems where someoe comes back to BCIT for a part-time course or is hired as a staff member after not being here for many years.
When Banner fires over an update to their account (assigned to a course, for instance), there is no account to update so it fails.
I see a few options:
Import everyone
This kind of scares me as we have close to a million accounts in Banner and I really don't want to bring them all over.
Track failed updates and manually update
Also a little scary as this seems like a lot of work that I just don't want anyone to be responsible for
Automatic talkback that forces an account to be sent over
This is what I am looking for. When an account is not present in Luminis, Banner intelligently takes the entirety of their account and creates the account on the Luminis side.
How are other institutes doing this? Is there a function I am missing? Can Banner and/or Luminis be configured in this way?
Portal is the front door - and the ONLY door
We don't run into this because in order for a person to get access to self-service banner (and hence register for a class) they must first log into the portal. Therefore they have an account.
We do have a bit of a race condition between when people are hired and when their paperwork finally gets back from HR to create their accounts, but we solved this by altering the hiring process, so that a placeholder account is created immediately and then filled in by HR later.
Todd
LDAP can handle lots of entries
We have 850K users in our Luminis LDAP. Roughly half of these are from students prior to 2001 or so. Luminis doesn't have any problems with this. At a time when we were having performance issues, we tried tweaking the LDAP cache settings and removing accounts for long-gone students, but didn't noticed a substantial difference (our performance issues were from something else, documented elsewhere on lumdev I think!).
I've seen several Sun pages recommend changing nsslapd-db-home-directory parameter in dse.ldif to reside in /tmp (on Solaris and presumably Linux), otherwise the disk activity can run high. We have done this.
Modified Trigger
We had a similar problem in that we would delete accounts after a set time if a person was no longer enrolled. To get around this, I modified the triggers on the Banner registration table so when an entry is created/deleted/etc. for someone enrolling/unenrolling/etc. from a class, a person event is fired before the enrollment event. This does cause an increase in LDI traffic, particularly during registration periods, but it hasn't been unmanageable. You also have to make sure to re-modify the trigger when the integration components are upgraded.
I can provide the trigger changes and what-not if desired. Please let me know via email (nesslage at missouriwestern.edu) and I'll update this post with the details.