Overview

The CSC(Chico State Connection) Portal is a model of simplicity. We use CAS for single sign-on which allows us to use the portal to send people to other applications without having to try and recreate their functionality in the portal. We rely heavily on Web Proxy and RSS channels to present information inside the portal. We have a very small "team" that administers/develops the portal, so this is the strategy that works best for us.

		YUI Grids and prominent user support information	Updated with YUI Grids

How uPortal Makes Our Life Easier

Our portal aims to do what all portals do, give users a central point to access institutional information. We don't want to compete with Google, or Yahoo!, or My Space, or Craig's List. We aim to provide access to the services which are unique to our campus.

For Students

Students have a relatively simple layout that initially consists of four tabs: "Student Home", "Records, Registration, & Finances", "Campus Life", and "My Stuff." Students rarely venture past the first two tabs which contain the most critical information and applications. Student Home gives them single sign-on access to WebCT Vista (via the WebCT Channel using the WebCT API) and web mail (HORDE/IMP+CAS). There is also a "Systems Status" channel to alert them to any downtimes, student announcements (run by the Public Affairs department), and a weather image. The RR&F tab is where students go to get access to PeopleSoft which manages almost everything that isn't WebCT or e-mail. The links are to specific pages within the Self-Serivce part of PeopleSoft SA which has been CAS-ified so there is not additional authentication.

For Faculty

• WebCT
• PeopleSoft for grading and class schedules
• Easy access to support documentation and links

For "State Employees"

Human Resources consider anybody who receives a paycheck from the state (be they student, staff, or faculty) to be a "state employee." We created a tab for this group that has links to important PeopleSoft pages (paycheck stub, vacation hours, benefit information, etc.). There are also channels for commonly used HR forms and informational links.

Framework Enhancements

We have avoided making modifications to the framework, not only because we don't have a large developer team but because we don't want to "stray from the flock." When we first launched we ran into a "show stopper" bug in the AggregatedUserLayoutStore implementation. With the help of Unicon we fixed the problem and the fix has made it's way back into the base code.

The Team

The portal is a cross-department effort, pulling resources from the following areas for daily operation.

• Server Administration (security patches, OS maintenance, etc.)
• Network Administration (Cisco CSS maintenance, network monitoring, etc.)
• Database Administration
• Application Administration (uPortal deployment, tomcat configuration, CAS deployment, content wrangling)

None of the people working in these areas are devoted to the portal full-time. For the non-Application folks, most spent the majority of their time on the portal during the initial setup phase and after that it was just trouble shooting or scheduled maintenance (kernel upgrades, database patches, network maintenance, etc.).

The Technical Details

The portal services over 15,000 student, 900+ faculty, and almost 1,000 staff users. Our scaling strategy again relied on keeping things as simple as possible, leveraging existing resources whenever possible.

Server Hardware

We run the production portal web/application servers on two Dell 2850s with dual Xeon 2.80GHz CPUs and 2 GB of RAM. There are two other identical web/app servers for testing/QA and development.

Scaling

Our portal web/app servers are behind two Cisco 11501 CSS's which handle load balancing and SSL offloading. The Engine directive in the tomcat server.xml was altered to set the jvmRoute to the hostname of the server. This greatly increased performance on the content switches as they didn't have to do all the cookie work. Tomcat tacks on the value of jvmRoute to the end of the JSESSIONID cookie and the switches can be configured to look for that value when making the decision on which server to send the request to. Our tomcat servers are not running in a cluster, again to keep things as simple as possible.

<Engine name="Catalina" defaultHost="localhost" debug="0" jvmRoute="uportal4">

gives us the following value for the JSESSIONID cookie

09E9EA2060F2C3C1376014C005075438.uportal4

Operating Systems

We run RedHat Enterprise Linux. The version we currently run on is RHEL 3 AS (32bit version). We have not seen any issues related to the OS.

Software versions

• uPortal 2.6.0
• JVM 1.5.0_12
• Tomcat 5.5.23