myRutgers Alerts

1. myRutgers Alerts Terry Wooding Assistant Controller Student Financial Services twooding@sfs.rutgers.edu Bill Thompson Associate Director – Architecture & Engineering Enterprise Systems & Services wgthom@rutgers.edu

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 email 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 999 99 9999

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 • 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) • 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

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

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 twooding@sfs.rutgers.edu Bill Thompson Associate Director – Architecture & Engineering Enteprise Systems & Services wgthom@rutgers.edu Presentation URL – http://www.rci.rutgers.edu/~wgthom/JASIG2005/

37. Alerts Web service