myrutgers alerts terry wooding assistant controller student financial services...
Post on 21-Dec-2015
217 Views
Preview:
TRANSCRIPT
myRutgers Alerts
Terry WoodingAssistant ControllerStudent Financial Servicestwooding@sfs.rutgers.edu
Bill ThompsonAssociate Director – Architecture & EngineeringEnterprise Systems & Serviceswgthom@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.
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.
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
1. Alerts2. Alert Manager3. Data Access Layer4. Notification Schemes5. 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
DAO
Web ServicePortlet Login Filter
AlertsPreferences
Alert Manager
Data Access Layer Separate DAOs for
Alerts and Preferences
Spring JDBC Could be replaced
with iBatis, Hibernate, JDO implementation
DAO
Web ServicePortlet Login Filter
AlertsPreferences
Alert Manager
Notification Schemes Notify users of new
alerts 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
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
Alert Login Filter
Implements login notification1. Instantiates an Alert Manager2. Checks for unacknowledged alerts3. Checks user’s Notification Scheme to
see if login notification is active4. 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
Authentication & Authorization1. Application
authenticates through CAS
2. Application received service ticket
3. Application HTTP-basic authenticates with web service
4. ACEGI validates service ticket with CAS
5. ACEGI passes session to webservice, or returns HTTP 401 Access Denied
6. Alerts web service communicates with client
myRutgers Alert Service(SOAP w ebservice)
ACEGICAS
Application PublishingAlerts
12
4
5
12
5
4
3
6
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
myRutgers Alert Service(SOAP w ebservice)
ACEGICAS
AlertPublisher
11Alert RequestStaging Table
Mainframe
1
2
1
17
6 4
5
3
1. Mainframe job w rites AlertRequeststo the database staging table.
2. AlertPublisher program reads requestfrom DB staging table.
3. AlertPublisher authenticates via CASobtaining a service ticket.
4. Alert Publisher authenticates w ithmyRutgers Alert Service.
5. ACEGI authenticates service ticket6. AlertPublisher publishes AlertRequests,
recieves alertID for each published alert7. AlertPublisher w rites alertID and published
date for each successful request to theDB 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
6/14/2005 myRutgers Alerts 36
Questions?
Terry WoodingAssistant ControllerStudent Financial Servicestwooding@sfs.rutgers.edu
Bill ThompsonAssociate Director – Architecture & EngineeringEnteprise Systems & Serviceswgthom@rutgers.edu
Presentation URL – http://www.rci.rutgers.edu/~wgthom/JASIG2005/
top related