LRT along with Financial and Legal Services (F&LS) have recently developed a new web application that allows students to see an overview of their financial information whenever they log in to the myMMU SharePoint portal. This has been designed to highlight urgent messages about overdue fees, provide an easy-to-understand breakdown of which fees are due, and allow students to request a detailed financial statement to be emailed to them.
Part of the need for such an application is to increase the flow of financial information between F&LS and individual students. Increasing student engagement and enhancing the student experience were key reasons for this development. By displaying this information on the front page of the portal, students are immediately made aware of any financial issues that may need urgent resolution. The development of this Portal initiative, along with current Credit Control procedures including telephone, texts, letters and emails, provides the student with up to date information.
This joint venture was created as a result of listening to students and delivering a concept that is easy to understand, informative and adds value to the wider University. The concept alerts students to fee status information every time they log in to check email or access the VLE. This application consists of a front-end implemented in SharePoint Web Parts, and a web services backend.
SharePoint Web Parts
The message above is displayed on the front screen of the myMMU portal whenever there are overdue unpaid fees. This is at the top of the page to make it as visible as possible. The red traffic light signals a problem and grabs the attention of the user, or if there are unpaid but not yet due fees an amber traffic light is displayed instead. No message is displayed on this page if there are no overdue fees.
The second part is more detailed information which displays fees by category. The traffic lights are used again to make it easy for users to see which fees are a problem. The button underneath the traffic lights allow students to request a financial statement, which generates an automatic email to students by F&LS through an overnight process.
Financial Web Services
All financial information is held within the University’s SAP finance system. Part of the challenge was to ensure complete security and privacy around personal financial data. Discussions between LRT and F&LS quickly agreed on a service-oriented approach in which nightly reports inside the SAP system would feed through summarised fee status information for each student in a database table. This table was visible to a web service written by the F&LS team. A second web service would allow students to request a full financial statement be emailed to their registered email address. To accelerate development and testing, LRT decided to create proxy web services that would eventually call the financial web services but could return test data in the interim.
The following steps were taken in consultation with F&LS in order to meet security and privacy requirements:
- Sensitive financial data were summarised by a process within SAP and exported to a table as student id and fee status indicators only, no value data was visible.
- A database user with read-only access to the summarised table was set up to make queries for the finance web service
- A token-based protocol, using a one-way hash of parameters with a timestamp and shared secret, was agreed to enable the financial web services to confirm they had been called by a legitimate user before responding
- Firewall settings ensured that only trusted machines could access the financial web services
The token-based protocol was also used for the proxy web services, which forwarded calling parameters and tokens to the financial web services and returned responses received.
Since the service was launched on Wednesday 17th November 2010:
- There have been 157627 hits to the finance web service on testapis (as of 4pm on 30th November 2010). Note that this does include all 30,000+ students, even students who aren’t first year students (who will not be able to see any financial info) will create a hit on testapis, which will return a null value.
- There have been 790 requests for financial statements using the traffic lights webpart. Only first year students who have unpaid fees can request a statement, so this is a significant number of roughly ten thousand MMU students who are in their first year of study.
The services are delivered to the student through MMU’s SharePoint portal, my.mmu.ac.uk. The front page gives students a short announcement when they login if any fees are overdue through a in-house custom “Urgent News” web part, with a link for more information. When a user clicks on this link they are taken to a different SharePoint page with another custom “Traffic Lights” web part with more detailed information.
The overall architecture is shown in the diagrams below:
These web parts call LRT’s proxy webservice on testapis.mmu.ac.uk with parameters containing student ID, the one-way hash authentication token, and return format. The return type can be XML, RSS, or Atom which allowed us to develop a single web service that could be consumed by the two web parts, and should make it easier to extend this service to different applications in future.
When testapis receives a request it checks the authentication token is valid. It checks the student records system to retrieve the student’s institution ID (which identifies students on the finance systems) and to check that the student is on the first year of their studies. This is shown as step 2 and 3 in the diagram. If the student is not a first year student, null is returned from the service, and nothing is displayed on the SharePoint page. The webservice uses C#.NET and REST architecture.
Testapis calls the finance webservice and forwards the authentication token, and the institution ID, queries the SAP database fee summary table, and returns this as XML as step 7 in the architecture diagrams. An example of this XML is below:
- <responseDate>20.09.2010, Time : 10:56:10</responseDate>
Testapis receives this – if the return format is XML it formats the date and removes the student ID, before passing the data back to the calling service in step 8 of the Traffic Lights diagram:
- <updated>30/11/2010 04:37 GMT</updated>
On the other hand if the requested format is RSS, testapis uses the abstract .NET SynchronisationFeed class to create a different feed item for each of the fee types – tuition, accomodation, and other. This contains a message that is readable and useful for students rather than the numbers indicated above:
- <rss version="2.0">
- <title>Fee Status</title>
- <description>Information on your current MMU fee status</description>
- <guid isPermaLink="false">2</guid>
- <title>Tuition Fees paid</title>
- <description>Processed invoices to-date already paid. Thank you.</description>
- <guid isPermaLink="false">1</guid>
- <title>Urgent: Accommodation Fees Overdue!</title>
- <description>Invoices are overdue for payment (if applicable these will also include any invoices paid on your behalf by your employer/sponsor). Please contact your Faculty Finance Office if you are paying your own fees and have not agreed an instalment plan.</description>
- <guid isPermaLink="false">3</guid>
- <title>Other Fees</title>
- <description>Financial status is not applicable at this moment.</description>
The SynchronisationFeed is converted into RSS (or Atom depending on what format was requested) before being passed back to the caller in step 8 of the Urgent News. Finally the student (who is a fully enrolled first year) is shown the custom web parts below:
Our next step is to find appropriate ways to make this information available to students on their mobiles. We have previously considered the possibility of a token-based approach for delivering private and personalised information to W3C widgets (2010-09-14) and we hope to explore the potential of the approach for this sensitive data in consultation with F&LS colleagues.
Web Parts and XSLT coded by Ludovic Tolhurst-Cleaver & Mark Stubbs
XML schema developed by LRT & F&LS
Finance Web Service and Traffic Lights Graphics developed by F&LS
LRT Proxy Web Service developed by Alexander Lee