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.