1. Migrating to uPortal 2 at UBC Paul Zablosky University of British Columbia Copyright Paul Zablosky 2003. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author.

2. History  uPortal 1.0 –Paper for EDUCAUSE 2001 –www.educause.edu/asp/doclib/abstract.asp?ID=EDU0109  The inevitable conversion  Why we did it –Stay current with the community –Take advantage of new rendering model and database –Recover on our investment in database design and implementation

3. The Project Objectives  Re-implementation of myUBC on uPortal Release 2  Maximized compatibility  Preservation of existing channels  Preservation of user profiles (layouts)  Improved functionality for selected channels  Equivalent or improved response and performance  Redesigned User Interface  No changes required by content providers

4. Challenges  Compatibility  Equivalent Robustness, Reliability  Performance  Integration with UBC Infrastructure  CWL Authentication  CWL Roles  CWL User ID’s (internal keys)  Oracle database

5. The Team - organized around roles  Project Sponsor –Champions the project  Project Manager –Creates the project plan. Organizes and directs resources throughout the project  Database Administrator –Responsible for all aspects of managing the database resource, including conversion.  Chief Programmer –Responsible for all framework programming tasks

6. The Team – roles continued  Java Developers –Design software solutions for assigned tasks  Platform Constructor –Builds operational service platforms for development and production – hardware and operating system  Testers – functional –Responsible for all functional and regression testing  Testers – technical –Perform volume, load, and stress tests

7. The Team – roles continued  Style and Presentation Coordinator –Manages the presentation structure (themes & skins), graphic design, navigation, and usability.  Business Analyst –Responsible for user issues, usability, compatibility, communications, documentation. Also liaison with Help Desk, stakeholders, and partners.  Software librarian –Performs all builds, integrations and promotions  Technical Writer –Creates technical and user documentation

8. The Team – roles continued  Webmaster –Installs and configures the Apache Web Server and the Tomcat container. Manages their interactions  Graphic Designer –Designs and creates images (skin & theme work)  HTML Developer –Creates HTML (skin & theme work)  XSLT/Java Developer - Develops XSLT transforms (skin & theme work)

9. The Development Environment  The base platform (uPortal 2.0.3)  UBC Channels  CVS Repository  UBC Infrastructure (CWL, Oracle)  Shared Instances: DEVL EVAL VERF PROD  Promotion between instances  Channel Definition Tool

10. The Development Environment (cont.)  Database Instances  DEVL VERF PROD

11. Platforms  Shared Development Platform –Sun V120 2GB  Production Platform –Server: SunFire 280R 2x750MHz CPU 4GB, Solaris 8 - Java Version: 1.4.2-beta –Database: Oracle 8.1.7.2 –Connection Pooling: Oracle with thin JDBC drivers –Container: Tomcat 4.1.24 –Web Server: Apache 2.0.45 (mod_jk2)

12. The Development Process  Spanned several months  Iterative with ongoing testing –Framework and database access –Data conversion tools –Channel refinement and publication –User interface and skins –Operational environment, container, and Web Server

13. The Migration Challenge  UBC-specific code (e.g. CWL authentication)  The channels  The user data –Layouts –Address-book entries –Bookmarks –Mail preferences  The conversion process (40 hours)

14. Performance & Reliability Challenges  Connection pool blocking  DBCP degradation  Poolman option  Oracle pooling  Read-only connection

15. Cutover process  Existing operational service  Orchestrated procedure  Backout procedure  New service running on a “test” URL  Shutdown, reconfigure, startup  7 minute outage

16. And it ran perfectly…  Needed to back out once  Second time lucky  22,000 logins in our first 26 hours of operation  User feedback

17. Working with Partners and Providers  Institutional conventions and consistency  Content providers  Other partners

18. Lessons Learned  The technology is still maturing  Development times are hard to estimate  Test test test

19. Visit us at http://my.ubc.ca Email: Paul.Zablosky@ubc.ca