CB Media Interface Description
Revisions
Version | Date | Description |
---|---|---|
1.1 | 08-06-2020 | Update MediaOrderB2C version Correct resource for notifyOrder and notityShipment |
1.0 | 28-04-2020 | Update yaml versions |
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.
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 and start order processing for orderline 1. 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 received stock for orderline 2, assigns stock and start order processing for orderline 2. 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 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 3 – customer cancellation
The customer orders one or more products, but decides to cancel the order shortly after ordering.
Flow description:
- The customer puts one or more products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder. The operation confirms acceptance of the order
- CB verifies the order, the shop is notified with the operation notifyOrder and status event In Progress
- The customer decides to cancel the order at the shop
- The shop forwards the cancel request per orderline to CB with the operation cancelOrderLine.The operation confirms a successful cancellation
- The shop confirms the cancellation to the customer
- CB informs the shop that the complete order is cancelled with the operation notifyOrder and status event Cancelled
Alternative Flow 4 – partial customer cancellation
The customer orders multiple products, but decides to cancel at least one of the orderlines but not all shortly after ordering.
Flow description:
- The customer puts multiple products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder. The operation confirms acceptance of the order
- CB verifies the order, the shop is notified with the operation notifyOrder and status event In Progress
- The customer decides to cancel orderline 1 in the shop
- The shop forwards the cancel request for orderline 1 to CB with the operation cancelOrderLine.The operation confirms a successful cancellation
- The shop confirms the cancellation to the customer
- CB assigns stock and start order processing for orderline 2. The shop is notified with the operation notifyOrder and status event ProductionReady
- 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 5 – CB order reject
The customer orders one or more products, but the order is not accepted by CB due to unknown products.
Flow description:
- The customer puts multiple products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder. The operation confirms rejection of the order
Alternative Flow 6 – partial CB cancellation
The customer orders multiple products and stock is available for at least one product. Also stock is not available for at least one product and backlog is not allowed.
Flow description:
- The customer puts multiple products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder. The operation confirms acceptance of the order
- CB verifies the order and identifies that orderline 1 is not available, the shop is notified with the operation notifyOrder and status event Warning
- The shop retrieves the order process status to see which orderline(s) are not available
- CB assigns stock and start order processing for orderline 2. The shop is notified with the operation notifyOrder and status event ProductionReady
- 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 7 – order during service window
The customer orders one or more products during the service window. Stock is available for all products.
Flow description:
- The customer puts one or more products in the shopping basket
- The shop forwards the order to CB with the operation placeOrder. The operation confirms receipt of the order during the service window
- CB confirms acceptance of the order after the service window ended
- CB verifies the order, the shop is notified with the operation notifyOrder and status event In Progress
- CB assigns stock and start order processing for the order. The shop is notified with the operation notifyOrder and status event ProductionReady
- The shop can retrieve the order process status with operation getOrderStatus to see which orderline(s) 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 8 – cancel during service window
The customer orders one or more products, but decides to cancel the order during the service window.