The new era has begun…

Today I hacked our legacy myUMBC portal code to generate XML output
for the registration eligibility function. The goal is to eventually
get away from the big, monolithic app and separate the business logic
from the presentation. Registration eligibility was a good place to
start, because (1) it’s a simple function with simple output; (2)
we’ve gotten a request to display registration eligibility within MAP,
so we needed to figure out a way to share the code; and (3)
registration eligibility still talks directly to the HP3000 mainframe,
which makes it impractical to do code sharing via Perl modules,
libraries, etc. So, this is what we came up with. It’s the first
step in coming up with a web-services type API for our back-end SIS
business logic.

The first thing I needed to deal with was the Perl code itself. The
legacy myUMBC code, while nice and modular, is very HTML-centric.
The business logic stuff is all mixed up with the code for HTML
generation. The code works by building data structures to represent
HTML objects, and the business logic bits are all built into those
data structures. Separating this stuff out is not really major
surgery, but it does require some work. I’ve managed to do this for
the registration eligibility code, but I still need to put a run-time
flag into the code to toggle XML vs. HTML output. Also, there will be
the ongoing challenge of dealing with error conditions and generating
valid XML in these cases, but we’re getting there.

On the actual XML front, the main challenge is defining what exactly
you want to output, coming up with a spec (DTD), and sticking to it.
This can require quite a bit of thought, and needs to be done before
any actual code is written. For registration eligibility, the DTD I
came up with is pretty simple:


