Overview

Ref 

Objectives 

Deliverables 

Priority 

Benefits 

O1 

Analyse generic API  

D1-Articulate the level of access security required 

D2-Improve current change-based events to make the triggers of SITS change more generic, incl error handling & notifications

D3- Analyse the CAM requirements for the degree finder, clarify what’s in scope for tuition fees

D4- Analyse the Timetabling requirements  

D3.1/4.1 Define the data model for each API, i.e. what the properties does a ‘student’ ( and ‘a programme’) have  

D5- Analyse the future SITS API  

Must 

Must 

Should 

Should

Should 

Should 

D1/D2: 

• consistent mechanisms for data transfer, 

• streamlining integration processes using API/ Tribal’s STUTALK 

• it should improve overall system performance and facilitating seamless data exchange between EUCLID and downstream systems 

D3- replacing the current use of csv files, which are manual steps 

D4- replacing the current EUGEX integration built for EventMap 

D5-when supplier's SITS API becomes available, this could be used 

O2 

Build API 

D6-Build API for Programme and Course information incl tuition fees 

D7-Build API for Student information and Student Course Enrolment 

Must 

Must 

• Future integrations with downstreams systems do not rely on EUGEX update/feeds anymore, reducing dependency on the EUGEX database, especially if we move to the cloud as per Tribal roadmap 

• Scalability, and reducing dependency on SSP development resources to write integrations 

O3 

Test cases the new built API 

D8-Deliver test case: the generic API can integrate with Degree Finder and Timetabling EventMap. SSP will deliver the platform for other services to integrate to. The success of the test case will be to test the data is available to the end points in EUCLID when fetching data. 

D9-Test the change notifications are sent correctly from EUCLID . 

D10-Build dashboard to represent the availability of the end points. 

Must 

Must  

Could 

The expected benefit of this project will be for developers of systems looking to integrate using the API (e.g. Degree Finder, Timetabling) can be confident that the API is robust, and that the integration can be tested/implemented successfully. 

Noting that future benefits if the Degree Finder delivers a separate project to access new API would be significant:  

• Programme data feed, benefit to prospective student web: remove the need for manual work uploading data files into Degree Finder and reducing the overall risk of data errors 

• Entry Requirement (ER): For users, enables future opportunities to present international ERs within programme page and use richer experiences, instead of user needing to navigate a separate website. Reduces numbers of enquiries and wasted applications, by improving presentation and accuracy of information, prospective students are able to better self-serve and self-identify 

• Course information: Reduces need for users to navigate through other systems to find information important to them. Users can better identify if the programme is right for them. Reduce numbers of enquiries because prospective students are more easily able to identify if a programme is right for them.

O4 

Documentation 

D11-Documentation on how downstreams applications can consume the SITS data  

D12-Articulate the Data Access Protocol 

Must 

Must 

Wiki documentation. New API is updated in Abbacus 

The Data Access Protocol process is reviewed in light of the new available API for passing sensitive student data