Overview

Below describes additional processing necessary when a student application is submitted in CCC Apply. This extends the existing design in Student Application.

When a student application is submitted, we will generate placement data.

Several applications are coordinated in order to deliver the placement data to the college and are outlined below.

Business Case

The California Community Colleges Chancellor's Office has mandated that a student's high school transcripts must be used to identify the most appropriate english and math courses for the student to be placed in.

This placement data must be shared with the student's college to facilitate student counselors helping students schedule appropriate courses.

API Gateway

This is mostly an additive modification not effecting existing integrations. However, previous work with MDM will need changes as outlined in Leveraging Previous work.

High Level Design

The API Gateway is integrating these systems:

• CCC Apply (Unicon)
  • student application submission
• Education Results Partners (ERP)
  • responsible for placement data
• California Colleges Guidance Initiative CCGI)
  • responsible for transcript data
• College SIS System (CCCTC College Adaptor)

At a high level, the process involves:

1. The submitted student application comes to Conductor from CCC Apply.

2. Process any self-reported transcript data present

   1. send self-reported transcript to ERP
   2. call ERP endpoint to GET placement data[]
      1. send placement data[] to college

3. Send CCGI a request for student transcript data

   1. CCGI will respond with a status and return immediately.
   2. Asnychronously, CCGI will call CCCTC, fulfilling the request and sending the "most significant" transcript for the student.

4. Process transcript data from CCGI (see above 3.2)

   1. send transcript to ERP
   2. call ERP endpoint to GET placement data[]
      1. send placement data[] to college

Workflows

Modify existing studentApplicationInboundWF

The existing design for handling submitted Student Applications will be modified with additive changes without effecting implementations there.

The Student Placement Workflow is passed the student-application.

see also JIRA tickets::

• CONDUCTOR-1

Student Placement Workflow

Input	Description
student-application	JSON application submitted in CCC Apply

This is the 'parent' workflow called when a student application has been submitted in CCC Apply.

The workflow is responsible for the following actions:

1. start workflow Process Self Reported high school transcripts Workflow. This will check for and handle self-reported data if appropriate.
2. start workflow Request student transcript from CCGI.
   1. The transcript is returned asynchronously and kicks off Process transcript data from CCGI.

Process Self Reported high school transcripts Workflow

Input	Description
student-application	JSON application submitted in CCC Apply

Students may self-report their high school grades and submit them with their student-application.

This workflow will process self-reported transcripts if ALL of the following are met:

1. self-reported data is contained in the submitted student application
2. an SSID is present with the application data. NOTE: only one of the SSID, the CCCID or the ISK are required by ERP when the self reported data is submitted.
3. the school being applied to is "supported" or part of the CCGI "network"

The workflow is responsible for the following tasks:

1. start workflow Request student transcript from CCGI

2. transform student-application to an ERP compatible format

3. make a POST call to ERP passing transcript data

   1. ERP replies with a 204 No Content status to acknowledge successful receipt

see also JIRA tickets:

• CONDUCTOR-2
• CONDUCTOR-4
• CONDUCTOR-5

Request student transcript from CCGI

Input	Description
student-application	JSON application submited in CCC Apply

This requests the "most significant" transcript from CCGI. They have an algorithm that will return official transcripts if available or fall back to self-reported if that's the best available.

1. If the 'ccgiToken' is populated in student-application, exit. CCGI is/will already send us this transcript.

2. call new endpoint to tell if school is supported by CCGI

3. transform inbound data for CCGI

4. make a POST call to CCGI passing mis code, SSID, and transcript data

   1. CCGI replies with a 201 Created status acknowledging the request has been created.
   2. CCGI makes an asynchronous call to the API Gateway and send the "most significant" transcript data for the student. This will be handled by Process transcript data from CCGI

see also JIRA tickets:

• CONDUCTOR-3

Process transcript data from CCGI

Input	Description
transcriptType	indicates highschool or college transcript
transcriptFormat	indicates XML or JSON
transcriptData	the PESC transcript as XML or JSON

The inbound student transcript triggers the following:

1. transform PESC to JSON format
2. GET call to ERP to get placement data for the student transcript
   1. transform placement data[] for college
   2. send resulting placement data[] to college passing mis, placement[]

see also JIRA tickets:

• CONDUCTOR-7
• CONDUCTOR-4
• CONDUCTOR-5

Leveraging Previous work

Previously, we had different conductor workflows to handle receiving student-applications from CCCApply. The different flows controlled which features were deployed into PROD and which flows were deployed only as far as PILOT (eg., for MDM processing).

With this effort, we'll simplify the workflows, versions and their forking based on the environment and consolidate them into a single flow for handling inbound student application submission.

Reference the previous designs for student application and MDM handling

• StudentApplication
• StudentApplicationMDMSPSIntegration

NOTE:, SPS integration is out of scope for the current effort. As a short-term change, we'll set messag retentionon on the SQS queue to be very short and simply not have MDM subscribed to the queue in PROD. This eliminates MDM processing any SPS integration.

see also JIRA tickets:

• CONDUCTOR-19

Service Router

Method	exposed UII	Description
POST	/transcript?transcriptType=HIGHSCHOOL_TRANSCRIPT&transcriptFormat={format}	Receive inbound PESC XML format

We'll continue using the previous exposed endpoint to accept student transcripts.

This endpoint will be secured using OAuth. ?? IS THIS TRUE ??

Service Workers

?? TODO: document this ?? :

Related links:

• ETRAN-242