For those just tuning in, LDI stands for Luminis Data Integration. Although it contains Luminis in the name it is not specific to Luminis. This tool from Sungard (the vendor that creates Luminis (what we call JUMP) and Banner (what we call Aurora)) is meant to allow for integrating Banner student data with any software package that will consume the data.
At the core of the LDI implementation is a JMS (java messaging service) server which acts as the hub, in a hub and spoke distribution system. Banner via LDI will send data packets to the JMS, and products such as Luminis and Angel will come along later to consume those data packets and act on them.
Now for a few years we have had a goal of implementing LDI for the courses stored in JUMP. To date we have been using an ever evolving batch processing approach to managing the courses, however batch processing occasionally has its problems. One of our largest ones is that we currently our unable to detect when a student drops a course. As such once added they remain until we are notified and then a manual process is used to remove them.
LDI will resolve this definicency. It does this because it will act on specific events from banner such as the add or drop of a course by a student. This also means that changes will flow for the most part in real time.
Now in an ideal world this would work out of the box, unfortuantely for us this is not the case. Banner is not the authoratative source for computer accounts on our campus, so when Banner sends a create person event the userid present is of no use to JUMP. As such for the last week and a bit what I have been working on is a set of programs that can intercept the LDI data packets after being sent to the JMS and transform them before placing them into a topic that Luminis will be consuming from.
This way, we can inspect the person data packet and determine the actual UMnetID the person has and update the data packet. In addition to the userid rebuild, we also potentially need to rebuild the primary spriden id piece of the data packet.
For most people (students) the primary spriden id is their student number. However faculty and instructors also have a primary spriden id which may be their student number from when they were a student, or some other number. Although Banner does have the employee number, it seldom is ever listed as the primary spriden id and it is only the primary spriden id that gets listed in the LDI data packet.
Now the signifigance of this problem is that our current IDM system has accounts under either a student number or an employee number. Faculty and instructors will want their courses connected to the account under their employee number as their student account may no longer be active. So part of this process is to derive the actual identifier from our IDM perspective before sending this on to JUMP.
Now both issues above have been worked out and in casual testing are working. This leave one final issue to deal with. Students, faculty, instructors, and employees are not automatically given a JUMP account currently. They need to claim the account. As such it is possible that banner will not only send a person data packet, but a course membership data packet for someone that does not exist in JUMP yet. We do not want to lose this information, so this code needs to determine if the user currently exists, and if the user does not place their data packets (person and membership) into a holding area for later processing.
Hopefully this is something that shall be resolved in the next day or two.