Diskussion:Shopping cart functionality

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.