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.