Author Archive

A new login page

December 2nd, 2009 No comments

Over the last week or so we have been working on a new login page for JUMP. This post will explain some of the areas we were thinking of that has prompted this new design.

  • To help reduce the time needed for the login page to appear in your browser we have been able to reduce the overall amount of data downloaded by at least 50%.

    Windows Mobile 6 device

    Windows Mobile 6 device

  • We have also been able to reduce the number of remote files that would need to be loaded which helps reduce the overall network activity
  • The form fields for the username and password appear on the left side of the overall login form which allows small screen devices (PDAs, cell phones) to be able to login without a need of scrolling to the right
  • As a login page’s purpose is to allow a user to log into an application we have removed non essential content from the login page (except for the graphic which is used for some flair)
  • You can still login with either a UMnetID, Student #/PIN, or Employee #/Birth Date and to this end we will adjust the label for the password field to reflect the type of password(format) you need to supply based on what you are using as a Username
  • For news we will make use of a browser’s Auto Discovery of new feeds (RSS) to inform you about the news list. This way if all you want to do is log in we are not wasting your time by supplying you with news you do not want to read at that time.
  • We wanted to pick up on some of the design elements from the UofM site to help solidify the impression that we are part of the UofM. This is achieved by sharing the gold colour as well as the UofM logo and the footer across the bottom.

We plan to carry the work done in making the login page a leaner faster page into the rest of the JUMP.

Let us know if you like the new design by sending an e-mail to

Tags: ,

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.

daily summary (moorewj)

June 15th, 2009 No comments

Last week found out we were facing a new defect with the migration. In this case admin permissions for manipulating channels were missing after the migration. With suggestions from Sungard over the weekend I installed LP IV on romulus and performed another migration.

This time post migration we have access to these admin level functions. So prior to this post things were in good shape for Debbie and Brian to test, not so for Dave, Naramada, and Bill. But now everyone can take part on vulcan ( to fix up the custom channels. Perhaps on the weekend I will try and put in some of my new custom channels.

dancing from roof tops

June 8th, 2009 No comments

Alright no real dancing but still some excellent news. Sungard reviewed the log files from Friday and Saturday and they all look good. Today I transferred over all the group/course tools files from June of last year (when we did the snapshot) to vulcan.

I am currently working with Sungard to resolve the odd issue with decreased admin access once logged into the portal. I still need to bring over the mb_topics table but once that is done I think we can open it up for testing.

Keep in mind the testing to be done is to confirm that the data present in the groups and courses is accurate. The testing is not for commenting on broken channels as we know that all custom channels we have developed will most likely be broken. There is one exception in that if a channel is not a custom channel (i.e. targetted content, or old school RSS) and it does not appear to have been migrated properly we need to know about it.

All feed back needs to be done via bugzilla, there is a new component called migration to track these issues in.

huzzah (aka a successful migration)

June 6th, 2009 No comments

About bloody time! I have been able to migrate the Luminis III data to Luminis IV. There are some fine touches that need to yet be done. Specifically:

  • migrate mb_topics by hand
  • migrate calendar data
  • migrate the group and course files and photos
  • put back the custom CAR files

Those were given issues from the outset of this process, which I will work on, on Monday. Now the data present in this system goes back to June of last year.

Perhaps I should not shout from the rooftops just yet, but I was actually able to log in and see a fairly functional portal unlike previous attempts where the bulk of the channels were broken.

The url for those that monitor this blog is

luminis migration

June 5th, 2009 No comments

The main issue affecting us currently is the small change to the baseDN suffix in Luminis IV. We have been told that if we make it the same the migration script should work. However the migration script is also meant to handle such a change.

Well today it looks like I may have tracked down the reason for the issue. In all the translations that the mgiration script does, it does not translate the property values from the old system before loading them into the new system. As such the old system does contain various properties that contain an LDAP baseDN. These are used by the system when it is running, but also later parts of the migration for fixing the data. I have adjusted their code that does perform some modifications to the source system property file to correct the values and in tests this afternoon it produces the correct file.

In a few moments I will start up the job that will perform the full migration tonight to see if this resolves things. Of course we will not know anything until tomorrow, I also hope the oracle team gets my e-mail in time to disable the lp4prod recycle. 🙂

Well look at that they did get it and it has been disabled. Yeah! 🙂


June 3rd, 2009 No comments

In regards to the migration it would appear that the belief Sungard had in regards to changing LDAP suffix causing the problem was incorrect. The problem was directly tied to attempting to move over a layout owner that did not exist in the list of users being loaded into Luminis IV. Once I removed this layout section from the dlm.xml file we were able to get farther. However we then stumbled on an issue with updating the LDAP with the layout owner information in the dlm.xml file.

This was due to there already existing layout information in the LDAP. The suggestion from Sungard for this was to reset the Luminis IV data and manually delete the layout information present so that the migration tool could insert the data from Luminis III.

This was done on Friday last week and we postponed the Luminis IV database recycle so that it could run through Saturday. We have now got even further then before. There is still an error in the output that I am having Sungard evaluate to determine if it is of a critical nature.

So in short the things that we have done to make the migration work:

1. Increase the error threshold to 2 as there is a known problem with the migration of the mb_topic table and UTF8

2. Migrate the mb_topic table manually as there is no translation being done on this table other then the dropping of one column

3. Ensure that there are no fragment entries in ou=site,o=Luminis Configuration, the cn pattern will look like where ?? is a number