Archive for March, 2010

New Financial Web Service Requisition Resource

UW Information Technology’s (UWIT) Information Management (IM) division (formerly the Office of Information Management) released to the University community a new component of its Financial Web Service (FWS): the Requisition resource.  This new data set provides campus developers programmatic inquiry access to near-real-time requisition data stored in the University’s central systems. The Requisition resource builds upon FWS’ existing budget and organization resources, to which it naturally relates.

This work could not have been accomplished without a unique and very successful partnership between the Office of Research Information Services (ORIS) and UWIT-IM.  ORIS’ System to Administer Grants Electronically (SAGE) has a critical need for programmatic access to a small portion of the requisition dataset: the budgets associated with a requisition.  However, SAGE staff understood and promoted the value of delivering the full dataset instead. To achieve this, ORIS contributed full-time development resources to do all of the coding and initial testing and UWIT-IM provided data expertise, developer support and quality assurance. This shared-development partnership was very successful and is a great example of how generic, reusable business services can be built that realize broader business needs, rather than just those of an individual project.

This was all achieved on a very short timeline without interrupting other higher priority work for any of the three participating teams. The mutually goal-oriented approach to “doing the right thing” technically resulted in excellent cross-team synergies. This was manifested both in the ultra-short duration of the planning/implementing/release process and the quality of the overall product. It also allowed for excellent cross-team pollination of ideas/technologies. The UWIT-IM web service code framework and authorization scheme, developed by Application Integration Services, was a valuable tool in facilitating rapid development and deployment.

This experiment was so successful that we all look forward to future similar collaborations moving forward.

No Comments

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

$xml->student->term[0]->course[2]->course_number;

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

$xml->body->div->ol->li[0]->div[9]->ul->li[0]->div[1]->a->span;

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
hanisko@uw.edu
Web Developer
UW College of Education

,

1 Comment

Web Service Discussion Group Ignites! Thursday March 4

When: Thursday, March 4 from 3-5pm.

Where: Odegaard Undergraduate Library, Room 220

Who…

1. Brian Ferris (CSE) – OneBusAway: Improving the Usability of Public Transit

2. Zephyr McLaughlin (UW Tech) – Getting Our Umbrellas Wet – A Cloud Integration Story

3. Scott Stephenson (Office of Information Management) – Enterprise Architecture and Web Services: Better Together

4. David Morton (UW Tech) – Mobile Authentication: The Current State

5. Jim Earnshaw (Chemistry) – How a ‘Nonprogrammer’ Uses the Group Web Service RESTful Interface

6. Nathan Dors (UW Tech) – A Top 20 Countdown: the Service Catalog

7. Darcy Van Patten (OIM) – Moving from Redundancy to Reuse: on the ROAd to SDB replacement

8. Tim Bond (Informatics) – Course Enrollment Tracker

9. RL “Bob” Morgan (UW Tech) – OAuth Magic

10. Paul Schurr (OIM) – Three Cheers (and One Jeer) for Kuali Rice

11. Matt Winslow (Registrar) – The R25 Web Service

12. Jaewha Lee (OIM) – Bring It On! The Person Web Service

13. Sean Vaughan (UW Tech) – REX: Simple SQL-XML-ReST Mapping

14. Tony Chang (OIM) – The Greatness that Is the SWS Enrollment Resource

No Comments