XML

UK

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.

Student Integration Architecture

 

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.

How it works

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.

Data Exchange Interval & Trigger Points

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.

Test Environments

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.

Data Protocols - Outbound

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.

Primary Keys Exchange (Optional)

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.

Ns0:intoScjCode=”0051539695/1”

Ns0:insSceScjc=”690047993/1”

SFTP

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.

Authentication

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.

Error Notifications

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

Support

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

Reference & Lookup Data

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

Supporting Information

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.

Pathway API (Application Program Interface)

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

US

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.

Student Integration Architecture

How it works

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

Student Application and Receipt File Integration

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

  • Access to the SFTP service is 24/7/365
  • Outbound files are produced between 03:00 and 22:00 EST time, 7/365
  • File production frequency is partner selectable but typically 4 times per day.
  • The generation of the files depends on the trigger point selected by the business.

Application Push Trigger Point:

  • Push first program of student’s study plan upon student confirmation (acceptance of offer letter).
  • Push updates to course responses (cancellations, deferrals, course changes).
  • Push new confirmed program resulting from a course change or deferral.

Application Receipt File Trigger points:

  • Create receipt file record for student upon successful load of the application into university student information system.
  • Create receipt file record for any subsequent programs loaded resulting from a course change or deferral.
  • If applicable, create another receipt file record once a student has created their university email address. NOTE: This only applies if the student does not get their email automatically generated once a confirmed application is created in the university student information system.

Document Integration

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 generation of this files will happen after the student’s application has been successfully loaded and verified through the receipt file process. This will ensure that documents are only pushed if the student currently exists in the university’s student information system.
    • Access to the SFTP service is 24/7/365
    • Outbound files are produced between 03:00 and 22:00 EST time, 7/365
    • File production frequency is partner selectable but typically 4 times per day.

Files are typically generated with a file naming convention that will help to index documents into the correct student folder.

Cascades Integration

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

  • Generally, new admit codes are used to distinguish when a student needs to be cascaded back to INTO, this trigger point can be decided upon during the planning phase of this integration.
  • Access to the SFTP service is 24/7/365
  • Files are produced by the university according their own capacity, at least once per day.
  • INTO Job to pick up files runs every four hours per day.

Direct Entry Waiver (DEW)

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.

URSA Major, URSA Minor

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

  • Access to the SFTP service is 24/7/365
  • Ursa Major
    • End of term enrolment and performance report. Dates will be agreed with partners
  • Ursa Minor
    • Beginning of term enrolment and performance report. Dates will be agreed with partners

Test Environments

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.

Data Protocols - Outbound/Inbound

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

Primary Keys & Exchange

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.

SFTP

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. 

Authentication

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

Error Notifications

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

Reference & Lookup Data

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/

keyboard_arrow_up