| Table of Contents |
|---|
CB Media Interface Description
Revisions
...
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
...
Notifications
...
MediaShipment
...
ShippingUnits
...
Retrieve the shipment information for a shipping unit
MediaShipmentNotify
...
Notifications
...
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.
...
| Date | Description |
|---|
Update MediaOrderB2C version
Correct resource for notifyOrder and notityShipment30-08-2019
Introduction
This document contains a description of the standard interfaces for implementation of data exchange with CB via webservices.
...
...
...
...
...
...
| Added extra information authorisation: “Basic ”||"Base64 encoding of username and password joined by a single colon : " |
| Media Order B2C: Yaml file version 1.3.0 Changelog version 1.2.0 to version 1.3.0:
MediaShipment: Yaml file version 1.0.0 version 1.1.0 Changelog version 1.0.0 to version 1.1.0:
|
| Authentication notify services, CB supports:
|
| Test and order simulation added |
| Add Tag matrix for Green and Standard option |
| Update yaml file MediaOrderNotify v.1.0.2.yaml |
| Update generic error messages |
| Align with updated order notifications |
| Update yaml file MediaOrderB2C v1.2.0.yaml |
| Update MediaOrderB2C version Correct resource for notifyOrder and notityShipment |
| Update yaml versions |
| Add volume limits and error messages; Correct typo in process flow diagrams |
| Add flows and sequence diagrams |
| Add operations |
| 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 | ||||||||||||
| Tag matrix for Green and Standard option | ||||||||||||
CB has two options for submitting e-commerce orders:
| ||||||||||||
| yaml definition files | An OpenAPI Specification file (yaml) for each resource | |||||||||||
https://services.cb.nl/rest/api/v1/mediaorderb2c/swagger.yaml Contains PUT (cancel), GET (status) and POST (place order) | ||||||||||||
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 nor processed at that moment) when our ERP systems are not available. Processing will resume as soon as our ERP systems are available again..
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 |
| Authentication mode | CB supports:
|
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 |
| Authentication mode | CB supports:
|
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 prepares for logistic processing of the order. 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 can retrieve the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer.
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 prepares for logistic processing of the order. 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 can retrieve 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 can retrieve the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer
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 backorder. 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 prepares for logistic processing of 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 can retrieve 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 prepares for logistic processing of orderline 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 can retrieve the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer.
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 acceptance of the cancellation
- CB informs the shop that the complete order is cancelled with the operation notifyOrder and status event Cancelled
- The shop confirms the cancellation to the customer.
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 acceptance of the cancellation
- CB informs the shop that an orderline is cancelled with the operation notifyOrder and status event Cancelled
- The shop confirms the cancellation to the customer
- CB prepares for logistic processing of 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 can retrieve the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer.
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 Cancelled
- CB identifies that orderline 2 is available, the shop is notified with the operation notifyOrder and status event InProgress
- The shop retrieves the order process status to see which orderline(s) are not available
- CB prepares for logistic processing of 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 can retrieve the shipment details (including tracking number and a list of products) per shipping unit and can inform the customer
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 verifies and accepts the order, the shop is notified with the operation notifyOrder and status event In Progress InProgress
- CB assigns stock to the orderCB starts order processing. Cancellation prepares for logistic processing of the order is not possible anymore, the . 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 orderlines 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 can retrieve 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 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.
one or more products, but decides to cancel the order during the service window.
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 and accepts the order, the shop is notified with the operation notifyOrder and status event In Progress
- CB assigns stock to The customer decides to cancel 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 shipmentin the shop
- The shop forwards the cancel request per orderline to CB with the operation cancelOrderLine. The operation confirms receipt of the cancellation request during the service window
- CB confirms a successful cancellation of the order after the service window ended. The shop is notified with the operation notifyShipment notifyOrder and status event ProcessedCancelled
- 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.
...
- confirms the cancellation to the customer
Webservice operations
This chapter describes the operations including some special remarks. Webservices are defined in the English language, available values in enumerations are also in human readable English (if possible).
Responses
The operations reply with a http response code as indication of the result. Regular http codes 200 and 204 indicate a successful request, codes like 400 and 404 indicate a failure.
Error messages
When the request is not successful the response includes an error message to identify the reason. Error codes are grouped into:
- WXX The request does not comply with the yaml definition;
- WMS Authorization failures;
- WMO The request encountered a mapping error, mainly due to incorrect shipment date(s);
- WSP No body supplied;
- OMS A supplied value encountered a functional error, like unknown SKU.
The list of error codes within these groups may change in time without notice
Generic error messages
- WXX-00001 Reported field does not comply with yaml definition
- WXX-00002 Reported field is not recognized
- WMS-00001 Invalid length for password
- WMS-00002 Invalid username/password combination
- WMS-00003 Invalid service
- WMS-00004 Not authorized to use this service
- WMS-00005 No username and/or password provided by the caller
- WMS-00006 Unable to authenticate
- WMS-00007 Unable to authorize
- WSP-00013 Empty body
Order
placeOrder
The operation placeOrder supports sending one order for a customer. An order can contain multiple orderlines, each for a specific title. Confirmation of the operation is provided with a http-response-code.
Check order identification (Requestor Order Id)
The identification of an order is used to check if an order already exists in the CB systems. If this is the case the new order is rejected. Only open orders are taken into account, so closed/cancelled orders are ignored.
Order type
The operation is available for order types ShipBuyer (LNAFN), ShipOwner (LNEIG) and ShipSecundaryOwner (LMEONE).
Sender and Owner
In the common scenario for media orders the sender requests CB to ship titles owned by a publisher to a consumer. This scenario identifies the publisher as owner, the sender (shop) as buyer from the owner and the consumer as receiver (and buying from the shop). An alternative scenario is secondary ownership, in this alternative scenario the sender (shop) already purchased titles from the publisher and requests CB to ship from its own stock.
Party
Because parties where goods have to be delivered are not known by CB the PartyType “ReceiverAddress,” is mandatory and all name and address information must be provided.
Values added services (VAS)
VAS activities can be controlled by means of special handling instructions for the order.
Examples of instructions:
- Wrap the books in gift paper
- Add leaflet to the package
Available special handling instructions must be agreed upon in advance by requestor and CB.
Specific error messages
OMS-01097 Unknown SKU
OMS-01099 Duplicate OrderId
OMS-01100 Unknown ShipmentCode
OMS-01107 Unknown CountryCode
OMS-01202 Unknown RelationId
OMS-01315 Unknown SKU
OMS-01338 Unknown document
cancelOrderLine
The operation cancelOrderLine supports cancellation of one orderline. Cancellation is available until the orderline is released for production (“vrijgegeven”). Confirmation of the operation is provided with a http-response-code. The operation requires the OrderId and OrderLineId as input and is available for orders entered via webservices only.
Specific error messages
OMS-01201 Unable to map sending party
OMS-01216 Unable to map OrderId
OMS-01251 Unable to map OrderLineId
OMS-01269 Unable to cancel. Orderline already processed
getOrderStatus
When the status of an order or orderline is changed a notifyOrder message is sent. This is the preferred trigger to call the operation getOrderStatus.
The operation getOrderStatus provides the status summary of the requested order. An order can contain multiple orderlines, each for a specific title. The status of every orderline is reported separately. An orderline can also be reported in multiple statuses, for instance when part of the quantity is available and ready for production and the remaining quantity is in backorder.
If (a part of) the order is not delivered, the status includes an explanation why.
The operation requires the OrderId as input and available for orders entered via webservices only.
Available statuses for notifyOrder:
- New Order is accepted after being received during the service window
- InProgress Order(line) passed validation
- ProductionReady Order(line) is ready for pick/pack in warehouse
- Warning Order processing started with an issue for at least one orderline
- Processed Order is finished with shipment
- Cancelled Order is finished without shipment
Shipment
getShippingUnit
When a shipment is ready to be shipped a notifyShipment message is sent per available shipping unit. The operation getShippingUnit provides the contents of the shipping unit and the relation to order and orderlines. An order can be shipped in multiple shipping units.
The operation requires the ShippingUnitId as input.
Available statuses for notifyShipment:
- Processed ShippingUnit is ready for shipping
| Include Page | ||||
|---|---|---|---|---|
|
Test environment
| Include Page | ||||
|---|---|---|---|---|
|
Addendum
Migration strategy from batch file to webservice
Suggested migration strategy from batch file to webservice:
- Verify technical and functional process with a live connection to the CB test environment.
- Arrange for shadow-run(s) in a combination of production and test environments,, i.e. send an OPDNAW message to the CB production environment, extract a few orders and send them via the webservice to the CB test environment. CB can verify the received data in the test environment against the production data from the OPDNAW.
- Arrange for go-live date
- Send a limited number of orders via the webservice to the CB production environment. CB can monitor the processing of these orders.
- Verify the information in the order status and shipping unit operations.
- Step-by-step increase the webservice load until the required level is reached.
- If applicable then disable the file based flow.