CE/Vista and Banner Integration

This is the second time I have worked on making Vista integration work with Banner. The first was 2005 in Vista 3.0.3 at Valdosta State. The production here at GeorgiaVIEW was set up by Harold, Jill, and Amy years ago and integrated into the install scripts or part of the cloned databases.

So now I am working on getting it to work in Vista 8. The IMS imports worked the first time like a charm. When I turned to using the Luminis adapter, the person records worked fine but the group contexts failed in Vista 8 and worked fine in Vista 3. So the “siapi.sh luminis import restrict” works fine.


We have 41 institutions in Vista 3 currently. So imports are automated to some degree to preserve the sanity of Jill (and to a lesser degree Amy and myself). Rather than put in the UI all the settings, we have a properties file defining the location, glcid, sourcedid.source and sourcedid.id for each institution. This allows us to easily pass the values when importing at the command-line.

My first approach was to leave the settings identical to what I used to create persons and group records with IMS. This essentially uses the glcid of the institution and sourcedid of the institution. This is what resulted in the person records working and groups not. Fail.

I realized my error in logic must be the lack of a division-to-group relationship as the error described the groups cannot be related to an institution. So I changed the properties to use the division values for the sourcedid. Fail.

So I went looking in “Guide to Integration with the SunGard Luminis Data Integration Suite” for what I ought to use at the command-line. I didn’t find a solution. Just the same command-line lacking even the glcid and sourcedid.


Giving up on the command-line approach for now, I added the relationship element to the XML so the group would become a child of one of the divisions I created with IMS. It sorta worked! The groups all imported but the course failed with the exact same error the groups formerly succeeded. To add insult to injury, simply running the import again on the exact same file had the courses import.


A mistake I made was reading the documentation: “Guide to Integration with the SunGard Luminis Data Integration Suite”.

Sungard Libraries:

  1. Page 8 says imq.jar and mbclient.jar do not come with CE/Vista and must be obtained from Sungard. All three of us thought in Vista 3.x these were automatically placed so we didn’t need to place them. Best I can tell, these were installed by Vista. I found $WEBCTDOMAIN/customconfig/startup.properties references both files in CUSTOM_CLASSPATH and setEnv.sh references CUSTOM_CLASSPATH. (This document has notes for what CE customers need to do and no note about CE users needing to go get them from Sungard.)
  2. Those who believe the last note would keep reading and find on Page 9 instructions to deposit the files in $WEBCTDOMAIN/serverlibs/. Assuming I am wrong about item #1, the startup.properties expects them in $WEBCTDOMAIN/serverlibs/luminis/ and would not find them where the document says to put them.

BbWorld Presentation Redux Part I – Automation

Much of what I might write in these posts about Vista is knowledge accumulated from the efforts of my coworkers.

I’ve decided to do a series of blog posts on our presentation at BbWorld ’07, on the behalf of the Georgia VIEW project, Maintaining Large Vista Installations (2MB PPT). I wrote the bit about tracking files a while back in large part because of the blank looks we got when I mentioned in our presentation at BbWorld these files exist. For many unanticipated reasons, these may not be made part of the tracking data in the database.

Automation in this context essentially is the scheduling of tasks to run without a human needing to intercede. Humans should spend time on analysis not typing commands into a shell.

Rolling Restarts

This is our internal name for restarting a subset (consisting of nodes) of our clusters. The idea is to restart all managed nodes except the JMS node, usually one at a time. Such restarts are conducted for one of two reasons: 1) have the node pick up a setting or 2) have Java discard from memory everything. The latter is why we restart the nodes once weekly.

Like many, I was skeptical of the value of restarting the nodes in the cluster once weekly. Until, as part of the Daylight Savings Time patching, we provided our nodes to our Systems folks (hardware and operating systems) and forgot to re-enable the Rolling Restarts for one batch. Those nodes starting complaining about issues into the second week. Putting back into place the Rolling Restarts eliminated the issues. So… Now I am a believer!

One of my coworkers created a script which 1) detects whether or not Vista is running on the node, 2) only if Vista is running does it shut down the node, 3) once down, it starts up the node, and 4) finally checks that it is running. Its pretty basic.

Log cleanup to preserve space

We operate on a relatively small space budget. Accumulating logs infinitum strikes us as unnecessary. So, we keep a months’ worth of logs for certain ones. Others are rolled by Log4j to keep a certain number. Certain activities can mean only a day’s worth are kept, so we have on occasion increased the number kept for diagnostics. Log4j is so easy and painless.

We use Unix’s find with mtime to look for files 30 days old with specific file names. We delete the ones which match the pattern.

UPDATE 2007-SEP-18: The axis files in /var/tmp will go on this list, but we will delete any more than a day old.

Error reporting application, tracking, vulnerabilities

Any problems we have encountered, we expect to encounter again at some point. We send ourselves reports to stay on top of potentially escalating issues. Specifically, we monitor for the unmarshalled exception for WebLogic, that tracking files failed to upload, and we used to collect instances of a known vulnerability in Vista. Now that its been patched, we are not looking for it anymore.

Thread dumps

Blackboard at some point will ask for thread dumps at the time the error occurred. Replicating a severe issue strikes us as bad for our users. We have the thread dumps running every 5 minutes and can collect them to provide Blackboard on demand. No messing with the users for us.

Sync admin node with backup

We use rsync to keep a spare admin node in sync with the admin node for each production cluster. Should the admin node fail, we have a hot spare.

LDIS batch integration

Because we do not run a single cluster per school and the Luminis Data Integration Suite does not work with multiple schools for Vista 3 (rumor is Utah has it working for Vista 4), we have to import our Banner data in batches. The schools we host send the files, our expert reviews the files and puts them in place. A script finds the files and uploads each in turn. Our expert can sleep at night.

Very soon, we will automate the running of the table analysis.

Anyone have ideas on what we should automate?