Module Registration XML Data Import

User Guide

This version: 28 July 2011

Introduction

This document describes the XML module registration file upload facility in MRM. This is a means by which departments can upload module registrations into MRM and SITS from their own systems. Module registrations can be uploaded interactively as a file; alternatively departments can automate their systems to upload module registrations through a web service. Uploads take place in real time and are not batched.

Once data has been loaded, it can be amended interactively in the same way as modules registered through e:Vision, ie through the MRM screens.

A report of validation issues and success or failure for each student is displayed on screen and emailed to the user.

Red sections indicate new functionality added up to June 2011. Green sections indicate functionality added July/Aug 2011.

Who Can Upload

The import facility will only be available to staff in departments for which MRM is currently open for approval, and only approvers for a student’s route will able to import their data. Approval rights for a particular route or department can be arranged through the Exams Office.

How to Upload Interactively

You can upload using the test system to a test version of the SITS database by visiting the test version of the MRM system at:

Once there, click “Upload Module Registrations” on the left hand side, under “Upload Menu”. You can then browse for a file locally and click “Upload.

To load data to the production SITS database from the live MRM system, use the URL:

How to Upload by Web Service

To upload by web service, you need to ask ITS (fao Student Services) for a special username and password known as “gwUsername” and “gwPassword”. The “gw” stands for “Gateway”, the name of the authentication filter used.

Then you can for instance submit a multipart form, such as the following:

form method="post"

action="

enctype="multipart/form-data"

input type="hidden" name="gwUsername" value="xxx"/

input type="hidden" name="gwPassword" value="xxx"/

input type="file" name="file"/

input type="submit" value="Upload"/

</form

Your own values for gwUsername and gwPassword will need to be inserted. The example above is for the test service; to use the live service, remove “test-“ from the URL.

Logs

A log entry is created for students whose data on SITS is altered so that uploading can be audited. This is viewable through the student screen in MRM – click the “View Log” button on the right hand side. Information is recorded in as much detail as manually entered data.

XML File Format

Examples

An example of an XML file with the proposed format is below.

The smo_only attribute and rtsc_attendance_status field are optional and only expected to be used by WMG.

<?xml version="1.0" encoding="ISO-8859-1"?>
<students replace_mr_set="no"check_diet=”yes” year=”10/11”smo_only=”true”
<student sprcode="0104993/1" route_code="N140" block=”1”
<module code="EC130-24" record_type ="add" psl="Y"
assessment_group>B</assessment_group
occurrence>A</occurrence

module_type>core</module_type

rtsc_attendance_status>B</rstc_attendance_status

</module>
<module code="FR216-30" record_type ="delete" psl="9"
assessment_group>W</assessment_group
occurrence>A</occurrence

module_typelisted_option</module_type

</module>

<module code="FR316-24" record_type ="change"psl="9"
assessment_group>W</assessment_group
occurrence>A</occurrence

module_typeunlisted_option</module_type

</module>
</student>
</students>

And here’s an example of module deletion:

<?xml version="1.0" encoding="ISO-8859-1"?>

<students replace_mr_set="no"check_diet=”yes” year=”10/11”

<student sprcode="0803347/1" route_code="VM11" >

<module code="HI104-30" record_type ="delete" psl="Y">

</module>

</student>

</students>

Attributes on “students” Tag

Attributes on the “students” tag which apply to all the data in the file:

replace_mr_set can be set to yes or no. This specifies whether existing module registration records should be deleted prior to uploading the new set.
check_diet indicates whether module uploads should be restricted to those modules which match the diets set up in SITS. Valid values are:
yes- a module choicecan only be uploaded if it is a valid choice according to the student’s diet. This will determine whether it is a core, optional core or option. Where the module is not allowable according to the diet specification (which could be the case if there was no general or unusual option list set up for the course), it will not be added. Where the XML specification of core, option or unlisted option does not match the diet but the module is allowable, the module will be added and a warning given.
no - the diets will be ignored.
warnings_only- diets will be checked and warnings issued, but the data will be uploaded anyway.
yearindicates the academic year to which the module registrations relate, e.g. “10/11”. Module registrations can only be uploaded for the current year – a check is performed that the year specified and the SITS current year are the same.
smo_onlyindicates that data should be uploaded to the SMO table in SITS only, and not to the SMS, SSN or SDL tables. Where the record set is being replaced, data will still be deleted from all tables.

Attributes on “student” Tag

sprcode – the unique code for the student on their course, assigned by SITS on the SPR table.
routecode– the route the student is studying
block – the student’s year of study

The upload will check that SITS has a record of a student with that code studying the specified route on the specified block in the current year and will not upload otherwise.

A check is also made that the student does not have module registration choices generated for selection through the SITS e:Vision screens in the current year. This is so that a conflict does not occur between a student’s engagement with module registration screens and the auto-upload.

Attributes on “module” Tag

code is the module code. Only modules which are recorded as current on SITS can be uploaded. The following checks are done in SITS:
The module must exist in the MOD table
It must be a current module, ie it must exist on the MAB table and the field MAB_UDF1 must be set to “Y” where MAP_CODE = module code.
It must be available in the current year, indicated by the existence of a MAV record for the year
If the module already has a SMO record for this student in a previous year, there must *not* be a corresponding SMR record with SMR_PROC set to either SAS or RAS
record_typecan be add, change or delete. These indicate whether the module registration should be added or deleted from the existing set, or be treated as an update to an existing registration. This distinction only has an effect if “replace_mr_set” on the “students” tag is set to no.
If add, the module will be added to the existing module registrations;
If delete, the module will be deleted.
If change, the module will be changed if it already exists and otherwise added with a warning issued.

