Access Keys:
Skip to content (Access Key - 0)

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.

IS&T Contributions

Documentation and information provided by IS&T staff members


Last Modified:

July 15, 2019

Get Help

Request help
from the Help Desk
Report a security incident
to the Security Team
Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
Feedback
This product/service is:
Easy to use
Average
Difficult to use

This article is:
Helpful
Inaccurate
Obsolete
Adaptavist Theme Builder (4.2.3) Powered by Atlassian Confluence 3.5.13, the Enterprise Wiki