Order Fulfillment Strategy
This page covers the design ideas for Order Fulfillment in Django-Oscar.
General Idea:
- Fulfill enrollments synchronously through the Enrollment API.
- Persist fulfillment status in django-oscar based on success or failure of request to Enrollment API.
- Allow manual resubmission of failed fulfillment from django-oscar, if the Enrollment API fails to enroll students.
Related Sections of Code in django-oscar
- order.processing.EventHandler is responsible for fulfillment via the "handle_shipping_event()" function.
- For all our digital product types, "handle_shipping_event()" will need to be extended to handle fulfillment.
- Each ProductType will require unique fulfillment actions, such as Enrollments requiring the Enrollment API.
- Each ProductType must have a unique fulfillment strategy defined in a new fulfillment API.
- We can use Order Status via order.abstract_models.AbstractOrder to have statuses for failed fulfillment.
Fulfillment API
- order.processing.EventHandler#handler_shipping_event() calls fulfillment_api.fulfill(order)
- settings.py has a configured mapping of ProductTypes to Fulfillment classes
fulfillment.py
- New fulfillment API module that has two functions
- fulfill(order)
- refund(order)
- Each function returns status on whether on success or failure.
- TODO: Need to identify all failure scenarios and map them to Order Status
Fulfillment Modules
- There will be a base fulfillment module that has the following interface:
- fulfill_product(product)
- refund_product(product)
- There will be an implementation per ProductType of "Fulfillment"
- For Q3 we only need the EnrollmentFulfillment implementation.
- EnrollmentFulfillment will contain the logic to call the Enrollment API synchronously to enroll a student.
Remaining Work
- Create a ProductType Definition (stories exist)
- Fulfillment API
- Wired into EventHandler
- Takes an Order
- Fulfills associated products
- Updates Order status
- Define order status
- state machine
- Update the Marketing Site to call into the new endpoint
- Course Mode table with SKUs for checking whether to use the new or old order workflows (short term)
- Login and Registration Pages
- Third Party Enrollment
- Bypassing Payment (via RESTful API work)
- Need to extend for payment gateways
- Can have additional logic for bypassing payment on free products
- The sandbox store has business logic for bypassing payment of free products as well.
Other Concerns
- Error Handling on order fulfillment
- Need celery task (or other queue) to re-attempt fulfillment on failed orders
- Incremental rollout means there will be a need to update the course modes table as well as Oscar
- Have a SKU table in the LMS that references rows in course_modes table (or add a new column)
- Pass the SKU through the Enrollment API
- Allows Drupal to build URLs based on the Enrollment API that can be used to purchase enrollments through Oscar.