Archive for August, 2009

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.

Luminis IV install documentation

August 14th, 2009 No comments

I have begun the documentation on how to install Luminis IV within our environment. You can view the evolving document over at the wiki titled Installing Luminis IV. At this point everything documented in the wiki on an install has been done on our test system (

This documentation shall help ensure that when we are ready to move to Luminis IV anyone invovled will have hopefully a clear set of steps.

Luminis IV on RHEL 4

August 13th, 2009 No comments

In spring SUngard had announced that Luminis IV would be officially supported on Red Hat Enterprise Linux(RHEL) 4. This was good news as the support for RHEL 3 which was the officially support Linux platform previously was about to dry up. As such we had a goal for our eventual move from Luminis III to Luminis IV to install Luminis IV on RHEL 4 as this should prove easier then upgrading the OS after the fact.

However we have had trouble in achieving this goal up until now. Today I had Ed reimage our RHEL 4 virtual machine ( and attempted another round of installing Luminis IV on it. It kept failing when it attempted to install the Java Enterprise System stack (calendar, directory, webserver, mail) with a return code of 50.

In examining the source code of the JES main install class error code 50 seemed to revovle around file I/O issues.Now up until this point I had been attempting to install Luminis IV onto a NFS partition, so on a long shot I decided to try and install it on the root file system. This almost worked except that we did not have enough disk space to achieve this goal. As such another call into Ed and the root file system gained an additional 5G.

This has allowed Luminis IV to be installed on RHEL 4. However this is not how we will want to leave it as we want to minimise the amount of software left on the OS disk. As such the next step will be to move this data over to the NFS partition and setup the symlink. This of course will be a job for another day.

I also will be placing some documentation into the wiki on how to install Luminis IV, with this rather important point present.