<?xml version="1.0"?>
<!ELEMENT registration (eligibility)>
<!ELEMENT eligibility (status*)>
<!ATTLIST eligibility status (eligible|ineligible|registered|error) #REQUIRED>
<!ELEMENT status (description,extra?>
<!ELEMENT description (#CDATA)>
<!ELEMENT extra (#CDATA)>

And some sample XML…

<registration>
 <eligibility status="ineligible">
  <status type="academic">
   You are academically ineligible to register.
  </status>
  <extra>
   Your GPA is too sucky for you to continue
   attending the university.
   Please go away.
  </extra>
  <status type="financial">
   You are financially ineligibile to register.
  </status>
  <extra>
   Your parents didn't send us any money this
   semester. Please go away.
  </extra>
 </eligibility>
</registration>


Coupla notes here.. I used the generic tag name “registration” with
the idea that down the road, the object will contain other
registration related stuff besides eligibility. We’ll see if that
actually happens. And, although I do include text-based descriptions
of eligibility status, these are only intended to be guidelines.
Applications can use the descriptions as-is, or key off the “type”
attribute in the “status” tag, and display their own messages.

The code generates this XML using the same Perl objects I wrote to
construct HTML. It seems to work OK for generalized markup, and
guarantees that the output will be “clean”.

Next up is to see how this works when we pull it in as a uPortal
channel. To do this, we’ll need an XSLT stylesheet and we’ll need to
set up a “Generic XML/XSLT Transformation” type channel (rather than a
web proxy). We’ll need to use our custom local connection context
code to connect, and it remains to see how that will work with a
non-web proxy channel. Should be fun..

Well, I learned something new about IE today. If you use an empty-element tag in a <script> declaration, for example:

<script language="javascript" src="/foo/bar.js"/>

It breaks IE. Apparently, IE doesn’t treat the trailing slash as a close tag, and treats the rest of the page as an inline script. Firefox, as expected, has no problems with this. The workaround for IE is:

<script language="javascript" src="/foo/bar.js">
</script>

This affects IE 6; don’t know about other versions.

Like everything else around here, we learned this the hard way, after I made some mods to the Student Parking Registration app and it broke for IE users. Fun fun..

On another front.. we’ve got something new coming down the pike. If I can ever get away from all my various menial maintenance chores (FAR, Parking, PlacePro, etc. etc. etc.) we’re going to attempt to do a pseudo-quasi-web services app. It’s not “real” web services, but I’m going to mangle the legacy myUMBC portal code so that various functions can return XML for consumption by other apps. Background: We’ve been asked to display registration eligibility status inside MAP (UMBC’s homegrown kitchen-sink retention-aid-transcript-displaying-advising-scheduling-coffee-making web app). Now, the hitch here is that we currently pull eligibility info directly from the HP3000. It’s all there in the Oracle SIS, but no one has coded up the SQL to fetch it, and our development resources are spread too thin (doing crap like FAR, PlacePro, etc.) to do it right now. And even if we did it, the code would have to be duplicated between myUMBC and MAP, which is just a bad idea anyhow. So, I’m going to hack myUMBC so that MAP can call it, pass some magic params, and read back an XML stream of registration eligibility info (which can be parsed, transformed, etc. as desired). To make this happen, we need to do a few things..

1. Move MAP off its current SGI hardware and onto a more modern platform, where we have the LWP::UserAgent and Crypt::SSLeay Perl modules installed
2. Figure out a workable DTD for the XML data, and stick to it
3. Modify the legacy myUMBC code so it can output XML (via a custom URL, custom CGI parameter, etc.
4. Modify MAP to call this routine using LWP::UserAgent, parse the results, and display them

Like I said, not really “web services” in the official sense, but the same kinda thing. This seems like an easier, and possibly better, way to do code sharing without having to do major surgery on the legacy code. As with everything else, we’ll see how it works in practice.

Well, I spent most of the day fixing our PlacePro single signon. Again.

PlacePro is the ultimate example of why I hate doing single signon to remote webapps on third-party sites. It’s a pain doing it in the first place, and when it’s done, it becomes an ongoing maintenance hassle. When it works, it’s nice, and one could make an argument that it enhances the end-user experience. But when it breaks, you end up reinventing the wheel to make it work again. And of course, it always breaks at the most inopportune times. My opinion: If you’re not going to do it right, don’t do it at all, and spare everyone the hassle. But anyhow..

PlacePro is an online service that allows students to post resumes for consumption by potential co-op and internship employers. They do this in conjunction with The Shriver Center. I’ve been dealing with PlacePro for, oh, 4-odd years or so. The usual iteration goes something like this:

1. We set up a single signon from myUMBC into PlacePro’s system. It works and the world is happy for, oh, a year or so.
2. The PlacePro people make a change on the back-end that breaks the single signon.
3. I get a frantic call from the Shriver Center.
4. I talk to the tech guy at PlacePro, and tweak the single signon process to work with whatever changed on their end.
5. Go to 1.

We’ve been through this loop 3 or 4 times now. The good news is, it now looks like UMBC is going to be dropping PlacePro. The question is, will the new vendor be any better? Time will tell I guess.

Basic PlacePro workflow, for anyone who wants to commiserate:

• A student decides they want to use PlacePro to find an internship placement. The student goes to the Shriver Center, and the Shriver Center staff enters the student into PlacePro’s system using the PlacePro Coordination Module.
• As part of this process, we put the student into a database table on the Oracle shadow, AUXIL.PLACEPRO_ACCESS. The table is indexed by student ID, and includes an access code field. NOTE: As of 3/22/2006, this access code is NO LONGER USED. This table is now used SOLELY to determine whether to display a PlacePro link to the student in myUMBC. If the student’s ID is present in the table, the student sees the link; if not, not.The script that puts the students in the table lives at: http://my.umbc.edu/cgi-bin/placepro/addlink.pl
• The student should now see a PlacePro link in myUMBC. The link is currently generated by the legacy Perl myUMBC codebase, in the file /myumbc/src/myumbc/placepro.pl. This code builds a link that posts the student’s ID and last name to https://my.umbc.edu/placepro.jsp. The JSP opens in a new window, and displays some verbage from the Shriver Center as well as a link to the actual PlacePro site. To generate this link, we run the student ID and last name through an encryption routine provided by PlacePro. All of this happens in the JSP. The last name does not seem to be case sensitive.
• The student clicks on this link, and is automatically logged into the PlacePro system (until it breaks again).

That’s about it, for now. Oh, one last caveat: The student’s last name in the PlacePro system MUST match the last name on file in SIS. Otherwise, this will pass an incorrect last name, and the signon will not work. Students in this situation should be referred to the Shriver Center. The change can be made via the PlacePro coordination module.