I don’t usually talk about work on this blog, simply because I’ve read enough horror stories about blogging work matters to know how badly it ends. Granted, if I were to blog about my job, it would mostly consist of technology bits, but it’s still one of those grey areas I avoid out of propriety.

Yet, I find myself at home, with a White Russian1 and the urge to opine.

The Background

In the summer of 2006, my workplace (The University of St. Francis, my alma mater) went live with a portal. For the previous year and half, when I was a student worker, we’d been working desperately to implement Oracle Portal. At a conference that summer, my boss, Tim, heard about uPortal, an open-source J2EE portal. On the ride back from Ohio, we more or less decided to try it on a lark. It’s basic ease of setup let us switch to uPortal and go live in 6 weeks. That’s right, a production-ready portal in 6 weeks.

Much of the work in that time was tying CAS into our LDAP implementation (Novell’s eDirectory), customizing the view (props to Virginia Tech for their excellent Tab-Column customization), and writing some basic portlets to allow quick views into student data: schedule, personal info, billing, &c. We’re a Banner school, so we could basically just reach into our Oracle database and pull the data we needed.

The Cool Bits

Since that time, we’ve poured a tremendous amount of energy into the portal, as it’s become our go-to spot for finding information and getting things done. Actually, we’ve spent very little time on uPortal at all, as it already contains much of the quick-view functionality we want. Much of what we do is a custom extension to the portal that transparently shares session data via CAS.

We have completed our portal rollout using uPortal (running on apache/tomcat), and are integrated with Sungard Banner 7.x for much of the information we pull and display, and we are using Novell E-Directory for our directory.

We used uPortal which proved to be a much more promising and easier to use platform than Oracle portal. Within 6 weeks we had our first production portal deployment. Over the last year we have built and put the following into production:

  • Student Schedule and Grades Display (pulled realtime from Banner)
  • WebCT Integration/SSO
  • Announcements (Targeted coming by end of summer ’07)
  • SSO to Novell WebMail, Netstorage, and Banner Self Serve
  • Bookstore Integration with Barnes and Noble (Shopping cart of books)
  • Financial Aid Portlet/Accept Loans – Display and update banner data
  • Tuition Bill Portlet – Pulled in realtime from Banner AR
  • Payment of Tuition Bill/Post Directly to Banner AR
  • My Profile Portlet (information pulled realtime from Banner)
  • GPA/Credit Hours Portlet (Pulled realtime from banner)
  • Banner Security Question/Reset Password Functionality
  • Expired Password Functionality
  • Faculty Schedule/Class Rosters/Email Class, Export to Excel
  • Banner Survey Integration
  • HR Leave Balances
  • Budget Reporting/Financial Activity/View Documents, checks cut, etc
  • Banner Requisition Approval
  • Web Based University Income/P&L Statement
  • Banner Finance Journal Voucher Upload
  • PIDM Usage Utility to help identify and resolve duplicate pidms
  • EZProxy/Library Databases Integration
  • Advancement Constituent Profiles
  • Advancement Fundraising Activity Reports
  • Advancement Constituent Contacts Data Entry/Reminders
  • Financial Aid targeted messages
  • GUAMESG
  • Residence Life View your Room/Roomates
  • Bulletin Boards (phpBB)
  • VT Calendar
  • Various Web based Reports
  • E-Directory Integration/Account Creation
  • Early alert and midterm warning submission, that allows the student, advisor, registrar, athletic coaches, and other support staff know when a student is having academic difficulties.
  • An online advising center. Advisors can now see all of their advisees, look at who’s registered, view issues with the students account such as registration or medical holds, etc. The goal is so that advisors can also help the students get their issues resolved.
  • Our initial stab at targeted announcements is done. We can now target based on the student type, level, or college as currently stored in the Banner ERP, as well as target to only employees or faculty members. The framework is in place to target off of any data element stored in Banner. Now we just need to expand our GUI allowing users to target messages.
  • Accounts Receivable Reporting Suite – Our finance office now uses the portal to do various AR reporting tasks, drilling into student details, etc.
  • Enrollment/Registration Status Reports – Various members of the university can now easily look at the overall student registration status through the portal.
  • A faculty attendance tracking module for faculty to electronically submit the attendance of students in their classes at the beginning of term and at the mid-term point. This helps the registrar and financial aid determine who is actually attending, and replaces an old paper based process.
  • On online Student Check-In procedure. Students can now confirm their class schedules, financial aid, and pay their bill through an easy to use “wizard” interface. The system will notify when they need to perform the electronic check in process before the start of the term, and then walks them through the process. This helps to collect payments sooner and determine which students are actually going to show up to class on day 1.
  • Our portal now has a targeted messaging facility which looks at business rules and notifies the students of issues or action items related to their student records. For example, if a student has holds on their account the system will tell them, show them the hold, tell them what it prevents them from doing, and who to contact to resolve the hold. For students with incomplete medical records they are notified, and shown which parts of their medical records are incomplete (and for our nursing program, which shots, etc they need to have on file to be able to attend clinicals).
  • A co-curricular transcript which pulls from Banner all the clubs, organizations, and sports a student has been a member of during their time at the university, and shows them in a nicely formatted page that they can print.
  • A real-time registration status dashboard for administrators, deans, and faculty members. This dashboard now shows the head counts, course registration counts, credit hours, and billing hours generated for registered students, and the number of potential students who are left to register. It breaks the summary counts down in several ways: by college, major, advisor, or level (graduate, undergrad, etc). The users can drill into this report and extract lists of students who still need to get registered, whom to call to see if they need advising help or assistance registering, etc.