If “replace_mr_set” on the “students” tag is set to yes, all the previous records will have been deleted prior to upload anyway, so add or change will be treated in the same way and modules marked as delete will be ignored.

psl– stands for “Period Slot”. Valid values are Y and 9.

TagsWithin Module Tag

assessment_group– validated to check that the assessment is available for that module in the year (field MAB_AGRP in table MAB for the module)
occurrence– validated to check the occurrence is available for that module in the year (field MAV_OCCUR on table MAV for the module)
module_type can be any of core, listed_option or unlisted_option. The upload feedback will normally give a warning if this is inconsistent with SITS. The warnings can be suppressed by setting “check_diet” on the “students” tag to “no”.
rtsc_attendance_status– the value required to populate the RTSC field in SITS SMO, used for WMG routes only. The system throws an error if this is present but the student’s route is not a WMG route, and also if it is not present and the student’s route is WMG.

General Comments on Validation

If any data fails the above validation, a student’s module registration records will not be altered. (This is based on the general principle that the existingrecord set can only be removed if there is a complete valid set to replace them with.)

There will be no validation against course regulations (e.g. minimum numbers of modules chosen from specific lists).

Where Data Goes In SITS (SSN, SMS, SMO and SDL tables)

Where the “smo_only” flag is set to true, only the SMO table is populated as described below.

Data is imported into the following tables in SITS:

SSN (Student Schedule Number record)

Each student registering for modules has one SSN record for each year. It holds the student’s module registration status, e.g. “CON” for confirmed, the date the upload was made and a note field, which is populated with the word “AUTOUPLOADED” and the creation date.

If module registrations are imported with the “replace” flag set to “yes”, the SSN record is deleted and recreated. If “replace” is set to “no”, the date is updated.

SMS (Student Module Selections)

This is normally where students’ module choices are held prior to confirmation. It’s also where changes are made to modules interactively through MRM. (Once changes are made in MRM, it’s necessary to re-confirm the student so that changes are propagated to SMO.) In order that MRM can be used to interactively amend module registrations in the same way as modules entered through e:Vision, this table is populated for each module registration. It also means that uploaded module registrations will show up in MRM reports on module registration which interrogate SMS.

SMS records are created with the following fields:

SPR_CODE – e.g. 0751236/1
MOD_CODE – e.g. FI204-30
AYR_CODE – e.g. 10/11
PSL_CODE – as specified in the “psl” attribute on the “student” tag
SES_CODE – C for core, else O (deduced from whether core is true or false – no possibility for CO at present.)
SMS_AGRP – assessment group, e.g. A
SMS_OCCL – occurrence, e.g. D (occurrence code)
SMS_SCHC (e.g. UW PG. )
SMS_LEVC (as required by module recoding project)
SMS_MCRD - cats for the module
SMS_SURN (student surname with initials appended – from STU_SRTN)
SMS_CRED - creation date
SMS_CRET - creation time
SMS_NPER – set to 1 if SES_CODE is not C
SMS_STAT – set to C
SMS_PDTC – set to PDT code for module list, if it can be determined
SMS_PDMS – set to PDM sequence number for module list, if it can be determined

Other fields are set to null.

SMO (Confirmed Module Options)

SMO stands for “Student Module Option” in SITS, but in fact holds confirmed module selections which are used to schedule exams, generate statistics and provide government reports on which our funding levels are based. SMO records arecreated with the following fields:

SPR_CODE – e.g. 0751236/1
MOD_CODE – e.g. FI204-30
AYR_CODE – e.g. 10/11
PSL_CODE – as specified in the “psl” attribute on the “student” tag
SES_CODE – C for core, else O(deduced from whether core is true or false – no possibility for CO. Can make it more general if needed.)
SMO_AGRP – assessment group, e.g. A
MAV_OCCUR – occurrence, e.g. D(occurrence code)
SMO_SCHC – scheme code e.g. UW PG (Sql is e.g.: select SCH_CODE from INS_MOD where MOD_CODE = ‘FR917-30’)
SMO_LEVC – level code (as required by module recoding project)
SMO_MCRD - cats for the module
SMO_SURN - student surname with initials appended (taken from STU_SRTN)
SMO_PDTC – set to PDT code for module list, if it can be determined
SMO_PDMS – set to PDM sequence number for module list, if it can be determined
SMO_RTSC – set to value provided in the rtsc_attendance_status field

Other fields are set to null.

SDL (Student Diet Log)

When modules are registered through e:Vision, records are created in the SDL table. The same thing happens when modules are registered interactively through MRM. For consistency, the same is done when modules are uploaded. Every time a new module is registered and an SMS record created, an SDL record is also created with the field values below. Other fields are set to null.

SDL_SPRC – SPR code
SDL_GENS - 001
SDL_SEQN – next sequence number, generated on import
SDL_AYRC – current year
SDL_ACTN - ADD
SDL_RECT - SMS
SDL_PSLC – period slot code (Y or 9)
SDL_MODC – module code
SDL_MAVO - occurrence
SDL_PDTC – PDT code (null if module does not match diet)
SDL_PDMS – PDM sequence number (null if module does not match diet)
SDL_UNDO–T

Zoe James