Backfill Documentation
Please note that this page and related pages are being developed as part of the CIM Courses Project and are subject to change.
This article describes the backfill of data from the Container/Template Subject Structure to CIS (Curricular Information System) and MITSIS.
Purpose
CIM Courses project saves subject information in Container/Template subject structure and it is the new source of all subject data moving forward. Data from container/template subject structure needs to be backfilled to existing subject tables so that legacy applications can function without any code change.
- MITSIS backfill refers to backfilling of “old” MITSIS tables -_scrsu_var , scbsu_key, scrrtrm, screqiv, scrgmod and scrattr
- CIS backfill tables refers to backfilling of CIS tables - _scrci_proposal, scrci_cluster, scrci_term_plan , scrci_bulletin, scrci_url
In the following diagram, items marked in blue are covered in this document Backfill Details
Backfill to CIS and MITSIS tables are done either by a batch job or in real time via an API call. How a subject is backfilled is based on subject type (Administrative, Standard or Cross Registration), how the Subject was created – SCASUBJI, CIMFEED etc. and at what stage of proposal the subject is in (approved or proposed).
Administrative subjects are created from SCASUBJI directly in approved status.
- These subjects are backfilled only to MITSIS using Mule MITSIS batch process.
- Administrative Subjects are not backfilled to CIS.
Standard subjects are created via SCASUBJI (approved stage) or CIMFEED (proposed or approved stage).
- Approved Standard subjects are backfilled to MITSIS using Mule MITSIS batch process
- Approved Standard subjects are backfilled to CIS using Mule CIS batch process unless backfill_CIS = N. Changes from SCASUBJI do NOT backfill to CIS. More details under Backfill Processing Logic section at CIS Backfill documentation
- Proposed subjects are backfilled only to CIS using CIS batch process
Cross Registration can be created from SCASUBJI or mit-cross-registration API. They are always created directly in approved status. These subjects from
- mit-subjects endpoints call MITSIS Backfill On-Demand endpoint when processing Cross Registration subjects
- Cross Registration subjects are not backfilled to CIS.
In short, Cross Registration subjects from CrossReg Batch Service is saved to MITSIS using MITSIS Backfill On-Demand endpoint and all the rest backfills to MITSIS and CIS using corresponding batch processes. Also, Approved subjects are backfilled to MITSIS only while both Proposed and Approved subjects are backfilled to CIS tables.
Visual representation - Approved data flow diagram and Proposed data flow diagram
Backfill Migration
Almost all subject data is backfilled by batch processes which runs at frequent intervals. There are 2 batch processes to backfill tables, one each for MITSIS and CIS. These batch jobs are hosted and managed in Mule CloudHub. Mule CloudHub is a part of Anypoint Platform which is a product of MuleSoft. CloudHub ensures availability and security and also manages the security and configuration of the applications hosted on it. More details on Mule CloudHub can be found at https://docs.mulesoft.com/runtime-manager/cloudhub-architecture.
Batch jobs and API are developed using Anypoint Studio by MuleSoft. More info on this IDE at https://www.mulesoft.com/platform/studio
!
Queue
When a subject is created, modified or deleted, Subject Management API creates one or more entries into subject_backfill_queue (alias queue) table. These entries propagate the change to legacy CIS and "old" MITSIS tables via backfill batch processes. This subject_backfill_queue table can be considered as an intermediate staging table for backfilling data to CIS and/or MITSIS. There are 2 batch processes which look at the queue entries to backfill - MITSIS Backfill Batch Process and CIS Backfill Batch Process. These batch processes pick up data from subject_backfill_queue table based on specific status fields.
Queue table
- CIS batch process picks up data for CIS backfill based on cis_backfill_status column in queue table and MITSIS batch process looks for the criteria in mitsis_backfill_status column. More details under CIS Batch Process and MITSIS Backfill Process sections.
- subject_backfill_queue_id (alias queueId) is the primary key of subject_backfill_queue table.
- subject_container_id (alias containerId ) column contains the container_id of the subject created/modified/deleted. This column will be -1 when a new subject is created in proposed status. Ultimately by the time the subject is approved, it would have a valid containerId.
- new_term_code in queue table is the effective term for which the subject is changed. This column also determines when the subject would be backfilled dependent on the gates configuration in subject_mgmt_config (Subject Management Configuration )
- backfill_cis column specifies whether a subject needs to be backfilled to CIS. This value as all the other values is set by Subject Management API when the queue record is created. Please note that even if backfill_cis=Y, there are cases when CIS backfill will be ignored. This column just determines if CIS batch process needs to try to backfill the record at all.
- previous_data column stores subject information in pre-determined JSON format. This is the state of the subject before change event. Therefore previous_data will be null when a new subject is created in proposed or approved state.
- new_data column also stores subject information in JSON format. This value is the state of the subject after the change is made. new_data cannot be null.
- proposed_change_flag column (Y/N/null) indicates whether the subject created/modified is proposed or approved. Value Y for this column means the subject is in proposed state in the workflow and is processed only by CIS. Value = null / N means the subject is approved and both MITSIS and CIS processing will need to look at this record.
- backfill_process_type can be
- TP - term plan type (used for MITSIS and CIS Backfill) - indicates that only term plan specific data like terms offered, frequency, duration, next offered year or faculty has changed for the subject. None of the other fields would have changed and this type helps to make the backfill processing more efficient by ignoring and not comparing the other fields for MITSIS as well as CIS backfill processing. This type could be generated by Term Plan or SCASUBJI application.
- SR - scheduling relationship type (used only for MITSIS Backfill)- only used by MITSIS backfill processing to set cluster_type and master subject information in scrsu_var. CIS backfill ignores this queue record.
- RQ - requisite type (used only for CIS Backfill)- indicates that only pre-requisites and/or co-requisites for a subject has changed. This is only used by CIS backfill processing to set requisites in prereq_text column in scrci_proposal table. MITSIS does not store requisite information and hence ignores processing this record.
- DE - delete proposed type ((used only for CIS Backfill)- indicates that a proposed subject has been deleted. Since proposed subjects are only stored in CIS, CIS backfill process uses this record to remove a proposed subject and MITSIS backfill ignores this type.
- SD - same term delete (used only for MITSIS Backfill) when a subject is deactivated in the same term it was created.
- BD - back date (used for MITSIS and CIS Backfill) - when a subject is back dated after a new subject is created or re-activated (in approved status).
- null - regular (used for MITSIS and CIS Backfill) - a regular backfill record which is processed in detail by both MITSIS and CIS backfill processes.
- mitsis_tracking_internal and cis_tracking_internal has details of corresponding backfill processing. If mitsis_backfill_status = -1, then mitsis_tracking_internal will store the error encountered during MITSIS backfill processing. The same way if cis_backfill_status = -1, then cis_tracking internal will contain error details. More user friendly log entries will also be created in subject_backfill_log table during MITSIS and CIS processing linked by queueId.
- internal_analysis contains any special processing details during backfill processing. Special processing infers that the main (master) subject number (key) was renumbered, number swapped etc. This is calculated as one of the first steps in backfill processing logic and is used to route the logic flow.
- MR - master renumbered - main subject number was renumbered to another non-existent / inactivated number . Also the old number would not be a valid number anymore.
- MS - master swapped - main subject number was swapped with the subject number of the cross-listed child so that main (master) number becomes the number of the child and vice versa.
- PMS - partial master swap - main subject number is renumbered to a brand new non-existent / previously inactivated number and the old number is added as a cross-listed child subject.
- PCS - partial child swap (only relevant for CIS backfill) - when a subject with cross-listed child is edited such that child becomes the master and old number is deleted.
Example: MR (10.280) in internal_analysis column means subject 10.280 was renumbered. The value in braces is the old main subject number.
*updated Feb 2019. Please note that the table structures are not complete. create_by, create_date, modify_by, modify_date columns are not shown for brevity.
Queue Processing
- When a queue entry is created by Subject Management API, records are also created in subject_backfill_queue_usedkey (alias usedKey table) for all subjects related to the main subject in the queue. ie. if a subject A has cross-list C and if B is equivalent and D has a scheduling relationship to subject A, then when subject A is edited, the corresponding queueId would have minimum 4 records in usedKey table one for each of A, B, C and D with its relationship_type and container. These usedKey entries are used to make sure that if a subject is only partially backfilled because of an error in processing, then related subjects are also stalled and not backfilled till the error is fixed so that integrity of the whole subject is maintained at any time. To implement this functionality, another helper table subject_backfill_errorkey (alias errorKey table) is used to track the subjects and related subjects which needs to be stalled during processing.
- More details of logic of MITSIS and CIS can be found at CIS Backfill documentation and MITSIS Backfill documentation
- Queue records which are successfully backfilled by MITSIS and CIS are moved to subject_backfill_queue_archive table (alias archive table) for historical purposes.
CIS Batch Process
( More information about CIS processing logic at CIS Backfill documentation )
- Implemented as batch job named "backfill-init-cis-batch Poll" and typically runs every 7 minutes. Frequency can be configured from RuntimeManager of Mule CloudHub. Choose application mit-subjects-v1-(environment) => Schedules => set schedule/frequency for backfill-init-cis-batch Poll as desired.
- picks up subjects to be backfilled to CIS from subject_backfill_queue table where (cis_backfill_status is null or cis_backfill_status in ( 0, 2)) and backfill_cis = ‘Y’.
Defined values for cis_backfill_status are
null – to be processed;
-1 – error
1 – successfully processed
2 – retry processing
3 – excluded subject type (when subject_type is not Standard)
4 – CIS backfill not required (when backfill_cis is null or N) - processes queue records in ascending order of subject_backfill_queue_id
- backfills subjects which are created or edited between CIS gate ranges specified in subject_mgmt_config table (Subject Management Configuration ). ie. subjects created/modified between (and including) gate ranges as
(select config_value from subject_mgmt_config where config_code = 'cisBackfillAllowedFromYear') and (select config_value from subject_mgmt_config where config_code = 'cisBackfillAllowedUptoYear') - backfills Standard subjects only
- backfills Proposed as well as Approved Standard subjects
- backfills subjects created or edited from CimCourses only and not from SCASUBJI. API sets backfill_cis column is set to ‘Y’ for non SCASUBJI queue records and only these are backfilled to CIS.
- backfills data in container/template tables to CIS tables below used by Legacy systems
scrci_proposal
scrci_cluster
scrci_term_plan
scrci_bulletin
scrci_url - Any error encountered while processing is set in subject_backfill_queue.cis_tracking_internal. More user friendly log of processing is also entered in subject_backfill_log table linked with subject_backfill_queue_id. (....link to error details on CIS backfill page)
- Any error in processing is sent to email address configured under backfill.email.to property. As of Feb 10, 2019, emails will be sent to cim-courses-support-test@mit.edu in TEST and cim-courses-support@mit.edu in PROD environnments.
MITSIS Batch Process
( More information about MITSIS processing logic at MITSIS Backfill documentation )
- Implemented as batch job named backfill-init-mitsis-batch Poll and typically runs every 3 minutes. Frequency can be configured from RuntimeManager of Mule CloudHub.Choose application mit-subjects-v1-(environment) => Schedules => set schedule/frequency for backfill-init-mitsis-batch Poll as desired.
- picks up subjects to be backfilled to MITSIS from subject_backfill_queue table where (mitsis_backfill_status is null or mitsis_backfill_status in ( 0, 2)
Defined values for mitsis_backfill_status are
null – to be processed;
-1 – error
1 -- successfully processed
2 -- retry processing
3 -- ignore processing (when subject is in proposed state)
- backfills subjects which are created or edited before MITSIS gate year specified in subject_mgmt_config table (Subject Management Configuration ). ie. subjects created/modified before ( and including) gate range as
(select config_value from subject_mgmt_config where config_code = ‘mitsisBackfillAllowedUptoYear’) - backfills only subjects in approved state . Proposed subjects are not backfilled to MITSIS tables.
- backfills all subject types – Standard, Administrative and Cross Registration subjects
- backfills subjects created or edited from CimCourses or SCASUBJI.
- backfills data in container/template tables to CIS tables used by Legacy systems
scbsu_key
scrsu_var
scbsu_key
scrrtrm
screqiv
scrgmod
scrattr - Any error encountered while processing is set in subject_backfill_queue.mitsis_tracking_internal. More internal backfill details like the tables in which records are inserted or updated is also detailed in this column if processinng is successful. More user friendly log of processing is also entered in subject_backfill_log table linked with subject_backfill_queue_id. (....link to error details on MITSIS backfill page)
- Any error in processing is sent to email address configured under _backfill.email.to _property. As of Feb 10, 2019, emails will be sent to cim-courses-support-test@mit.edu in TEST and cim-courses-support@mit.edu in PROD environnments.
Testing Backfill endpoints
- used by Automated Tests to backfill CIS and MITSIS
- REST urls - \test\cisBackfill{queueIdToRun} backfills CIS tables and \test\mitsisBackfill{queueIdToRun} backfills MITSIS tables
- hosted in MIT Mule CloudHub
- this endpoint processes only one queue record at a time. It can take multiple calls to the url to backfill one subject change since more than one queue record could be generated for a single operation from CIMFEED or SCASUBJI
- expects parameter queueIdToRun - a valid value in backfill_subject_queue_id column in backfill_subject_queue.
- debugging – can be called from Postman or browser as a GET call to execute one queueId
- note that this endpoint ignores gate values in scrci_mgmt_config (cisBackfillAllowedFromYear, cisBackfillAllowedUptoYear and mitsisBackfillAllowedUptoYear) to determine if a subject falls within the gate range when backfilled to CIS. Since the API is used by automated tests and for debugging purposes mainly, it is designed to ignore the gate config values.
MITSIS Backfill On-Demand endpoint
- called by Subject Management API when a subject is created or modified.
- backfills MITSIS immediately and response is expected.
- will impact Cross Registration subjects only since the other subject types are ignored by this call
- is a mule flow
- synchronous request / response
- expects payload to have queueId, subjectType, termCode and apiRefId so that flow can determine if MITSIS backfill needs to be done at all without reading parameters from database table subject_backfill_queue
Table Counterparts - Old Structure to New Structure
This table is an overview of the conceptual mapping between tables of the "old" structure (CIS, MITSIS) and the "new" (Container/Template) structure. Mapping of the actual fields will be found on the CIS Backfill and MITSIS Backfill KB articles (#work - link and post mapping).
CIS Table | MITSIS Table | Container/Template Table | Notes |
---|---|---|---|
- | - | SUBJECT_CONTAINER | The container table is a new concept that did not exist in the old structure |
SCRCI_PROPOSAL SCRCI_SEMINAR SCRCI_CLUSTER |
SCRSU_VAR | SUBJECT_TEMPLATE | - Seminars are considered to be standard subjects in the new structure. They are flagged with the "FSEM" attribute. -Renumbering were handled in SCRCI_CLUSTER but are now handled in SUBJECT_TEMPLATE |
SCRCI_CLUSTER | SCRSU_VAR | SUBJECT_TMPL_REG_INSTANCE | Parent/child relationships are denoted by the "Master" fields in SCRSU_VAR |
SCRCI_PROPOSAL | SCRGMOD | SUBJECT_TMPL_GMOD | - |
SCRCI_CLUSTER | SCREQIV | SUBJECT_CONTAINER_EQUIV | - |
SCRCI_CLUSTER | SCRSU_VAR | SUBJECT_CONTAINER_RELATION |
- |
SCRCI_PROPOSAL | SCRATTR | SUBJECT_TMPL_ATTRIBUTE | Attributes in SCRATTR were derived from fields in SCRCI_PROPOSAL during the "Upload to MITSIS" process described here |
SCRCI_PROPOSAL | - | SUBJECT_TMPL_ENROLL_LIMIT | Enrollment limits were only stored as text in SCRCI_PROPOSAL.LIMIT_TEXT |
SCRCI_PROPOSAL | - | SUBJECT_TMPL_REQUISITE | Requisites were stored as text in SCRCI_PROPOSAL.PREREQ_TEXT |
- | - | SUBJECT_TMPL_DISPLAY_CTRL | New concept for Department Administrator to decide which information they want displaying the Online Subject Listing (OSL) |
SCRCI_URLS | - | SUBJECT_TMPL_URL | - |
SCRCI_SEMINAR | SCRSU_VAR | SUBJECT_TEMPLATE |
- |
SCRCI_SEMINAR | - | SUBJECT_TMPL_SEMINAR_FACULTY | - |
SCRCI_BULLETIN | - | - | SCRCI_BULLETIN will still be backfilled and used |
SCRCI_TERM_PLAN | SCRRTRM | SUBJECT_TEMPLATE | - |
Subject Attribute Handling
LAB/LAB2/LB Attribute Mapping
Due to the new Lab Institute Requirement, the "LAB" attributes are mapped as follows.
CIS (SCRCI_PROPOSAL) | MITSIS (SCRATTR) | CTSS (SUBJECT_TMPL_ATTRIBUTE) | CTSS (SUBJECT_TEMPLATE) |
---|---|---|---|
GIR_ATTR | ATTRIBUTE_CODE | ATTRIBUTE_CODE | UG_DEGREE_AUDIT_LAB_UNITS |
LAB2 | LB1 | - | 1 |
LAB2 | LB2 | - | 2 |
LAB2 | LB3 | - | 3 |
LAB2 | LB4 | - | 4 |
LAB2 | LB5 | - | 5 |
LAB2 | LAB2 | - | 6 |
LAB2 | LB7 | - | 7 |
LAB2 | LB8 | - | 8 |
LAB2 | LB9 | - | 9 |
LAB2 | LB10 | - | 10 |
LAB2 | LB11 | - | 11 |
LAB | LAB | - | 12 |
HASS Attribute Mapping
CIM Proposal | CIS (SCRCI_PROPOSAL) |
CIS (SCRCI_PROPOSAL) |
MITSIS (SCRATTR) |
CTSS (SUBJECT_TMPL_ATTRIBUTE) |
Notes |
---|---|---|---|---|---|
HASS Category |
WRITE_ATTR | GIR_ATTR | ATTRIBUTE_CODE | ATTRIBUTE_CODE | - |
HASS Arts |
HA | - |
HA, HE |
HA, HE |
- |
Half HASS Arts | HA2 | - | HA2 | HA2 | - |
HASS Humanities |
HH | - |
HH, HE |
HH, HE |
- |
Half HASS Humanities | HH2 | - | HH2 | HH2 | - |
HASS Elective |
HE |
- | HE |
HE |
- |
Half HASS Elective | HE2 | - | HE2 | HE2 | - |
HASS Social Sciences | HS | - | HS, HE | HS, HE | - |
Half HASS Social Sciences |
HS2 | - | HS2 | HS2 | - |
(HA, HH, or HS) + HE |
(HA, HH, or HS) |
- | (HA, HH, or HS), HE | (HA, HH, or HS), HE | Only two attributes in the (HA, HH, or HS) set should be present at any time. This restriction is not enforced in CIM courses, but is enforced by CIS. |
Other Attributes
This table shows the flow of relevant subject attributes.
Data Element |
CIM Courses |
CTSS |
CIS |
MITSIS |
|
---|---|---|---|---|---|
Variable Units | Arranged Units Radio Button = True | SUBJECT_TEMPLATE.VARIABLE_UNITS = "Y" SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRSI_PROPOSAL.UNITS_VAR = "Y" SCRSI_PROPOSAL.SUPR_ATTR is (null) |
SCRATTR.ATTRIBUTE_CODE = SUPR SCRATTR.ATTRIBUTE_CODE = VARU LAB_UNITS = 1 |
|
Independent Study | Supervisor Dropdown = Independent Study | SUBJECT_TMPL_ATTRIBUTE = INDP SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRCI_PROPOSAL.SUPR_ATTR = INDP | SCRATTR.ATTRIBUTE_CODE = INDP SCRATTR.ATTRIBUTE_CODE = SUPR |
|
Undergrad Thesis | Supervisor Dropdown = Thesis and Subject Level = Undergraduate |
SUBJECT_TMPL_ATTRIBUTE = THES SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRCI_PROPOSAL.SUPR_ATTR: THU | SCRATTR.ATTRIBUTE_CODE = THES SCRATTR.ATTRIBUTE_CODE = SUPR |
|
Graduate Thesis | Supervisor Dropdown = Thesis and Subject Level = Graduate |
SUBJECT_TMPL_ATTRIBUTE = THES SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRCI_PROPOSAL.SUPR_ATTR: THG | SCRATTR.ATTRIBUTE_CODE = THES SCRATTR.ATTRIBUTE_CODE = SUPR |
|
Paid UROP (URN) | Subject Number = "URN" and Tuition Dropdown = UROP | SUBJECT_TMPL_ATTRIBUTE = URN SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRCI_PROPOSAL.SUPR_ATTR: UROP AND SCRSI_PROPOSAL.SUBJ_NUM = "URN" |
SCRATTR.ATTRIBUTE_CODE = SUPR SCRATTR.ATTRIBUTE_CODE = UROP SCRATTR.ATTRIBUTE_CODE = URN |
|
UROP | Tuition Dropdown = UROP | SUBJECT_TMPL_ATTRIBUTE = UROP SUBJECT_TMPL_ATTRIBUTE = SUPR |
SCRCI_PROPOSAL.SUPR_ATTR = UROP | SCRATTR.ATTRIBUTE_CODE = UROP SCRATTR.ATTRIBUTE_CODE = SUPR |
|
Science Core (BIOL, CAL1, CAL2, CHEM, PHY1, PHY2) | Science Core, Institute, REST Dropdown in (BIOL, CAL1, CAL2, CHEM, PHY1, PHY2) | SUBJECT_TMPL_ATTRIBUTE in (BIOL, CAL1, CAL2, CHEM, PHY1, PHY2) |
SCRCI_PROPOSAL.GIR_ATTR in (BIOL, CAL1, CAL2, CHEM, PHY1, PHY2) | SCRATTR.ATTRIBUTE_CODE in (BIOL, CAL1, CAL2, CHEM, PHY1, PHY2) |
|
Communication Requirement (CIH, CIHW, CIM) | Communication Requirement Dropdown | SUBJECT_TMPL_ATTRIBUTE in (CIH, CIHW, CIM) |
SCRCI_PROPOSAL.COMM_ATTR in (CIH, CIHW, CIM) |
SCRATTR.ATTRIBUTE_CODE in (CIH, CIHW, CIM) | |
Tuition Attributes (COOP, COXA, PRAC, RESH) | Tuition Dropdown in (COOP, COXA, PRAC, RESH) | SUBJECT_TMPL_ATTRIBUTE in (COOP, COXA, NTRN, PRAC, RESH) |
SCRCI_PROPOSAL.TUITION_ATTR in (COOP, COXA, NTRN, PRAC, RESH) |
SCRATTR.ATTRIBUTE_CODE in (COOP, COXA, NTRN, PRAC, RESH) |
|
Internship (NTRN)* *Also a Tuition attribute but has different handling |
Tuition Dropdown = NTRN | SUBJECT_TMPL_ATTRIBUTE = NTRN SUBJECT_TMPL_ATTRIBUTE = COOP |
CRCI_PROPOSAL.TUITION_ATTR = NTRN |
SCRATTR.ATTRIBUTE_CODE = NTRN SCRATTR.ATTRIBUTE_CODE = COOP |
|
Freshmen Advising Seminar (FSEM) | Freshmen Advising Seminar Form | SUBJECT_TMPL_ATTRIBUTE = FSEM |
(FSEM related fields are stored in SCRCI_SEMINAR) |
SCRATTR.ATTRIBUTE_CODE = FSEM. (FSEM related fields are stored in standard MITSIS tables for subjects) | |
Rest Elective in Science and Technology (REST) | Science Core, Institute, REST Requirement Dropdown = REST | SUBJECT_TMPL_ATTRIBUTE = REST |
SCRCI_PROPOSAL.GIR_ATTR = REST |
SCRATTR.ATTRIBUTE_CODE = REST |
|
Half Rest Elective in Science and Technology (RST2) |
Science Core, Institute, REST Requirement Dropdown = RST2 |
SUBJECT_TMPL_ATTRIBUTE = RST2 |
SCRCI_PROPOSAL.GIR_ATTR = RST2 |
SCRATTR.ATTRIBUTE_CODE = RST2 |
|
ROTC | ROTC = Yes and "Not for Credit" is checked (Department must be in AS, MS, NS | SUBJECT_TMPL_ATTRIBUTE = ROTC |
SCRCI_PROPOSAL.SUBJ_CODE in (AS, MS, NS) | SCRATTR.ATTRIBUTE_CODE = ROTC |
|
Repeatable (RPT) | Grading Characteristics = Can Repeat for Credit | SUBJECT_TMPL_ATTRIBUTE = RPT |
GRADE_RULE = R | SCRSU_VAR.SUBJ_REPEAT_IND = Y | |
T-Graded Subject (TGRD) | Grading Characteristics = Can Use "T" | SUBJECT_TMPL_ATTRIBUTE = TGRD |
GRADE_RULE = T | SCRATTR.ATTRIBUTE_CODE = TGRD |
|
School Wide Elective (SWE) | Engineering School-Wide Elective Subject? Radio Buttons | SUBJECT_TMPL_ATTRIBUTE = SWE |
SCRCI_CLUSTER.CLUSTER_TYPE = S | SCRSU_VAR.CLUSTER_TYPE = S | |
First-year Discovery Subject (FYD) | n/a (added via SCASUBJI only) | SUBJECT_TMPL_ATTRIBUTE = FYD |
n/a |
SCRATTR.ATTRIBUTE_CODE = FYD |
Subject Management Documentation Index
The Subject Management Documentation Index is the central listing for documentation pertaining to Subject Management.