SITS Interactive Apps at St Andrews Two key

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 Stu. Talk

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 Stu. Talk • Reads SITS data for update over Stu. Talk • Writes decisions back via Stu. Talk web services • Student details, applications, etc. written back via Stu. Talk 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

Stu. Talk Web Services v 8. 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

Stu. Talk Web Services (2) • Poorly designed – JSON in SOAP • XML in JSON in SOAP! – Base 64 in XML in JSON in SOAP!? App Engine Datastore – No use of standard authentication tools – No transaction safety • Slow (200 -500 ms/request) • Limited support for writing multiple records – Embedded XML feeds

Stu. Talk 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> App Engine Datastore <urn: INDATA> { "cap_stuc": "120004054", "cap_apfs": "01", "cap_seqn": "01", "cap_blok": "24", "cap_qstc": "NQ", } </urn: INDATA> <urn: MD 5>b 447291 e 73 dc 268 a 717 e 276 c 2 e 96 da 0 b</urn: MD 5> </urn: ACTION> </soapenv: Body>

Stu. Talk 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

Stu. Talk XML Example <EXCHANGE> <stu. ins> <stu_code>01234567890</stu_code> <stu_had 1>1 Made Up Street</stu_had 1> App Engine Datastore <stu_had 2>Edinburgh</stu_had 2> <stu_hapc>EH 1 2 AA</stu_hapc> <stu_haem>student@example. org</stu_haem> </stu. ins> </stu> </EXCHANGE>

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

Stu. Talk 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 Stu. Talk? – “Beta” API in 8. 5. 1

Suggestions • Stu. Talk 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?