XML

The Pathway Interface (PWI) is a 2-way file-based data exchange delivering student / course data between IUP and its partner universities using an industry standard XML file format.  The exchange of files is handled via a secure SFTP (Secure File Transfer Program) server managed and monitored by IUP, which forms the core element of the transport layer.

Each PWI partner is allocated a SFTP site comprising 2 folders:

• OutTray (files sent from IUP)
• InTray (files sent from partner)

The tray structure constitutes the data handover point for the PWI model.

The interface is a seamless background process and enables INTO’s systems and the university’s student record system to synchronise with key biographical, HESA, course and compliance related information (Passport, Visa and CAS data).

The interface also provides the transport layer for the return of the university student number and term-time email address, both of which are distributed to students on arrival with IUP and provide access to key resources on campus such as Wi-Fi, library, gym and other services.

The process is initiated by INTO and is triggered 28* days before the course start date. 

A rolling/overnight process checks student records against a set of pre-requisite conditions; and if met, the application is marked, and data extracted to XML interface files (filename auto-generated) and sent to the OutTray.

Note: The university can request either one record or multiple records per interface file.

It is the university’s responsibility to poll the OutTray and process files found there at their earliest opportunity.

Once the file has been processed and the data ingested, INTO expects the university to return the university student number and term-time email address for each student sent.  See the return feed section following.

After the initial send; and on every occurrence of the data being changed by IUP, the data is re-extracted and sent – this service continues for up 90 days after course completion.

Access to the SFTP service is 24/7/365

Outbound files are produced between 05:00 and 20:00, 7/365

File production frequency is partner selectable and typically either, hourly or daily (if there is data to send)

*As stated, the initial trigger is set for 28 days in advance of course start date, however this is flexible and can be adjusted to meet partner requirements particularly during the run-up to major cohorts.

By arrangement, a test environment, including access to a secure SFTP server can be configured and test data provided to support on-boarding new partners. IUP will also provide comprehensive technical support to ensure partner are able to develop the PWI interface solution in the shortest possible time.

The PWI is based on a mature XSD, developed in conjunction with several existing partners and this defines the structure of XML files produced by the service.  A copy of the PWI XSD is available on request. 

Contained within the XSD are definitions covering the following:

• Field names
• Data types e.g.  string, date/time
• Use: Required/Optional
• Field lengths
• Validation information where appropriate

Further information can be sourced from the ‘Institution Briefing Document’ which provides a comprehensive overview of the PWI payload.

The exchange of primary keys is optionally service offered and provides a flexible one-to-one mapping between the INTO Course Applied For (CAF) record and that of the of the partners record system.  The primary key is based on the student/course join relationship. Below is an example of the IUP primary key followed by that of the university.

The SFTP server is the basis of the PWI and is managed by INTO, providing partners with a secure and GDPR compliant environment for the transfer of student/course data.

Each site consists of an OutTray for files sent from IUP to the partner; and an InTray for the data sent by the partner to IUP; see Diagram 1.

An archive facility is located on the SFTP site and provides a historical reference of PWI files transferred/processed.

Security for the SFTP site is password controlled and managed by the INTO SFTP-Gatekeeper, who is responsible for access control, service monitoring and data security.

A range of alerts and reports provide timely error notification when exceptions to normal service occur; reports include (but not limited to):

• Server performance alerts
• Data verification errors
• Files not processed by the partner – (file remaining in OutTray after 24 hours)
• Audit reporting provides a reference of data sent and received; through this mechanism records can be marked for re-sending to the partner

PWI partners can access support directly by contacting the IUP Integrations team.

The PWI uses education industry standard coding where permissible to support the transfer and synchronisation of key data elements between IUP and the universities. 

As an example, references to country are supplied in Alpha-2 code format; fields supplied this way include:

• Country of Domicile
• Country of Birth
• Nationality

For Aplha-2 coding please see: https://www.iso.org/obp/ui/#search/code/

Further details around this can be found in the ‘IDX UK Reference Guide’ here

To assist university partners with the design and development of a PWI solution, technical documentation is available and includes details of the PWI data-set and mirrors the content of the XSD (XML schema document)

Also, sample PWI payloads are available that demonstrate and help visualise typical operational content seen via the PWI.

Please note there is also an API version of the PWI which is covered separately on this site.

Data transmission integrations is a key concept to implement with INTO Partners, currently this integration occurs between INTO’s CRM system and the University’s core system(s) which allow for tracking and management of student data throughout multiple points of the student lifecycle process (applicant lead through graduation & alumni). 

Data will be transferred in the form of an XML data document that will contain one application or multiples applications in a XML document, XML files are defined using an XSD, a schema definition file that will only allow data to be passed if the file matches the criteria for the matching schema definition.

