Design to Save California College Promise Grant Applications to Colleges
Overview
A student fills out a California College Promise grant application using the CCCApply web portal (henceforth referred to as CCPG for brevity).
Previously, colleges would download some of that application data and process some of it into their database (SIS). The below design sends all the application data to the college's SIS at the time the student submits it.
Business Case
- The "download client" and process of downloading CCPG data to each college is problematic and will eventually be replaced. Separate from that replacement we want to store, in near real time, the CCPG application into the college's SIS. This should include all the application data.
API Gateway
A workflow and design already existing for retrieving student application data (the regular application for admission to a college) from CCC Apply. This workflow will be augmented to enable processing of multiple application types: the existing application for admission (APPLY), the California College Promise Grant (CCPG) and in the future the International Application (IA).
Here is the existing design document: Student Application
Note that the decision was made to utilize the exiting SQS queue for CCPG applications, so all applications will come in on the same queue. This means no new event handlers or SQS queues will need to be created.
Details of this modification are below:
Event Handler Changes
The existing event handler studentApplicationInbound will be modified to call a new workflow which determines how to route the application based on its type. See below for details of this new Workflow.
Note that because the CCPG application will come in on the same SQS queue as is already used for regular applications, this is the only modification that needs to occur to the event handler.
Workflow Additions / Modifications
New Workflow: studentApplicationInboundRouterWF (or similar name)
A new workflow will be developed that uses a DECISION to determine how to process the incoming application. This DECISION will be based on a value from the SQS message that indicates the type of application. Based on the type of application it will derive the necessary details to process the application and send them to the existing, but modified workflow studentApplicationInboundWF (see below for details on modification to that workflow).
Workflow Input:
| Parameter | Description |
|---|---|
| message | SQS message (includes application ID, application type, application status) |
Workflow Outputs to studentApplicationInboundWF:
| Parameter | Description |
|---|---|
| application source | URI of the endpoint of the CCC Apply REST API to call to retrieve the application data |
| college adaptor destination | URI of the endpoint on the college adaptor REST API where the data should be POSTed |
Workflow modification: studentApplicationInboundWF
Two modifications are required:
- Replace existing input parameter with new parameters that specify source and destination of application data
- Utilize new input parameters when making calls to retrieve data from CCC Apply and send data to an SIS
Workflow Input:
| Parameter | Description |
|---|---|
| application source | URI of the endpoint of the CCC Apply REST API to call to retrieve the application data |
| college adaptor destination | URI of the endpoint on the college adaptor REST API where the data should be POSTed |
MDM Considerations
Presently there are two versions of studentApplicationInboundWF - one that supports MDM and one that does not. This leads to some complication retrofitting the existing workflow and will likely need to be addressed when the MDM version moves past QA. That is beyond the scope of this design, however.