Archive

Posts Tagged ‘course membership’

Luminis and LDI Part 2

August 27th, 2009 No comments

This morning I was able to take an extract from the production banner system and push into our test Luminis system all the terms and courses. This worked quite well and allowed me to move onto the next test. The creation of user accounts.

Modifying the extract parsing code to only forward on person data packets I have been able to create all the required messages in the JMS (approx 45K). As I previously had worked out the code to determine a UMnetID for a given person data object all that was left was to push those person objects with no UMnetID into a holding topic.

I created  a new topic for this purpose and fired up the interceptor code. It began determining UMnetID’s and sending them to the topic that Luminis subscribes to which then began producing user objets quite nicely.

However the ones that had no UMnetID although being sent to the holdign topic were not remaining there because there is no subscriber to that topic. As such the next goal will be to write the utility that will monitor the holding topic and periodically resend those data packets to the topic the interceptor will listen on.

For this reason I have stopped the interceptor for tonight and will start fresh in the morning. Once it is properly handling the person objects that need to be queued I will move on to the membership objects. There is no translation that needs to be done, but we do need to inspect the packets to see if the user exists in Luminis before sending it along. Probably should verify that the course is present as well before sending it along. These are both LDAP queries so nothing overly complex and should be quick to wrap up.

At this rate we can probably have testing early next week.

Luminis and LDI

August 26th, 2009 No comments

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.