Impact

Priority and Funding

This is a discretionary project, core funded by additional USG/CSI funding 

Priority normal (per current priorities of projects within SSP programme), this has been prioritised within CSI roadmap, see LINK 

Impact and Dependencies

Dependencies:  

• From SITS upgrade for the lead developer, who is expected to support the upgrade over Dec-Mar (risk) 

• (soft) would like access to Tribal API available within the next version of SITS 10.8 (already released) and 10.9 (released in Dec 24 tbc) so that we can produce a version of it, and expect our build to be closed to it  

• (soft) data dictionary / naming conventions already used in IS/Admission BI for documenting Abbacus (risk) 

Impact:  

• The Timetabling (funded) roadmap includes integration work to use API from current Eugex feed to be done in winter 2024/25, to integrate in Feb/Mar 25 in live before next peak period , risk added 

  Impact to other projects

Lessons learned from previous projects

Two integrations have been written previously to send data from SITS using STUTalk and a publish subscribe model we can draw a fair amount of experience from.  

The First was the integration to People & Money and Enquiry Management. From this we learned three things.  

• The platform on which we designed the integration required an SSP resource to write the integration because it was heavily embedded into the SSP framework. We should instead attempt to abstract the integration behind a REST API to reduce the dependency on an SSP resource when future integrations are required.  

• From a support perspective the error presented inside of WSO2, this works well if the error is of a technical nature. However, a data quality issue would need to be fielded by the technical support team before finding its way back to Student Systems. This caused unnecessary delays and additional work by the technical support team.  

• Finally, the data was sent out with the trigger from SITS and as we performed the store and forward component of the integration in WSO2 the error recovery process became complicated as we needed to ensure the integrity of the queue. If a message errors and is placed in the error queue, the currency of the message needs to be checked, and the payload may need to be regenerated from within SITS which are both manual processes. This can be addressed by keeping the integration within SITS using WSO2(Choreo) as a proxy to manage security and versioning. We would trigger the change from SITS and then use REST APIs to fetch the most recent version of the data from SITS while the trigger is being processed. Thus, allowing downstream integrations to be responsible for their own error handling. Or, a callback into SITS needs to exist whereby a payload is regenerated automatically on errors before starting the integration from again. The second option would rely on the downstream system correctly and restfully handling the error so that a data issue doesn’t get stuck in a loop through the integration.  

The Second integration we can draw experience from is the Advocate (Student Case Management) integration.  

• In this we attempted to abstract the integration behind a REST API and did so to a large degree of success. What was not as well considered as it should have been was the guidance on how the downstream integration should be using the platform. This resulted in a high volume of data being passed to the downstream system and unnecessary updates being send to the system consuming the data when methods intended to reduce traffic were not observed.  

• The other element we need to consider is the triggers to which downstream integration subscribe. Currently a single message is triggered from the API and a REST endpoint is exposed to allow the user to query whether that message is relevant to them. This could be made into a more topic-based approach where different triggers are fired from SITS but this is a trade-off between how generic we can make the API and the work required when a new topic is identified.  

Project Risks