Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 5
Next »
This page is not intended to cover every use case, but to list some of the needs from various squads.
Squad / Contacts | Use Case | Status and Notes |
---|
Aperture (Kelly Buchanan TJ Tracy (Deactivated)) | Syncing catalog data from Discovery to Credentials | Currently handled with scheduled bulk updates. Has high latency and is prone to errors. |
Aperture (Kelly Buchanan TJ Tracy (Deactivated)) | Syncing course certificate and grade data from LMS to Credentials | Currently handled with async call from LMS directly to Credentials. Prone to errors, business logic breaks domain boundaries, no event reuse. See below for implementation notes. |
Purchase (Ben Holt (Deactivated)) | Ecommerce replacement, cross service calls. For example, data sent from LMS to new Ecom. | Need to plan for async direct calls until Event Bus capabilities exist. Events can’t easily be reused by multiple services without being routed by the ecom replacement service. |
Enterprise: Access: Titans? (Brian Beggs) | Subscription plan creation, subscription plan expiration, license expiration, license renewals, learner enrollment changes | We need to create and remove things frequently that touch a number of systems (LMS, license manager, catalog manager) that are currently doing synchronously. This can cause timeouts, failures and is prone to errors due to transient errors on the systems being called. Nothing started yet. Would need something where events/messages could be fired and consumed by a number of systems. |
Content: Cosmonauts (Zach Hancock (Deactivated) Simon Chen Andy Shultz (Deactivated) ) | Moving proctoring out of platform and into an IDA. Calls to the LMS to update grades, credit, completion, and certificates based on exam review. | This project is currently in the design phase. We would like to decouple a lot of these proctoring features that are currently spread across the LMS. |
Use Case Notes
Sync certificate and grade data from LMS to Credentials
Expand for notes on certificat and grade events...
Rough Notes on Grades Event POC
[From Matt Tuchfarber] Our top two use cases for message bus are:
Syncing catalog data from Discovery to Credentials, and
Syncing course certificate and grade data from LMS to Credentials
My first thought would be the GeneratedCertificate create/update/delete event, but in actuality we send a lot of auxiliary data with that API call now, and I don't know if it makes sense for you to build all that auxiliary data into the POC, and it'd be kinda of useless without it. It's an option though.
A grade change event would probably be a lot easier to POC since there's a lot less data to care about. So I'd vote that.
On grade change a signal gets sent that we listen to in our platform app: * https://github.com/edx/edx-platform/blob/3152c14192dcccac79b7b7a76eba91b380eba78a/openedx/core/djangoapps/credentials/apps.py#L33-L34
That signal handler just pipes to our send_grade_if_interesting code which only sends grade changes that are related to a GeneratedCertificate and are part of a course in a program. This is historically to avoid flooding the celery queue with grades we don't care about. With course certs eventually making their way to Credentials, those requirements wouldn't be worthwhile.
That sends a call to Credentials that looks like:
credentials_client.grades.post({
'username': username,
'course_run': str(course_key),
'letter_grade': letter_grade,
'percent_grade': percent_grade,
'verified': verified,
})
Credentials just has a UserGrade model with a DRF API that only does writes:
If we published the data, we could just make a listener on Credentials that filters it down to things we care about, and creates/updates those objects. Pretty straightforward I think
Additional Notes: