Solve the idempotent problem of the main order in the scenario where multiple sub orders under the main order will separate multiple requests.

Scenario:

The upstream system requests the downstream system.

Upstream conditions:

Upstream documents are divided into primary documents and sub documents (details). A primary document corresponds to multiple sub documents.

When sending a request to the downstream system, the parameter structure is that a main order contains multiple sub orders, and the downstream system may be requested many times.

Downstream conditions:

Downstream documents are also divided into primary documents and sub documents (details). A primary document corresponds to multiple sub documents. Idempotent is required for the master order.

Correspondence between upstream and downstream documents:

The upstream primary order and downstream primary order have a 1: n relationship.

Upstream sub list and downstream sub list have a 1:1 relationship.

Example of upstream request parameter structure:

{
    "bizCode":"INVENTORY_ADJUST",
    "subOrderDTOs":[
        {
            "detailOrderId":"2000001394868005",
            "itemCode":"..."
        },
        {
            "detailOrderId":"2000001394868006",
            "itemCode":"..."
        }
    ],
    "locationCode":"TESTCS1",
    "mainOrderId":"CSCSTESTCS1kt210914000005",
    "merchantCode":"CSCS"
}

Request example:

An upstream master order will be split into multiple requests:

The upstream master doc No. csctestcs1kt210914000005 is requested for the first time, corresponding to upstream sub doc No. 200000139486805 and 2000001394868006;

The upstream primary doc no. of the second request is also csctestcs1kt210914000005, but the corresponding upstream sub doc No. is 200000139486807, 200000139486808 and 200000139486809;

The upstream master doc no. of the third request is also csctestcs1kt210914000005, but the corresponding upstream sub doc No. is 20000011394868008 and 20000011394868009; (the sub order number has been included in the second request)

The upstream main doc no. of the fourth request is also csctestcs1kt210914000005, but the corresponding upstream sub doc No. is 20000011394868009 and 20000011394868008; (different from the order of the third sub Order No.)

For the fifth time, the upstream master doc No. csctestcs1kt210914000005 is requested, corresponding to upstream sub doc No. 200000139486805 and 2000001394868006; (exactly the same as the first time)

Request analysis

For the first three requests, we believe that idempotent is not required.

Because the information of sub order number is different, we think it is a different request. The third sub order number has been included in the second request, but we think it is a valid request and does not need idempotent.

The fourth and fifth requests are idempotent. Because the sub order numbers are the same and the order is different, it is considered to be the same request.

Treatment scheme

The primary order number is a string information.

Option 1

It is composed of merchant code, warehouse code, upstream primary doc No. and business code

"CSCS|TESTCS1|CSCSTESTCS1kt210914000005|INVENTORY_ADJUST"

Problems:

Different sub orders of the same primary order will be directly idempotent, and subsequent operations cannot be performed.

Option 2

It is composed of merchant code, warehouse code, upstream main doc No., sub doc No. and business code

"CSCS|TESTCS1|CSCSTESTCS1kt210914000005|2000001394868005|2000001394868006|INVENTORY_ADJUST"

Problems:

If there are multiple sub orders under the unified master order, if there are too many sub orders, the composition string will be too long and errors will be made when saving into the database. If the sub doc No. is sorted differently, it will be considered as different documents.

Option 3

A string is formed by sorting the merchant code, warehouse code, upstream main doc No. and sub doc No., and then MD5 encryption and business code

"CSCS|TESTCS1|CSCSTESTCS1kt210914000005|2f7625f846b788abfd84b2e991dd03f8|INVENTORY_ADJUST"

advantage:

At the same time, the problems of scheme 2 and scheme 1 are solved to ensure the order of sub doc No. too many sub orders are requested at one time. After MD5 encryption, a fixed length string can be obtained, so as to meet the idempotent requirements of the main doc.

Pseudo code

//Get sub doc No. list
List<String> outDetailOrderIdList  = getOutDetailOrderIdList(adjustOrderDTO);
//Sub doc No. list sorting
outDetailOrderIdList.sort(String::compareTo);
//Sub list splicing string
String outDetailOrderIdListJoinStr = String.join("|", outDetailOrderIdList);
//MD5 encoding is performed on the list string of sub doc No
String outDetailOrderIdListMd5 = MD5Util.toMD5(outDetailOrderIdListJoinStr);
        
//Generate power sign
String idempotentNoStr =  adjustOrderDTO.getMerchantCode() + VERTICAL_LINE + 
adjustOrderDTO.getWarehouseCode() + VERTICAL_LINE + 
adjustOrderDTO.getOutMainOrderId() +VERTICAL_LINE + 
outDetailOrderIdListMd5 + VERTICAL_LINE + 
adjustOrderDTO.getOutBizCode() + VERTICAL_LINE;
        

conclusion

Therefore, we use scheme 3 to do idempotent verification, which just meets the business requirements.