CB Media Interface Description
Revisions
Version | Date | Description |
---|---|---|
0.6 | 12-03-2020 | Add volume limits and error messages; Correct typo in process flow diagrams |
0.5 | 13-01-2020 | Add flows and sequence diagrams |
0.3 | 11-11-2019 | Add operations |
0.1 | 30-08-2019 | Initial document |
Introduction
This document contains a description of the standard interfaces for implementation of data exchange with CB via webservices.
The entire set for the standard data exchange with CB consists of the following documents and files: | |
The mapping from file based to webservice based messages | |
The functional description of the definitions in the operations | |
yaml definition files | An OpenAPI Specification file (yaml) for each resource |
Overview webservices
This chapter gives an overview of the available interaction patterns for data exchange with CB. The figure below gives an high level overview of the CB system landscape and the available webservice operations.
CB provides REST based webservices. In REST operations define the available activities.
The webservices provide online creation and cancelation of media orders at CB. Changes to an order (other than cancel) are not available. Resending an order is possible only when the order was not accepted by CB earlier.
Webservices are available 24 hours a day, 7 days a week, however order handling is restricted to warehouse working hours. Our regular maintenance window is on Saturday from 08:00 hours until 14:00 hours. The webservice operations are available during this time, but received requests are stored only (i.e. not validated or processed).
File versus Webservice
Communication about orders is based on the receiving channel, i.e. file base communication is used for orders received via file based interfaces and webservice communication is used for orders received via the webservice.
Orders are processed independent from the receiving channel.
Mapping batch files versus webservice operations | |
---|---|
OPDNAW | placeOrder |
ANNOPD | cancelOrder |
UITOPD | notifyOrder / getOrderStatus + notifyShipment / getShippingUnit |
NUITOP | notifyOrder / getOrderStatus |
Timing
Webservice requests are processed realtime, i.e. an order is registered immediately when the webservice call is executed. Order processing at CB is based on scheduled processes and not primarily triggered by the webservice request.
Responses to the requester are send in Near-Realtime (NRT) with an average delay of 2 to 3 minutes. The regular maximum delay is 5 minutes, in exceptions running up to 10 minutes. During this timeframe the orderstatus has reached a status that is not yet reported to the requestor.
Volume
Webservice requests are limited to a maximum of 10 requests per service per second per requestor.
Performance
The media webservices comply with the generic CB webservice performance requirements:
- Average response time within 2 seconds during prime-time (08:00-01:00 CET)
- Response within 3 seconds for 99,95% of the requests during prime-time
- Response within 6 seconds for 99% of the requests outside prime-time
MediaOrderB2C
Webservice name: | MediaOrderB2C |
Definition: | MediaOrderB2C.yaml |
Resource: | Orders |
Operations provided by CB: | |
placeOrder | Send one (1) order to CB |
cancelOrderLine | Cancel one (1) orderline |
getOrderStatus | Retrieve the status of one (1) order |
MediaOrderNotify
Webservice name: | MediaOrderNotify |
Definition: | MediaOrderNotify.yaml |
Resource: | Notifications |
Operations provided by you: | |
notifyOrder | CB calls your webservice to inform you about status updates of an order |
MediaShipment
Webservice name: | MediaShipment |
Definition: | MediaShipment.yaml |
Resource: | ShippingUnits |
Operations provided by CB: | |
getShippingUnit | Retrieve the shipment information for a shipping unit |
MediaShipmentNotify
Webservice name: | MediaShipmentNotify |
Definition: | MediaShipmentNotify.yaml |
Resource: | Notifications |
Operations provided by you: | |
notifyShipment | CB calls your webservice to inform you about a shipment for your order |
Process flows
This chapter contains the identified flows when using webservices to order physical books at CB. The most common and regular scenario is describes in the happy flow. In addition 7 frequent scenarios are described in alternative flows.
Happy Flow
The customer orders one or more products, stock is available and the order is shipped in one shipment.
Flow description:
- The customer puts one or more products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder
- CB verifies and accepts the order, the shop is notified with the operation notifyOrder and status event In Progress
- CB assigns stock to the order
- CB starts order processing. Cancellation of the order is not possible anymore, the shop is notified with the operation notifyOrder and status event ProductionReady
- The shop can retrieve the order process status to see which orderlines are ready for production and cannot be cancelled anymore
- CB executes pick and pack for the order and creates a shipment. The shop is notified with the operation notifyShipment and status event Processed
- The shop retrieves the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer
- CB informs the shop that the order is completed with the operation notifyOrder and status event Processed.
Alternative Flow 1 – multiple shipments
The customer orders multiple products and stock is available for all products. At pick and pack multiple shipping units are created. The order is shipped in multiple shipments.
Flow description:
- The customer puts multiple products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder
- CB verifies and accepts the order, the shop is notified with the operation notifyOrder and status event In Progress
- CB assigns stock to the order
- CB starts order processing. The shop is notified with the operation notifyOrder and status event ProductionReady
- The shop can retrieve the order process status to see which orderline(s) are ready for production and cannot be cancelled anymore
- CB executes pick and pack for orderline 1 and creates a shipment. The shop is notified with the operation notifyShipment and status event Processed
- The shop retrieves the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer
- CB executes pick and pack for orderline 2 and creates a shipment. The shop is notified with the operation notifyShipment and status event Processed
- The shop retrieves the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer
- CB informs the shop that the order is completed with the operation notifyOrder and status event Processed.
Alternative Flow 2 – multiple shipments due to partial backorder
The customer orders multiple products and stock is available for at least one product. Also at least one product is in backlog. The order is shipped in multiple shipments.