Versions Compared

Old Version 3

changes.mady.by.user Anthony Arland (Deactivated)

Saved on

compared with

New Version 4

changes.mady.by.user Anthony Arland (Deactivated)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Table of Contents

Overview

Phase 1 Map Status Calculation will feature a cron job that calculate plan statuses for all active plans as detailed in the Phase 1 requirements doc (/wiki/spaces/SSP/pages/103986907).  

 

MAP Plan Status Calculation Implementation Details

Map Plan Status Calculation Flow Chart

Gliffy
size500
nameflow chart

Map Plan Status Schema

Gliffy
namemap_plan_status_phase1

 

Map Status Data Dictionary

MAP_STATUS_REPORT (Process will produce one row per active plan assigned to an active student.)

...

Info
titleComments
  • course_code: This may or may not be applicable here.  We are seeing more and more schools loading data into external_course with the same formatted_course but different course_id values.  This represents different versions of the course and is completely legitimate in the field.  Many schools start with this concept because the SIS table structures require different course ids for each term the course is offered.  However, different course ids in MAP are important when the course has a different definition (title, course hours, etc).  

 

 

Excerpt

New Configurations

namepossible valuespurpose
calculate_map_plan_statustrue, falseturns on/off cron job that will drive the calculation
map_plan_status_passing_gradesschool specific but something like (A,B,C)In cases where a plan course and taken course line up, the student must have passed the class in order to not cause a anomaly
map_plan_status_cutoff_term_codeterm_code (EXTERNAL_TERM.CODE)

The calculation cutoff term is the latest future term to be included in the matching logic.  The term range for a given calculation will start with the oldest term for the student transcripted courses up to the cutoff term.  The term must be a valid term from external_term.  

  • If no term is configured, current term is used
  • If the configured term is a past term (user forgot to update),current term is used
task_scheduler_map_plan_status_calculation_triggercron expression (i.e., 0 0 1 * * *)drives the frequency of the cron job that will calculate status
map_plan_status_addition_course_matching_criteriaavailable options are (COURSE_TITLE,CREDIT_HOURS) or blankIn addition to the static matching criteria (term_code and formatted_course), implementors have the option to add additional criteria. COURSE_TITLE will match PLAN_COURSE.COURSE_TITLE to EXTERNAL_STUDENT_TRANSCRIPT_COURSE.TITLE and CREDIT_HOURS will match PLAN_COURSE.CREDIT_HOURS with EXTERNAL_STUDENT_TRANSCRIPT_COURSE.CREDIT_EARNED

...

Info
titleComments

 passing_grades: Dan also questioned the need for more complexity.  Maybe I'm missing something that you both are seeing.  The basic functionality is to check to see if the grade the student was awarded on their transcript is a passing grade. 

Matching criteria

Different schools may have their course/transcript data organized differently.  This means they may want different criteria to drive the matching logic between plan and transcript.  We will assume that three criteria are non-negotiable and static; term_code and  formatted_course.  In addition to the static matching criteria, implementors have the option to add additional criteria. COURSE_TITLE will match PLAN_COURSE.COURSE_TITLE to EXTERNAL_STUDENT_TRANSCRIPT_COURSE.TITLE and CREDIT_HOURS will match PLAN_COURSE.CREDIT_HOURS with EXTERNAL_STUDENT_TRANSCRIPT_COURSE.CREDIT_EARNED.  

Implementation Concerns

  • System load and memory footprint will be big concerns for the calculation process.  We don't want to load all active plans into memory at once.  Implementors may not want to have cron job run during business hours as it could put load on the web server and database.
  • Configuration map_plan_status_cutoff_term_code is a maintenance concern.  Will most likely have to be updated every term.  This must be clear to implementors.
  • map_plan_status_passing_grades may not be very flexible enough for a lot of schools.  We may want to explore a hierarchical configuration approach.

Open Questions

  • Do we want to store one status per plan?  If we want to store multiple statuses per plan, that may have performance and storage concerns.
    • JME: During the original discussion we agreed for phase 1 that we would record only the current plan status and off plan reason.  The one per is actually buried in the /wiki/spaces/SSP/pages/103986907 in the Operational Table description.

...