CB Media Interface Description

Revisions

Introduction

This document contains a description of the standard interfaces for implementation of data exchange with CB via webservices.

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.

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

MediaOrderNotify

MediaShipment

MediaShipmentNotify

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