1. myRutgers Alerts Terry Wooding Assistant Controller
Student Financial Services
Bill Thompson
Associate Director – Architecture & Engineering
Enterprise Systems & Services

2. Business Drivers
Recent focus on student service delivery has highlighted areas in need of improvement which could be addressed by an expansion of online web services.
Facilitate streamlining of services and service integration where appropriate to enhance customer satisfaction.
Provide personalized and customized service delivery for Rutgers constituents through the development and expansion of the myRutgers university portal.

3. Alert Students of Financial Holds via myRutgers
Enhancement to the myRutgers to alert students of Financial and Immunization Holds (placement and removal) on April 1st 2005.
Alert message, which directs students to login to myRutgers to view the alert detail.
Financial Hold Information screen showing all financial holds on student’s account for student to view over the web and print a bill for payment.

4. Alert email directs students to myRutgers

7. Alerts Channel - provides student notification of Financial Holds including department and telephone number for additional information

9. Financial Hold Information Screen
This screen displays the cumulative financial holds on a student’s records and provides totals by department and contact phone numbers.
This screen also provides a link where students can print a Hold bill to then mail payment to RU.

11. Printable Bill

12. Bottom portion of Printable Bill

13. Screen allows Administrators to access Hold data on student records

16. IMS Registration Hold Screen allows Administrators to access Hold data on student records

17. Registration HL D Screen

18. Outcomes Timely notification of changes in status or non-compliance
Student show up at service desks with Alerts printed out
Increase in student compliance
Reduce need for costly notification letters

19. myRutgers Alert System
Architecture
Portlet & Filter
Web service
Authentication & Authorization (CAS & ACEGI)
Integrating with Legacy Systems

20. Alerts Architecture Alerts Alert Manager Data Access Layer
Notification Schemes
Acknowledging Alerts

21. Alerts Alert users to business events
Immunization hold
Financial Obligations
Parking Fines
Allow users to acknowledge receipt of an alert

22. Alert Manager Provides access to a user’s Alerts & Preferences
Get listings of alerts
Get an individual alert
Acknowledge alerts
Utilized by other system elements to retrieve & manipulate a user’s alerts

23. Data Access Layer Separate DAOs for Alerts and Preferences Spring JDBC
Could be replaced with iBatis, Hibernate, JDO implementation

24. Notification Schemes Notify users of new alerts Customizable Email
Header
Login
Customizable
Default scheme
Custom user scheme

25. Acknowledging Alerts New Alerts begin unacknowledged
Header & Login notifications are active if a user possesses unacknowledged alerts
Users manually acknowledge alerts
myRutgers records the date an alert was acknowledged

26. Open Source Glue
Spring, PortletMVC
ACEGI
CAS
Apache AXIS

27. Alerts Portlet Portlet API (JSR-168) Spring PortletMVC
uPortal IChannel -> Portlet Adaptor
Spring PortletMVC
Reuse sub-system wide domain tier objects (AlertsManager, Preferences, DAOs, etc.)
Enforce MVC pattern design
Pluggable view technologies
Eliminates “plumbing” code

28. Alert Login Filter Implements login notification
Instantiates an Alert Manager
Checks for unacknowledged alerts
Checks user’s Notification Scheme to see if login notification is active
If 2 & 3, redirects user to Alerts portlet in focused mode

29. Alerts Web Service Overview
Standards-based SOAP web service
Cross-platform (Java, .Net, Perl, etc.)
Toolkit support (Apache AXIS)
Standard ports (firewall & router friendly)
Access to service protected
Authentication – CAS
Authorization - ACEGI
Toolkit support – take public WSDL document and automatically generate client side code to interact with service

30. Authentication & Authorization
Application authenticates through CAS
Application received service ticket
Application HTTP-basic authenticates with web service
ACEGI validates service ticket with CAS
ACEGI passes session to webservice, or returns HTTP 401 Access Denied
Alerts web service communicates with client

31. Publishing Alerts Integration Scenarios:
Use Alerts web service to publish Alerts
Use intermediary to talk to web service

32. Legacy System Integration
Data/processes on IBM mainframe
Numerous homegrown systems
SOAP integration possible, but untried
Solution:
Database staging table
Standalone AlertPublisher client
Advantage:
Leverage existing mainframe developer skills

33. Alert Publisher
1. Mainframe job writes AlertRequests to the database staging table.
2. AlertPublisher program reads request from DB staging table.
3. AlertPublisher authenticates via CAS obtaining a service ticket.
4. Alert Publisher authenticates with myRutgers Alert Service.
5. ACEGI authenticates service ticket
6. AlertPublisher publishes AlertRequests, recieves alertID for each published alert
7. AlertPublisher writes alertID and published date for each successful request to the DB staging table.

34. Ideas for Future Alerts
Library loan, overdue books
Books that are about to overdue
Grade received
Wait list…
Provisional marks / review
Financial aid milestones/process
Scholarship application/ change of grade
Academic probation
Class closings (for those registered for that class)
Room change
Workflow for grant applications

35. Ideas for Future Alerts
Registrations are canceled for nonpayment of term bill
Grade changes
Class closings (for those enrolled in the class)
Notification of account closings, quota violations, bandwidth abuse
Room and time changes (for those enrolled in the class)
Financial aid notifications

36. Questions? Terry Wooding Assistant Controller
Student Financial Services
Bill Thompson
Associate Director – Architecture & Engineering
Enteprise Systems & Services
Presentation URL –
uPortal 2.6? Or addon?

37. Alerts Web service