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:
https://test-mrm.warwick.ac.uk
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:
https://mrm.warwick.ac.uk
1
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="https://test-mrm.warwick.ac.uk/mrm/webServiceUpload/xmlResponse.xml"
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.
2
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_type>listed_option</module_type>
</module>
<module code="FR316-24" record_type ="change" psl="9">
<assessment_group>W</assessment_group>
<occurrence>A</occurrence>
<module_type>unlisted_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>
3
Attributes on “students” Tag
Attributes on the “students” tag which apply to all the data in the file:
1. 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.
2. check_diet indicates whether module uploads should be restricted to those modules which
match the diets set up in SITS. Valid values are:
a. yes - a module choice can 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.
b. no - the diets will be ignored.
c. warnings_only - diets will be checked and warnings issued, but the data will be
uploaded anyway.
3. year indicates 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.
4. smo_only indicates 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
1. sprcode – the unique code for the student on their course, assigned by SITS on the SPR table.
2. routecode – the route the student is studying
3. 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.
4
Attributes on “module” Tag
1. code is the module code. Only modules which are recorded as current on SITS can be
uploaded. The following checks are done in SITS:
a. The module must exist in the MOD table
b. 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.
c. It must be available in the current year, indicated by the existence of a MAV record
for the year
d. 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
2. record_type can 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.
a. If add, the module will be added to the existing module registrations;
b. If delete, the module will be deleted.
c. 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.
3. psl – stands for “Period Slot”. Valid values are Y and 9.
Tags Within Module Tag
1. 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)
2. occurrence – validated to check the occurrence is available for that module in the year (field
MAV_OCCUR on table MAV for the module)
3. 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”.
4. 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.
5
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 existing record 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.
6
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 reconfirm 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.
7
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 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. 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.
8
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
9