INTO North America integrations are broken down into the following classification

• Student Application and Receipt File Integration
• Document Integration
• Cascades Integration
• Direct Entry Waiver.
• URSA Major and URSA Minor

It is the delivery of student application data from INTO’s systems to the University’s student information system, and the generation of a “receipt” file, which will be used to confirm that student application data has been successfully created in the University’s student information system.

Data will be transferred in both ways in the form of an XML data document, XML files are defined using an XSD, a schema definition file that will only allow data to be passed if the file matches the criteria for the matching schema definition. This helps ensure that both the university’s and INTO systems only receive or pass data that is allowed by the rules defined in the schema document.

The XML documents will be transferred via SFTP in various folder locations depending on contents of the XML file and its desired final location.

A “receipt” file, containing critical student information required by INTO, will be transferred in XML form from the university system to INTO SFTP server after the university has received the initial student application into their system. This process will need to be developed and maintained by the University.

Data-Exchange-Interval-and-Trigger-Points

Documents related to student applications will be downloaded from INTO’s systems and transferred via SFTP to the University’s document management system.

Data-Exchange-Interval-and-Trigger-Points

The “Cascades” integration will pass student applications that have been “cascaded” down from the University’s admissions team if they determine that the student has not met the English criteria required to apply directly to the university.

Cascade application data will be extracted from the University’s student information system in the form of an XML file and transferred via SFTP. INTO will pick up the applications from the SFTP location and load the applications into INTO systems.

Data-Exchange-Interval-and-Trigger-Points

The purpose of DEW is to allow the agents, agencies or sponsor (s) to make inquiries on behalf of the student during or after the application process. The INTO job will send applicant’s information of those individuals who complete the Direct Entry Waiver Form to University. It will create some information from the applicant in INTO’s systems. INTO will send information via email to the University who will flag the applicant as an INTO recruited student. The “DEW receipt” file, containing student information required by INTO, will be sent in XML format from the University’s student information system to the INTO specific system through the SFTP after they have received and successfully loaded the student application file into their system. This process will need to be developed by the University.

Once INTO receives the information the records are updated accordingly and marked as complete.

The University Reporting Student Achievements, URSA (Major and Minor) integrations will extract student enrollment and performance metrics from the University’s student information system in the form of an XML file on a termly basis. INTO uses this data to determine how students are performing after leaving our programs and ensures that we are recruiting quality talent to the university. This also helps with financial reconciliation between the university and INTO.

These integrations are very similar, but have two distinct student populations:

URSA Major: Includes all international students enrolled for the term that just ended, that are either previous INTO matriculated students, or were sourced through an INTO Direct Entry recruitment activity.

URSA Minor: Includes all international students enrolled for the current term, pulled after add/drop period has ended. The population is the same as URSA Major, either previous INTO matriculated students or sourced through an INTO recruitment Direct Entry activity.

Data-Exchange-Interval-and-Trigger-Points

There is a dedicated folder per partner and type of integration to run tests and make developments. The schedule of the jobs exporting the files in testing could be different from production. Credentials and folder location will be provided upon request.

INTO NA integrations are based on a set of matures XSD files, developed in conjunction with existing partners and this defines the structure of XML files produced by each integration. 

A copy of the current XSD version is available on request, with additional documentation.

Contained within the XSD are definitions covering the following:

• Field names
• Data types e.g.  string, date/time
• Use: Required/Optional
• Field lengths
• Available values
• Validation information where appropriate

The exchange of primary keys is required for the application/receipt file integration.

• Primary keys for the 3 core objects in the INTO student account/student application/ student courses are the foundation of this integration.

For other integrations the University ID is key to match the information between university systems and INTO systems.

The SFTP server is a core component of the integration, it is managed by INTO providing partners with a secure environment for the transfer of student/course data. Each site consists of an Output folder for files sent from INTO to the partner; and an Input for the data sent by the partner to Into. Following processing of files, it is the responsibility of the partner to move such files to the archive folder on the SFTP server, to be retained as a historical reference. 

Security for the SFTP site is password controlled and managed by INTO, who is responsible for access control, service monitoring and data security.

A range of reports provide error notification for issues relating to the normal performance of the platform, reports include (but not limited to):

• Files not processed by the partner
• Applications which had been delayed being processed by the partner
• Applications with Data entry errors

The integration uses standard coding where permissible to support the transfer and synchronization of key data elements between INTO and the universities. 

References to country are supplied in Alpha 3-code ISO Country format; fields supplied this way include:

• Country of Residence
• Country of Birth
• Nationality

For more information about the ISO Code: https://www.iso.org/obp/ui/#search/code/