Event Bus Use Cases

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 (Albert (AJ) St. Aubin (Deactivated) Matt Tuchfarber (Deactivated))	Syncing catalog data from Discovery to Credentials	Currently handled with scheduled bulk updates. Has high latency and is prone to errors.
Aperture (Albert (AJ) St. Aubin (Deactivated) Matt Tuchfarber (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 (Brian Mesick (Deactivated) 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)	TBD	Noted in /wiki/spaces/AC/pages/3183346123

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.
  - https://github.com/edx/edx-platform/blob/d7a4947ea97ade19ae39684a429533e77baad891/openedx/core/djangoapps/credentials/tasks/v1/tasks.py#L255
- 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:
  - https://github.com/edx/credentials/blob/2a7a6475141333cc9b90d4d803d8f19041ae2a34/credentials/apps/api/v2/views.py#L136
- 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:

edx-platform sends three signals in this code:

COURSE_GRADE_CHANGED.send_robust(
    sender=None,
    user=user,
    course_grade=course_grade,
    course_key=course_data.course_key,
    deadline=course_data.course.end,
)
if course_grade.passed:
    COURSE_GRADE_NOW_PASSED.send(
        sender=CourseGradeFactory,
        user=user,
        course_id=course_data.course_key,
    )
else:
    COURSE_GRADE_NOW_FAILED.send(
        sender=CourseGradeFactory,
        user=user,
        course_id=course_data.course_key,
        grade=course_grade,
    )