As the UI architect for the portal extension, I decided this past summer to standardise on jQuery, and certainly haven’t regretted it. The only bad thing about javascript is that it becomes easy to rely on it for things which should really be controlled server-side. Important validation checks, for instance. Since our ERP system has certain business logic which it enforces on the database level, we usually do two checks for important data: one (javascript) for the user’s sake, and one (servlet) for ours.

It got to the point where we were loading 10 different jQuery javascripts and 2 stylesheets in our header. Most of the javascripts were either packed or uncompressed (if packing broke them), and totaled about 200Kb. Not only was this too much, but the eval() caused a delay for each script. Recently, after one of our rollouts to production, when I got more leeway to play, I completely upgraded our script layout. I’m not going to provide an apples-to-apples comparison table here, since the prior configuration was a hodgepodge, but after minifying and turning on server-side compression for javascripts and stylesheets2, I managed to reduce the load from 200Kb in 12 requests to about 50Kb in 5 requests. According to Julien Lecomte, running mod_deflate on a minified (but no obfuscated) javascript yields the lowest file size; regardless of how often that’s true, I like the idea of avoid latency from the eval(). A lot of our users are still on IE6, and they take some pretty big performance hits.

Goodness knows there’s more I could do, but given the nature of our portal (single-image CSS layouts, anyone?), it wouldn’t be a productive use of our time); I have enough crap to do with counting pixels.

jQuery rocks my socks

I might take a moment here to say just how much I love jQuery. For those of you who don’t know, jQuery is a javascript framework which abstracts a lot of functions into a much more easily-written manner. In the past, I’ve sort of been a Copy & Paste javascript programmer, since it’s been easier to use some free script than to write one’s own code. jQuery and it’s vast array (har!) of plugins makes it easy to implement or write new code. For instance, if we want to implement a support for CSS hover effects in IE, all we do is this:

$("input:text,input:password,textarea").focus(function() {
     $(this).addClass("focused");
});
 
$("input:text,input:password,textarea").blur(function() {
     $(this).removeClass("focused");
});

Easy as pie.

Granted, there are a lot of frameworks to choose from. Originally, there was only Prototype; now there’s also jQuery, Dojo, YUI, Mootools, Rico, and any one of a number of others.

The one I wanted to talk about in this post in particular is ExtJS, which was originally an extension of the YUI framework, but which eventually split off into its own project. It recently went 2.0, and boasts some rather impressive demos. I marvel at the Vista-like UI, which, admittedly, is very slick.

