1 / 20

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.

cecil
Download Presentation

SITS Interactive Apps at St Andrews

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. 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

  3. 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

  4. MMS (Students on Module)

  5. 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

  6. Admissions (Applicant Import)

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. Questions?

More Related