Diskussion:Shopping cart functionality

Aus DRV STRING
Wechseln zu: Navigation, Suche

Michael Althoff remarked: Question/Remark: The project is about the definition of an interface - shopping carts can either be a function of the front end or the inventory system of the tour operator. The interface itself does not provide an own shopping cart. Pls check the use case

Peter Holtermann: This requirement is about the implementation of a shopping cart in the the inventory system of the tour operator. But to make that accessible through the String-Interface, we need to expose some kind of reference, which is called BookingRef in the use case. The other additional field BookingMode is something we need anyway in some way or another.

I do not really care about the wording: We could call the container "Shopping Cart" as well as "Reservation" or "Booking Container".

The important parts are:

  • The interface has to contain a reference to a container that can contain more than one product. Products could be single products or packages.
  • The Products in the container may have different states.

Example workflow:

Find and add a flight

  • Container 1
    • Flight FRA-PMI/PMI-FRA (ADDED)

Find and add a hotel

  • Container 1
    • Flight FRA-PMI/PMI-FRA (ADDED)
    • Hotel PMI (ADDED)

Find and add a rental car

  • Container 1
    • Flight FRA-PMI/PMI-FRA (ADDED)
    • Hotel PMI (ADDED)
    • Rental car (ADDED)

Everythings fine? Ok, book all the stuff in the container

  • Container 1
    • Flight FRA-PMI/PMI-FRA (BOOKED)
    • Hotel PMI (BOOKED)
    • Rental car (BOOKED)

Example container with a package and an extr rental car

  • Example Container 2:
    • Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
    • Rental Car


The whole container/reservation/shopping cart stuff should be an optional feature. Clients could query the the implementing systems via the configuration service, whether they support the feature or not.