SITS Interactive Apps at St Andrews
description
Transcript of SITS Interactive Apps at St Andrews
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
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
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 (200-500ms/request) • Limited support for writing multiple records
– Embedded XML feeds
App Engine Datastore
StuTalk Web Services Request<soapenv:Body> <urn:ACTION> <urn:USER>stutalk</urn:USER> <urn:PASSWORD>topsecret</urn:PASSWORD> <urn:DELIMITER>JSON</urn:DELIMITER> <urn:FUNCTION>DMU</urn:FUNCTION> <urn:PARAMETERS>{"ACTION":"UPDATE","DCT":"SRS","ENT":"CAP"}</urn:PARAMETERS> <urn:INDATA> { "cap_stuc":"120004054", "cap_apfs":"01", "cap_seqn":"01", "cap_blok":"24", "cap_qstc":"NQ", } </urn:INDATA> <urn:MD5>b447291e73dc268a717e276c2e96da0b</urn:MD5> </urn:ACTION> </soapenv:Body>
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<EXCHANGE> <stu> <stu.ins>
<stu_code>01234567890</stu_code> <stu_had1>1 Made Up Street</stu_had1> <stu_had2>Edinburgh</stu_had2> <stu_hapc>EH1 2AA</stu_hapc> <stu_haem>[email protected]</stu_haem> </stu.ins> </stu></EXCHANGE>
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