SITS Interactive Apps at St Andrews Two key applications that interact with SITS: –MMS: institutional data flow management tool suite –Admissions: does what it says on the tin As of Jan 2013 MMS is read/write via DB Admissions is read via DB, write-back using StuTalk

MMS MMS is primarily designed to minimise manual handling of data Extracts data from SITS over database links, including: –Courses, course enrolment –Degree intention, supervisors (PGR) –Course results for degree classification –Exceptional circumstances –Disability information

MMS (2) Data written back semi-automatically CSV files generated for end-of-course results Imported in batch operations through SITS client As of Jan 2013, work partially completed for writing back automatically as XML feeds

MMS (Students on Module)

Admissions Reads SITS data directly from database –Performance issues performing mass-reads over StuTalk Reads SITS data for update over StuTalk Writes decisions back via StuTalk web services Student details, applications, etc. written back via StuTalk XML

Admissions (Applicant Import)

Feedback Very positive response to user interfaces –Substantially simpler to adopt institutional look and feel –SITS-specific detail generally hidden from user Issues with performance Issues with reliability Hiding implementation detail can cause confusion

StuTalk Web Services v8.5.1 SOAP based Ability to run processes –Assign new student ID –Generate reports –Etc. Immediate feedback on success/failure –Useful for development –Well suited to small interactive tasks –Can report outcome directly to user

StuTalk Web Services (2) Poorly designed –JSON in SOAP XML in JSON in SOAP! –Base64 in XML in JSON in SOAP!? –No use of standard authentication tools –No transaction safety Slow ( ms/request) Limited support for writing multiple records –Embedded XML feeds App Engine Datastore

StuTalk Web Services Request stutalk topsecret JSON DMU {"ACTION":"UPDATE","DCT":"SRS","ENT":"CAP"} { "cap_stuc":" ", "cap_apfs":"01", "cap_seqn":"01", "cap_blok":"24", "cap_qstc":"NQ", } b447291e73dc268a717e276c2e96da0b App Engine Datastore

StuTalk XML Intended for bulk data import/export Appear more robust for simple data sets Some issues with mixed data sets Writing back inter-related data sets has issues with primary key generation –For example CAP, APF and STU for a new student application Require shared space for storing XML files

StuTalk XML Example Made Up Street Edinburgh EH1 2AA App Engine Datastore

Reading by Database Fast –Especially joining tables Risk of issues due to schema changes Non-database fields cannot be accessed –Unaware of any times this was an actual problem

Writing by Database Fast, however: –No SITS triggers –No integrity constraints –No feedback Cannot run processes –For example student ID assignment Usable only in very simple use-cases

StuTalk Interaction Layer Developed in-house at St Andrews Web service & XML wrapping layer Hides implementation details –Allows easy re-targeting of SOAP & XML interfaces Simple object-mapping layer –Data object definitions automatically generated from SITS ENT & FLD records

Summary In theory, good In practice, some significant challenges Likely to be worth persevering with Upcoming changes/improvements to StuTalk? –“Beta” API in 8.5.1

Suggestions StuTalk XML feed into EUGEX Staging database for changes to go to SITS Work with Tribal on API to improve key issues: –Lack of transaction support –Performance (session instantiation?) –Read/write related records as a batch

Questions?