Blog: Improve student experience with system integration

With the start of the pandemic, digital learning has become a new norm for most students. The digital approach demonstrated so many benefits that it remained in various forms even after the lockdown. There is a rise in hybrid learning when classes consist of in-person and online students. Not to forget about a blended study that includes online and on-campus courses.
Digital has become an integral part of higher education. So how can universities use technology to provide the best online experience for students and staff and boost operational efficiency while reducing costs?

In this blog, I'll tell the story of our customer, one of the top research universities in the UK, and how it utilised API-led integration to automate data synchronisation between its two legacy platforms.

Search for an integration platform

To hold information about students, the university relies on two key platforms - SITS and SPOT:

• Student record system (SITS) - the primary student records system.
• Identity Management System (SPOT) - the authoritative source for IT accounts responsible for maintaining each person's unique identity within the university. 

It is critical for the university to keep the stored information synchronised and up-to-date. The IT team developed and maintained a custom connector to ensure data exchange between the two systems.

Although point-to-point connectors resolved some problems, they created many more. Direct integrations are very brittle, impossible to reuse, and hard to enforce security and governance. On top of that, maintaining custom code requires time and effort.

As a part of its long-term digital strategy, the university sought a scalable solution to create an interconnected ecosystem of systems and devices. Hard-to-maintain, inflexible and non-reusable custom connectors were not fit for that future. The university needed a powerful market-leading integration platform like MuleSoft.

A pilot project to demonstrate MuleSoft's capabilities and benefits

The university was keen to test the power of API-led integration and, in time, use it to replace all custom connectors with a scalable, secure application network. There are numerous benefits of using a unified platform like MuleSoft - a safe and efficient mechanism for data exchange and a single tool for proactive monitoring and error handling. Having all tools under one umbrella increased productivity by 25% leading to significant cost-cutting.

We started with a small project to give the university's IT team a taste of the new platform and its capabilities. The proof of concept demonstrated how to use API-led connectivity to automate bidirectional data flow between SITS and SPOT. The most natural approach was to design and build APIs from existing legacy interfaces – database views and stored procedures. 

Let's look closely at the main use case: 

1. Export all student record changes from the Student Record System (SITS) and import them to the Identity Management System (SPOT).
2. Export details of IT accounts from SPOT; update records in SITS based on a positive or negative response.

SPOT to SITS information synchronisation

When a new student joins the university, his identity is created in SPOT. The information is then passed to SITS to enable the students to sign in using their IT accounts. Also, every time the IT account is changed, the SITS must be updated to reflect the changes. Based on the SITS's response, SPOT is updated. 

We started by building two System APIs - SPOT and SITS - to communicate with the two underlying systems. System APIs abstract communication with data sources and fetch their content. The next step was to build two Process APIs - Student Process API and Identity Management Process API. Process APIs 'shape up' data extracted from multiple systems. Retrieved information is aggregated, and business logic is applied when necessary.

A scheduler calls Process APIs to start the data flow. We use MuleSoft's Anypoint MQ (cloud messaging service) to publish messages on a 'topic'. It is a very efficient and scalable approach because any API can listen to the broadcasted notifications and update its underlying system as required. 

Now, let's explore the data flow from SITS to SPOT:

• A scheduler calls the Student Process API, which calls SITS System API.
• SITS System API executes SITS DB View to retrieve changes in student records and returns the information to the Student Process API.
• Student Process API places a new message into the queue. The Identity Management Process API fetches this notification and decides whether to create, update or delete a student record.
• For each record, the Identity Management Process API calls SPOT System API.
• The SPOTS System API calls the SPOT stored procedure and returns the result (success or failure) to the Student Process API.
• The Identity Management Process API calls SITS System API to update on transaction status. On failure, Identity Management Process AP also sends out an email notification about the transaction failure.
• Lastly, SITS System API calls SITS stored procedure of the transaction status, either success or failure.

A similar process is triggered for all changes in SPOT to ensure two-way data synchronisation. Let's look at the second data flow from SPOT to SITS:

• A scheduler executes the Identity Management Process API to call the SPOT System API.
• Then, the SPOT System API runs the SPOT DB view to retrieve all changes in SPOT. The list of changes is returned to the Student Process API. 
• The Identity Management Process API puts a message into the queue.
• The Student Process API pulls the message and executes logic to determine whether records succeeded or failed.
• The Student Process API calls SITS System API, passing a single record change for every record in the list.
• The SITS System API calls the stored procedure and returns the result to the Student Process API.
• Student Process API calls SPOT System API to update on transaction status. On failure, Student Process API also sends out an email notification.
• Lastly, SPOT System API calls SPOT stored procedure of the transaction status, either success or failure.

Future Considerations

We suggest the future design rely even more on the event-driven model, as shown in the diagram below. Systems interested in any changes in student records could subscribe for updates. Process APIs would be a 'conductor' that orchestrates the messages as needed. The next step would be to develop Experience APIs to format student data for further consumption by user-facing devices.

We always follow the principles of reusability and scaling; therefore, the APIs created for this pilot can be used for various use cases in the future:

•  retrieve student records by unique identifier or email;
•  fetch all student records;
•  get student course details;
•  cascading updates to other systems interested in this information.

The pilot project was a success and a great demonstration of what the university could achieve by using MuleSoft's integration platform. It took our team only a few weeks to replace the custom point-to-point connector with scalable, flexible and secure API-based integrations. Considering that all APIs are designed and developed with reuse in mind, the API-led connectivity approach creates plenty of opportunities for future integrations and enhancing student experience!