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
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.
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.
Alert email directs students to myRutgers
Alerts Channel - provides student notification of Financial Holds including department and telephone number for additional information
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.
Printable Bill
Bottom portion of Printable Bill
Screen allows Administrators to access Hold data on student records
IMS Registration Hold Screen allows Administrators to access Hold data on student records
Registration HL D Screen 999 99 9999
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
myRutgers Alert System Architecture Portlet & Filter Web service Authentication & Authorization (CAS & ACEGI) Integrating with Legacy Systems
Alerts Architecture Alerts Alert Manager Data Access Layer Notification Schemes Acknowledging Alerts
Alerts Alert users to business events Immunization hold Financial Obligations Parking Fines Allow users to acknowledge receipt of an alert
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
Data Access Layer Separate DAOs for Alerts and Preferences Spring JDBC Could be replaced with iBatis, Hibernate, JDO implementation
Notification Schemes Notify users of new alerts Customizable Email Header Login Customizable Default scheme Custom user scheme
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
Open Source Glue Spring, PortletMVC ACEGI CAS Apache AXIS
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
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
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
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
Publishing Alerts Integration Scenarios: Use Alerts web service to publish Alerts Use intermediary to talk to web service
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
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.
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
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
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/ uPortal 2.6? Or addon?
Alerts Web service