230 likes | 406 Views
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.
E N D
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>student@example.org</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