Event Bus Use Cases

This page is not intended to cover every use case, but to list specific needs or pain points from various squads. The event bus would generally be used for most future cross-service communication.

Squad / Contacts	Use Case	Status and Notes

Squad / Contacts	Use Case	Status and Notes
Phoenix (@Kashif Chaudhry (Deactivated) @Jeremy Ristau)	Syncing CMS course run creation with Discovery.	Arch-BOM is currently working on implementing this use case. Currently handled with scheduled bulk updates. Has high latency and is prone to errors.
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. Also see https://openedx.atlassian.net/wiki/spaces/SOL/pages/3381428720
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.
Content: Cosmonauts (@Andy Shultz (Deactivated) )	Detect some program intent actions to drive behavior	A later phase of program intent but I think likely to be implemented sooner or later.

Other use cases:

Additional parts of Refresh Course Metadata
Catalog Caching for Prospectus builds
Replacing synchronous calls from LMS to Discovery
Replacing synchronous calls from publisher (discovery) to lms/studio/enterprise
Publishing enrollment event for unknown/various future consumption.

Use Case Notes

Sync certificate and grade data from LMS to Credentials

Rough Notes on Grades Event POC

[From meeting with Kelly/Justin]

[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: * edx-platform/openedx/core/djangoapps/credentials/apps.py at 3152c14192dcccac79b7b7a76eba91b380eba78a · edx/edx-platform
- 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.
  - edx-platform/openedx/core/djangoapps/credentials/tasks/v1/tasks.py at d7a4947ea97ade19ae39684a429533e77baad891 · edx/edx-platform
- 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:
  - credentials/credentials/apps/api/v2/views.py at 2a7a6475141333cc9b90d4d803d8f19041ae2a34 · openedx/credentials
- 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, )