Monthly Archives: March 2010

An SWS Client Use Case: College of Education

This article is an overview of how the College of Education is using the Student Web Service (SWS) in its advising web application: STEP (Student Tracking of Educational Progress).

STEP is web based tool used at the College of Education by faculty advisors and administrative staff to view student information. STEP incorporates UW central data (student information and transcript information) with local college data (advisor information, degree milestones, internships, placements, etc).

STEP currently uses five resources available through the SWS.

  1. Person – We use the person resource to lookup student RegIDs. Our application was originally based entirely off of the UWSDB so we have System Key as our identifier. We need RegID because that is the student identifier all the services expect.
  2. ID Card – There is a place holder silhouette in the screen shot, but the app brings in the student’s Husky Card photo through the ID Card service.
  3. Registration – This service populates the “Currently Enrolled” tab. That module was built before the Enrollment service existed, but now that same data is available through the Enrollment service.
  4. Enrollment – We use this service to populate the “Transcript” section.
  5. Courses – For both “Currently Registered” and “Enrollment” we use this service to get the full course title.

STEP is a PHP application. We use the CURL and SimpleXML libraries to help with the service request and parsing the response.

Sample code is available, demonstrating how to connect to the SWS using PHP, CURL, and SimpleXML. That code here. STEP uses a slightly modified version of the SimpleRestClient.php class.

Most of the data presented in STEP runs live off of the service. For a couple more static items (ID card photos, and course titles) we implemented a local cache.

Since the “Transcript” takes a couple of seconds to load (varying by length) we decided to load the page with the section hidden. When a user expands the section they get a “Loading…” and ajax spinner while the service request is made and parsed.

The whole process was fairly easy to implement. If I had to pick out one challenge it would be mapping the location of the data you need in the service payload. The SWS currently provides an XHTML payload. This format is great for development and debugging since you can easily examine the service in a browser. However, it makes parsing the XML with a library like SimpleXML less elegant than if the service used a custom XML vocabulary.

Instead of code that looks something like this (if SWS had custom a XML vocabulary).


We have to map to specific fields like this (to specify a path through an XHTML document).


You only have to work out this mapping once and there are multiple ways to locate data (e.g. XPath searches) so it is not a huge obstacle. SWS team also has an XML version of the service on its to-do list.

We are currently in development on calculating credits and GPA based on the webservice. That was mostly an exercise in defining our business rules. We are waiting for one fix from SWS before rolling it out. That same change will allow us to update several degree milestones based on the service.

There are a couple things the SWS does not provide. We have to start with an existing student list since there is no existing service to tell us who are students are. We still import contact information (address, phone, email) from the UWSDB. We hope these fields will be available in the person resource in the future.

Our system was originally designed to allow students to access their own record. However it was a major internal change to get our local data moved to this application and we decided to shut off student access until we are confidant the local data is up to date.

Paul Hanisko
Web Developer
UW College of Education]]>