Download presentation
Presentation is loading. Please wait.
Published byJamya Billingsly Modified over 10 years ago
2
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
3
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
4
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
5
MMS (Students on Module)
6
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
7
Admissions (Applicant Import)
8
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
9
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
10
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 (200-500ms/request) Limited support for writing multiple records –Embedded XML feeds App Engine Datastore
11
StuTalk Web Services Request stutalk topsecret JSON DMU {"ACTION":"UPDATE","DCT":"SRS","ENT":"CAP"} { "cap_stuc":"120004054", "cap_apfs":"01", "cap_seqn":"01", "cap_blok":"24", "cap_qstc":"NQ", } b447291e73dc268a717e276c2e96da0b App Engine Datastore
12
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
13
StuTalk XML Example 01234567890 1 Made Up Street Edinburgh EH1 2AA student@example.org App Engine Datastore
14
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
15
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
16
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
17
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
18
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
19
Questions?
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.