Luminis Modification Procedure
February 19, 2007 | 2 Comments
Over the last few years of administering a SunGard Higher Education Luminis portal, I have often found it necessary to make modification to the base system. The mods themselves are reasonably simple, but remembering to maintain them across patches and upgrades can prove challenging. In response to this, the following procedure has proven to be most efficient for us at Plymouth State University.
When making modifications to your base Luminis system…
- Copy the original file to filename.version
(ex. cp nested-tables.xsl nested-tables.xsl.3.3.3.16) - Make your modifications to the original file.
(ex. vi nested-tables.xsl) - When you are happy with the complete and tested modifications, copy the file to filename.psu
(ex. cp nested-tables.xsl nested-tables.xsl.psu) - Once a modification is complete you make notes on why these changes were made in ~/CHANGELOG
When you have completed this, you will have three files where you previously had only one. The reason for making all these copies is to protect yourself during patches. You will always have a copy of the file with your modifications and a copy of the unmodified version. This sets you up nicely for the following patch procedure.
Rolling modification back in when patching Luminis…
- Make note of the current version number.
(ex. 3.3.3.16, you get this with the cpver command) - Apply the patch as documented .
- Use find to get a list off all your modifications.
(ex. find $CP_ROOT -name “*.psu”) - If the file is a binary archive (jar or car) you will need to extract it and apply the following steps for each modified file inside the archive.
(ex. mkdir tmp; cp uPortal.jar tmp; cd tmp; jar xvf uPortal.jar; rm uPortal.jar) - Use diff to compare the file against your custom version.
(ex. diff nested-tables.xsl nested-tables.xsl.psu)- If there are no differences, the file was not updated by the patch, in this case you should move the old versioned file to match the new version number. You are complete with this mod.
(ex. mv nested-tables.xsl.3.3.3.16 nested-tables.xsl.3.3.3.64)
- If there are no differences, the file was not updated by the patch, in this case you should move the old versioned file to match the new version number. You are complete with this mod.
- If step 5 yielded differences, you need to see if the file was changed from the previous version.
(ex. diff nested-tables.xsl nested-tables.xsl.3.3.3.16)- If there are no differences, then the file hasn’t changed and you can put your mod back in place and simply update the version number. You are complete with this mod.
(ex. cp nested-tables.xsl nested-tables.xsl.3.3.3.64; cp nested-tables.xsl.psu nested-tables.xsl)
- If there are no differences, then the file hasn’t changed and you can put your mod back in place and simply update the version number. You are complete with this mod.
- If step 6 yielded differences, you need to merge your changes into the new version, this could be simple or complicated depending on how much has actually changed. This is a manual process where you will need to reference ~/CHANGELOG to detemine the extent of what was modified.
- If the file was inside a binary (step 4), recreate the archive
(ex. jar cf uPortal.jar .; cp uPortal.jar ../uPortal.jar.psu; cp uPortal.jar ../uPortal.jar) - If all your mods have been addressed, you can startup and test Luminis. You are complete.
(Note: Be sure to test the patched Luminis cleanly before applying mods)
The following steps must be done for each modified file
Obviously this is still a fair amount of work, but it is designed to be forgiving of mistakes. You generally have a fair number of files that are self explanatory in name and nature. Additionally, if done in proper order it can be done against a fair number of mods quickly. Therefore this procedure is scalable.
If anyone is doing anything similar, drastically different, or has questions or concerns about this process, please let me know in the comments section. I’m always looking to gain efficiency wherever possible, so please chime in!
Tags: luminis, modifications, nested-tables.xsl, patch, patches, plymouth state university, portal, sungard, sungardhe, uportal
Best Practices for Applying AJAX to JSR 168 Portlets
January 12, 2007 | Leave a Comment
At Plymouth State University we are just beginning to look into JSR 168 portlets for our institution’s portal. This technology for creating channels is just becoming available with the impending release of Luminis IV in Q1 of this year. In doing my initial research on JSR 168, I turned up this interesting article from Greg Ziebold and Marina Sum written in September of 2006.
From the summary/overview:
A year ago, the article Asynchronous Rendering of Portlet Content With AJAX Technology demonstrated how to apply Asynchronous JavaScript and XML (AJAX) to portlets. Since then, AJAX has become increasingly popular in the software arena and many new AJAX technologies have emerged. Examples are JavaScript libraries and toolkits, such as the Dojo Toolkit, the Yahoo! UI Library, the Google Web Toolkit, Script.aculo.us, and DHTML Goodies. In addition, new standards bodies like Open AJAX and the Dojo Foundation are key players.
In light of the many developments in the past year and the host of feedback on how to use AJAX in portlets, this article describes several helpful tips and practices on how best to exploit AJAX in portlets that comply with the Java Specification Request (JSR) 168: Portlet Specification.
The article refers to an updated version of the sample, AJAX Portlet Invoice Viewer, from the original article. You can download the binary Web archive (WAR) file. In the near future, this sample will reside in the Open Source Portlet Repository on java.net.
As we are new to JSR 168 and definitely interested in incorporating Ajax with most any channel we create, this seems like a useful guide.
Tags: AJAX, channel, dojo, greg ziebold, jsr 168, jsr168, luminis, luminis IV, Marina Sum, portal, portlet, xml, yahoo ui
Summit 2007 Presentation Proposals
October 11, 2006 | 1 Comment
It’s that time of year again. I’ve updated my bio and tweaked a few of the proposals I’ve submitted in previous years. I’m submitting fewer this year than past years as many of my responsibilities in the past year have swayed away from Luminis, reducing it’s core status in my workload.
My Title: Portal Administrator and Senior Web Developer
My Bio:
Zach Tirrell is from Plymouth State University in northern New Hampshire. Zach is both portal administrator and senior web developer for the institution. The main areas of his concentration revolve around integrating systems and identity management, Luminis has become a perfect enabler of this. He is often looking to get just a bit more out of Luminis than what is delivered. In the past couple years Zach has become increasingly involved with Summit events. At Summit 2005, Zach presented “LDI Implementation Tips and Tricks”. This presentation was repeated at Summit 2006 as well as a new presentation, “Implement and Deploy Banner Channels”, which was voted in the top 5 by attending reviewers. While at Summit 2006, Zach also co-presented “Alumni Are Coming! Luminis ROI”. Finally, he hosted an informal session in the Luminis Developer’s Lounge where he covered statistics tracking and drag and drop channels within Luminis.
Implement and Deploy Banner Channels
Banner 7 comes with a huge pile of exciting new channels. These channels greatly leverage the relationship between Luminis and Banner, however, implementation is complicated and deployment even more so. Banner channels are fantastic, but they need to be rolled out carefully. Plymouth State University has already run this gauntlet, come hear some of the concerns and pitfalls so you can avoid them yourself.
This is a repeat from last year
Collecting Luminis Statistics
By leveraging the underlying UPortal infrastructure, learn how to take advantage of RDBMSStatsRecorder to generate detailed numbers on who is logging in, logging out, how often, and by role. These numbers are supplemented with other third party statistic tracking utilities. You can then use these numbers to better understand how effective your portal strategy is. Tracking user adoption and growth over time becomes essential to decision making about the portal.
Extending SSO - CAS in Luminis
One of the most common WebISO solutions is the Central Authentication Service (CAS) developed by Yale. In Luminis III.2 CAS became available as an installable module. Learn how to get CAS installed, configured, and where it might fit in your organization. See how Plymouth State University has leveraged the phpCAS libraries to CAS’ify all their internally developed PHP web applications as well as a few third-party ones. What’s best, it only takes a couple lines of code!
This topic is for technical audiences
Tags: banner, banner channels, cas, channel, channels, luminis, portal, portal administrator, RDBMSStatsRecorder, single sign on, sso, summit, sungard, sungardhe, web developer, yalecas
Ultimate Directory of Services
March 13, 2006 | 1 Comment
With the many diverse services we offer our users in higher education providing an easy way to find them can often be a challenge. Many institutions have attacked this issue in a series of ways varying degrees of success. It was with this in mind that I’m sure led Middlebury College to develop a service they call “Go”.
This creative solution basically attachs services to keywords to services. These keywords can then be simply appended to the URL ‘go.middlebury.edu’ or just ‘go’ on campus. For example, someone on campus can simply type ‘go/registrar’ and immediately get where they want to go. According to some of their IT guys, this idea started quietly and gradually. The underground movement soon picked up and go became a very poplular service. I can see why.
As an added benefit, they have created a “GOtionary” which is presented to you if you enter a keyword they do not have linked to a service, or you can simply browse it by go directly to go. To add to the power of this system, Middlebury also solicits constant feedback about what should be added to their “GOtionary”. They’ve also created a browser toolbar to bubble up the power of go into their users browsers.
A more common approach for many institutions is to build a monolithic portal application structure where all the various services are linked in (hopefully) appropriate locations. This is a model we at Plymouth State University have operated under for years. This approach has been successful for us, but I think it is interesting to compare the two. These are the questions I ask anyone reading:
Which is more scalable?
Which is more flexible?
Which is more user-centered?
Which rewards repeat users?
Which most intuitive?
What are the learning curves for each, if any?
Are there major drawbacks to one over the other?
Are there major benefits to one that I am glazing over?
Which is the right solution?
Remember, we’re talking purely about findability of services and ease of accessing them. Not about integration, security, identity management, or any of these types of things.
Tags: directory, findability, higher education, keyword, keywords, middlebury, portal, web, web development, web portal, web20, web_20
Leveraging Varying Level of Assurance
March 9, 2006 | 2 Comments
In higher education we all seem to struggle, at least a bit, with coupling together our many varied web services and applications. Part of the difficulty I see is the varied needs for how secure each of the services we delever need to be.
A common reaction to this is to lock things down tightly, requiring your users to reauthenticate on a regular basis to access even the most trivial of services. In this situation users feel encumbered by the security and are less satisfied using these services. Face it, who doesn’t love sites that know who we are and let us do the things we expect when we go back? (ex. Wordpress, Gmail, Flickr, Amazon, etc)
For the purposes of this article, I am defining level of assurance as how sure we are that the user on the other end of the browser is who we think they are.
I imagine an ideal situation where we identify a required level of assurance for each service, then check against an appropriate indicator.
A preliminary structure for varying levels of assurance:
| LOA | Who/How? | Example Services |
|---|---|---|
| Level 0 | Anonymous | Homepage, various public facing pages, etc |
| Level 1 | Long term cookie | Targeted Announcements, News Reader, Personalized Content, Bookmarks, etc |
| Level 2 | Active browser session or desktop domain login |
Email, Learning Management System, Calendar, Groups Tool, etc |
| Level 3 | 30 minute session | Financial Information, Grades, Address Information, etc |
| Level 4 | Every usage | Password change, others? |
In this scenario, users would be asked for credentials less frequently for less secure needs. This in turn encourages them to use many of these types of applications more frequently. In those less secure applications, “ticklers” can be placed encouraging them to register for classes, update address information, or check in on classes in the learning management system all as appropriate. This allows us to draw users into the more secure areas just like Amazon draws us into making a purchase, but always allows us to place things in our shopping cart.
Tags: browser, higher education, identity, identity management, level of assurance, loa, password, portal, session
Summit 2006 Presentation Proposals
October 3, 2005 | 2 Comments
I finally put together all my material to submit proposals for Summit presentations. I looked back at what we’ve been doing in the portal this year and the following is what I came up with. Overall it’s been a busy year, I was surprised to come up with as many as I did.
My Title: Portal Administrator and Senior Web Developer
My Bio
Zach Tirrell is from Plymouth State University in northern New Hampshire. Zach is both portal administrator and senior web developer for the institution. The main areas of his concentration revolve around integrating systems and identity management, Luminis has become a perfect enabler of this. He is often looking to get just a bit more out of Luminis than what is delivered.
Collecting Stats in Luminis
By leveraging the underlying UPortal infrastructure, learn how to take advantage of RDBMSStatsRecorder to generate detailed numbers on who is logging in, logging out, how often, and by role. You can then use these numbers to better understand how effective your portal strategy is. Tracking user adoption and growth over time becomes essential to decision making about the portal.
This presentation is for technical audiences.
YaleCAS in Luminis
One of the most common WebISO solutions is the Central Authentication Service developed by Yale (YaleCAS). In Luminis III.2 CAS became available as an installable module. Learn how to get YaleCAS installed, configured, and where it might fit in your organization. See how Plymouth State University has leveraged the phpCAS libraries to CAS’ify all their internally developed PHP web applications as well as a few third-party ones. What’s best, it only takes a couple lines of code!
This presentation is for technical audiences.
Luminis and Identity Management
While deploying Luminis, or maybe immediately after, lots of questions arise related to identity management. Are you using a central authentication point like LDAP or Active Directory? How do technologies like CPIP or YaleCAS fit into your authentication scheme? What applications should and can use SSO? Are you centrally managing authorization? Is shibboleth something you should be thinking about? How is your password policy? What’s you level of assurance on accounts you have assigned? All these questions and more will be discussed. Come prepared for lots of crowd participation.
LDI Implementation Tips and Tricks
Plymouth State University is starting to reap the rewards of its integrated campus portal strategy. PSU started its Banner migration in 2001, deployed Campus Platform 3 with its legacy SIS in 2002, publicly deployed Banner in 2003, and in 2004 with the migration to Luminis and implementation of LDI for eLearning, has finally reached “critical mass.” Luminis provides the infrastructure and LDI provides the glue that connects Banner, WebCT, the library, and other services. The presentation details Plymouth State University’s implementation and discusses the problems and solutions we faced along the way, with an emphasis on LDI and Luminis. Plymouth State has used this technology to realize the benefits of a unified digital campus.
This is a repeat from last year
Implement and Deploy Banner Channels
Banner 7 comes with a huge pile of exciting new channels. These channels greatly leverage the relationship between Luminis and Banner, however, implementation is complicated and deployment even more so. Banner channels are fantastic, but they need to be rolled out carefully. Plymouth State University has already run this gauntlet, come hear some of the concerns and pitfalls so you can avoid them yourself.
Tags: active directory, banner, campus portal, cas, channel, channels, identity management, integrate, integrated, integration, ldap, luminis, php, plymouth state university, portal, sct, sso, summit, sungard, sungardsct, tirrell, webiso, yalecas, Zach Tirrell, Zachary Tirrell
Expanding the Portal’s Reach
August 4, 2005 | Leave a Comment
As part of my duties lording over our institution’s portal, I am also charged with expanding the reach of the portal. This involves the creation of new roles, new features, improved functionality, and in general anything to make the portal better. Over time I will explore and outline all my plans in these areas.
Interesting of late is the addition of new roles, and more specifically, ones with populations we are not currently serving in the portal. This last January we extended the portal out to all our alumni. A huge undertaking, not technically but more along the lines of determining what content to make available and who will maintain it.
The huge advantage to extending personalized, web based, self service functionality to alumni is in the associated engagement that follows. There are many studies in higher education that show engaged alumni being much more willing to donate time or money back to the institution. How better to keep them engaged then to provide them a portal with integrated email, news services, bookmarks, and entertainment. All while continuing to keep your institution in the forefront of their minds. Additionally the more personalized this feels the more they are likely to stick around and continue using the service. I also like the idea of deploying the alumni portal in the same infrastructure as the existing faculty, staff, student portal. This allows you to present them with a seemless experience and transition them between roles without interruption of service. So we’ve done that and the benefits are obvious. Once someone becomes a student, assuming they graduate, we attempt to keep them engaged online for life.
More recently discussion is now centered around a prospective student portal. Once again, an integrated solution seems best. If this group can be rolled in with all the others, content can be shared, resources pooled, and the experience can remain seemless. Now you have the basis to establish “consumer loyalty” at an even earlier, and arguably, more impressionable age. If the right product is delivered to them at this point, it is likely they will convert into students and go on to alumni who remain engaged.
When we get there, we will not be first, even on this platform. La Salle has already paved the way here, understanding the significant advantage of keeping all the data and users centralized.
Of course this is all theory and institutions nationwide are betting on this. However I feel many of them are going about this all wrong. Any time you make users switch systems or change where you’re pointing them, you are bound to drop engagement. This means once you choose a portal technology, you need to commit to it and do the best you can including all your groups in there.
Beyond these two groups which clearly extend the core student population earlier and later in the relationship, there are other groups who will see value in being members of the portal as well. Parents, visiting faculty, guests, or other population we’ve yet to think of.
I’ve had colleagues argue that these smaller, non-paying constituents are not worth the time and effort to get them integrated. I argue that one central authentication and authorization point, one simple location where all resources can be accessed, one location for all support documentation, for 100% of all users on campus is not only “worth it” but also required.
Tags: alumni portal, identity, portal, role, roles