Diskussion:Shopping cart functionality: Unterschied zwischen den Versionen

Aus DRV STRING
Wechseln zu: Navigation, Suche
(Example container with a package and extrq rental car)
Zeile 34: Zeile 34:
 
** Rental car (BOOKED)
 
** Rental car (BOOKED)
  
== Example container with a package and extrq rental car ==
+
== Example container with a package and extra rental car ==
 
* Example Container 2:
 
* Example Container 2:
 
** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
 
** Package (Flight FRA-PMI/PMI-FRA, Hotel PMI)
 
** Rental Car
 
** 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.
 
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.
 +
Note after experts meeting on 08.02.2017:
 +
-- Generally the usage of references to containers and items is considered a good idea.
 +
-- Details will be examined more closely when dealing with the BookingContainer element.

Version vom 8. Februar 2017, 16:19 Uhr

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 extra 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. Note after experts meeting on 08.02.2017:

-- Generally the usage of references to containers and items is considered a good idea.
-- Details will be examined more closely when dealing with the BookingContainer element.