Showing results for 
Search instead for 
Did you mean: 

Keep the same cart number for order

0 Kudos

Hello SAP team, I have two questions regarding the "orderCodeGenerator" and its modifications.

1.-I would like to know how it works, also how it works in "cluster".

2.-There is the possibility of keeping the same cart id so that when generating the order it keeps that same cart id, and what would be the disadvantages of doing this.


Accepted Solutions (1)

Accepted Solutions (1)


We use this approach (order code is the same with cart code) in most of our projects since we use it mostly for as a reference on payment provider. This will not cause any DB related issue since their table are different i.e. orders and carts. The only problem could happen is when a problem / exception occurs between order creation and cart removal. In such cases, order will be generated in the table but cart will not be removed. Thus, additional order creation request will be failed since the order with the same code already exists. Other than this case, I don't think it will cause you a problem.

Easiest way to achieve this is to override DefaultCreateOrderFromCartStrategy's generateOrderCode method as below

protected String generateOrderCode(CartModel cart) {
return cart.getCode();

And defining the spring definition

<alias alias="createOrderFromCartStrategy" name="customCreateOrderFromCartStrategy"/>
<bean id="customCreateOrderFromCartStrategy" parent="defaultCreateOrderFromCartStrategy"

Hope this helps,

Answers (1)

Answers (1)


DB table is used to guarantee that the order/cart id is unique across the whole system even in cluster environment

  1. There is a special numberseries table which is used to maintain the current availabe id number range, please note, there is only one availabe number range record for each key (here, the key is something like order_code)
  2. In the cluster environment, optimistic lock can guarantee each node will take different number range
  3. Whenever a new cart/order is created
  • If there is available number in the cached number range, it will return the available number as the id, then points to the next available number in the cached number range
  • If there is no availbe number in the cached number range, it will query numberseries table to get the only one availble number range for key 'order_code', then it will update numberseries table to set new available number range for key 'order_code'. For example, suppose the initial number range is from 1 to 100, then new number range will become from 101 to 200, from 201 to 300, etc.

cart and order will use different id in the default implementation, since both of them are based on the same key 'order_code', each time as order instance is created from a cart instance, a new id will be generated from current number range

if you hope that order will copy the id number from related cart, customization is required, but i don't think it makes sense