But the more I look at ExtJS, and half-heartedly consider its possible deployment within our portal, the less enthused I become. ExtJS’s grid, for instance, doesn’t even function on existing HTML table markup: you mass it an array of data as a javascript variable, and it creates markup on the fly… a lot of markup, in order to create it’s slick Office 2007 interface. While this is good insofar as it manages to completely abstract data from presentation, I’m not sure how much I like the idea, since it (1) relegates users to the script default without heavy customization, and (2) doesn’t allow for any kind of fallback mechanism if the javascript should fail or the user has it disabled. Our table-sorting function, in a case like that, doesn’t at all prevent the table markup and data itself from being rendered3.

Work can be fun sometimes.

  1. or, if you prefer, a post from drunkenbatman. And might I say, while I’m referencing Drunken Blog, how sad I am that the blog appears to have died? Granted, I don’t care a bit about Mac stuff, but the man’s coverage of the PearPC/Maui X-Stream was one of the tech-blogging highlights of the year[]
  2. for some reason, turning on mod_deflate for HTML brings the server to a crawl; I’m not sure if it has anything to do with us serving from a connector for Tomcat. Regardless, it’s off for the time being[]
  3. I should say, in fairness, that not all of our portal is that safe from failure. Many of its functions depend on javascript, though I’m not so sure that, in 2007, a modern browser and enabled javascript is such a weighty demand. In fact, I think that if developers intentionally spent less time catering to dead-weight users who can’t be bothered to use technology from this decade, the world would be a better place[]
§1941 · December 8, 2007 · Tags: , , , , , , , ·

8 Comments to “Various and sundry technology stuff pertaining to work”

  1. Jeff says:

    Every time I want to blog about work it’s something bad, so I typically keep my mouth shut. I still like my job, though. Maybe I’m just a negative person.

    I’ve been playing around with jQuery at work and it’s quite cool. I haven’t brought up adding it to the web app I work on, but I may shortly. When you can replace 150 lines of hack-ish Javascript with 15 lines of understandable jQuery based code, that’s gotta say something.

  2. Ben says:

    It’s easy to bitch about bad things. I work at a university: I have to cater to academics all the time; rolling my eyes is now second nature. For all that, though, it’s a good place, and good work.

    jQuery is by far the easiest of the frameworks I’ve seen. I wasn’t even really a javascript sort of guy until I found it. It manages a ridiculous level of abstraction without a ridiculous amount of overhead. A perfect example of good code.

  3. David says:

    I’m new to Banner and I’m trying to build a simple JSR-168 compliant portlet that will SSO into SSB by posting directly to twbkwbis.P_ValLogin with the correct user credentials but there’s a problem, instead of logging the user in I get a 410 error:

    The requested resource
    /…/twbkwbis.P_ValLogin
    is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

    I imagine there’s some http header information or cookie I am missing when I do my POST but a packet trace has not proved useful because the site is over https.

    I’ve done this hacky type of SSO before with success but I’m missing something fundimental when dealing with Oracle/Sungard.

    Any tips anyone?

  4. Ben says:

    Self Serve is notoriously finicky. Our “SSO” into the self-service area is essentially a frameset that loads a user, looks up their pin from GOBTPAC, and fires off a frame that logs the user in. Then, some javascript trickery removes the login frame, leaving only the desired page.

  5. Amar says:

    I need to do same thing as David. I am trying to do SSO from within a different domain than that of the Banner SSB. When I am trying to submit the form through a frame I am getting this error on IE, "Could not complete the operation due to error 80070005". When I looked upon that error code it said, "General access denied error". I think its denying me access becauase I am trying to mainupulate form data outside the domain.
    So my question to you is, when you did it, were you running it from the same domain or from a different domain?

  6. Ben says:

    Our portal server is on a different box than our Banner form server (SelfServe), if that’s what you’re asking.

  7. Hello,
    I’m glad to find your info about uPortal & Banner.
    We will be migrating to Banner shortly and we’ve been on production uPortal for about 5 months.
    Do you know of a working support group for Banner customers using uPortal?

    Many thanks.

  8. Ben says:

    There isn’t a resource specifically for Banner schools as far as I know, but the general mailing list is an excellent resource. Banner’s the most common ERP in higher ed, so I imagine there are a lot of schools in the same boat.

Leave a Reply