Design to Save Student Applications to Colleges
Overview
A student fills out an application using the CCCApply web portal.
Previously, colleges would download some of that student 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 in CCCApply.
This design is extended in Student Placement
Business Case
- The "download client" and process of downloading student application data to each college is problematic and will eventually be replaced. Separate from that replacement we want to store, in near real time, the student's application into the college's SIS. This should include all the student application data.
API Gateway
The API Gateway's design for the Service Router, Service Conductor, and Service Workers for saving the student application to the college are detailed below.
Service Router
There will be no REST endpoint or anything exposed publicly. The service is initiated using the below event handler.
Service Conductor
The Service Conductor design components are defined below.
Event Handlers
All event handlers are asynchronous. Events 'fire-and-forget' in the main thread so they have little to no impact on the main flow. In a separate thread, handlers listen for specific events and act on them accordingly.
Student Application Event Handler
This handler listens to an SQS queue. Events are received by this handler that pass the condition below:
TBD
By satisfying this condition, a start_workflow action is performed naming the Save Student Application Workflow to be started.
Workflow Definitions
There is one workflow involved in this service.
- Save Student Application
There are two workflow tasks:
- Get Application Data Task
- Save Application Task
Save Student Application Workflow
This workflow is started by the above Student Application Event Handler.
Since the input is only the unique ID of the student application, this workflow is responsible for making a REST call to get the entire student application data and then sending that data to the college-adaptor where it'll be saved into the SIS.
Workflow Input:
| Parameter | Description |
|---|---|
| studentApplicationId | Unique ID of student application submitted. |
Get Application Data Task
The workflow inbound message only contains the unique id of the application, so this task uses that ID to:
- Do an HTTP GET call to pass $input.studentApplicationId to retrieve the full application data.
- Set the JSON results in context output
Properties:
- CCCApply REST endpoint to retrieve student application from
- TBD security credentials for interacting with CCCApply
Save Application Task
Given the student application in the workflow context, this task is processed by the college-adaptor worker and saves it into the SIS.
- Create a RESTful call for college-adaptor that includes the student application
Properties:
- workflow name of college-adaptor to foward processing to
Service Workers
For deployment, all service workers will be deployed to the shared-services env + private subnet. This model allows using the centralized service-worker from the api-gateway stack.
Response
Since the flow is initiated from a queue asynchronously, there is no caller to send a response upon completion.
Normal status checking and error handling in Conductor apply.