电商/零售场景大数据量对接的性能优化与应用优化建议原创
金蝶云社区-钟秋生身份
钟秋生
17人赞赏了该文章 1,008次浏览 未经作者许可,禁止转载编辑于2022年05月09日 14:42:48

      目前,企业的应用系统越来越多,ERP和其他系统对接的需求越来越多。

其中,对接比较多的是前端的各种电商系统、零售系统。这些业务场景下应用特点是单据金额小但是单据量大。

通常情况下一天的单据量/分录量从几千、几万到几十万不等。这样大的业务量和数据量,高效和可靠对接是保障正常应用的关键。

      本文结合一些收到的大数据量对接项目的反馈,针对电商/零售等大数据场景下项目的对接总结出一些建议。这些建议包括业务流程优化建议和对接接口性能优化建议。遇到类似场景的做对接的人员可以参考。

 

场景:前台电商/零售等对接星空供应链系统。

 

一、业务流程对接建议:

1、流程尽可能不要跨系统交叉,降低业务和流程的复杂度

       这个其实就是要求只对接流程结果。各自系统中尽可能把流程完整跑完,将一个流程的结果传入另外一个系统即可。这样的好处是流程各自独立运行,互不影响,一旦接口出现问题,双方系统还能独立运行。对业务的影响最小。

电商和零售等业务,我们建议流程上只对接电商和零售的销售出库单,所有的业务都在前台系统跑完,只将结果出库单/退货对接到星空即可。尽量避免一个订单处理流程跨2个系统,这样出现问题,涉及到2个系统的流程调整,出现数据问题需要在不同的系统处理,提高了应用的复杂度。比如,对接电商系统,电商系统一般的流程是第三方系统下载订单->订单处理-->订单拣货/分配库存-->打印快递单—>出库/发货一个完整的流程。如果要对接,建议是电商的出库结果对接到星空的出库单即可。这样,电商独立处理整个订单发货流程,这个流程不依赖星空,流程出现问题,不需要在2个系统中处理,降低了流程的复杂度和耦合度。

 

2、对接的单据尽可能不要产生跨组织内部交易

       由于前台电商,零售门店多,业务量大,出库单量非常大。如果这些对接过来的销售出库单需要做跨组织结算,会生成大量的内部交易单据,以及跨组织的明细结算清单,后续对账、核算带来很大的工作量。2C的销售出库单都是针对电商客户的零散的出库,出库单明细非常多,建议业务流程上取消电商与总部之间的销售出库单的跨组织交易,内部通过购销或者调拨的跨组织交易模式进行。即总部与电商通过调拨方式,这样调拨可以定期(如每天每周)成批调拨,降低单据量。这样跨组织交易就变成了2个组织之间调拨单,数量汇总了,单据量少。跨组织交易生成的应收应付清单数据量少,对账对总数即可,简单。而非前端的几十万的明细销售出库单。
3、如果需要保留跨组织交易,建议按一定的规则汇总合并后生成星空出库单。

      如果实际业务上就是这样的跨组织出库,则需要保留跨组织交易,则我们建议前端的出库单,通过一定的汇总依据传到到星空,生成数量合并的销售出库单。降低出库单的明细分录数量。参考如下的方式,对出库单进行合并。    

     大数据量下对接数据对接到ERP的中间表中。通常将外围第三方需对接的数据对接到ERP的中间表中,中间表按一定的合并规则(相同物料、相同店铺等)合并。

     前端电商和星空,考虑按一定的条件进行合并(如店铺、物料、仓库、时间等维度),如按天,将同一个店铺,相同的商品前端的出库单进行合并再传给星空。一般数量可以成倍几十倍的降低(依赖于相同商品的购买频次、合并的时间范围、业务量的等因素,如一个店铺某种商品,一天卖出100笔,正常按数量合并后,只有一笔,数据量约为原来的1/00)。这样的一个好处是,出库单的分录数量大大降低,由于合并数量了,核算、后续的应收应付、对账更加高效,简单(不要从几万,几十万的明细数据中核对,只要对总数量、总金额,效率提升),另外一块是出库单、应收单之类的日常操作,审批等业务用户的体验会更好。

 

二、     对大数据量接口性能上的优化建议: 

       大数量应用场景下,性能上主要体现在2个方面,一个是对接的单据传输性能,另外一个传输过来后的大量单据后续的核算、应收、应付等单据操作上的性能。

        目前收到部分项目中,由于对接的数据量大(每天几万到几十万出库单),造成出库单传输接口性能瓶颈,以及对接生成的出库单单据量比较大,因此出库单据的核算、出库单的操作如审批下推生成应收单等都有较大的性能问题,影响用户的体验。

   针对接口的性能优化建议:

1、 生成的单据中取消不必要的服务

       针对具体的项目中,不用的功能服务取消。如对接销售出库单,传过来的出库单单价、金额都有的,那么取价服务可以不要。前台2C的用户,信用相关的服务可以不要。库存的锁库与预留等相关的服务都可以取消。这个针对具体的场景,不需要的业务和服务都可以取消,加快单据的传输。可以根据项目和应用具体自行评估可以取消的服务。

2、 考虑批量接口调用及批量合并

       每次不要一单单传输,按一定的批量传输,数据要分批通过执行计划对接,通过ERP的执行计划插件,少量多次,分批轮询执行,每批次定量从临时表抓取待同步的数据(比如一次200条,控制在5分钟内本批次的全部执行完毕的最优条数,避免超时)。

针对webapi接口性能的优化,详细措施可以参考如下链接:
https://vip.kingdee.com/article/11179?productLineId=1

 

三、出库单单据量大的优化建议

       由于前台电商,零售门店多,业务量大,出库单量非常大。大批量的出库单后续的核算、应收、应付等单据操作上的性能的问题,建议是可以考虑按一定的措施合并分录/单据。具体建议如下: 

    1、大数据量下对接数据对接到ERP的中间表中。通常将外围第三方需对接的数据对接到ERP的中间表中,中间表按一定的合并规则(相同物料、相同店铺等)合并。

     2、前端电商和星空,考虑按一定的条件进行合并(如店铺、物料、仓库、时间等维度),如按天,将同一个店铺,相同的商品前端的出库单进行合并再传给星空。一般数量可以成倍几十倍的降低(依赖于相同商品的购买频次、合并的时间范围、业务量的等因素,如一个店铺某种商品,一天卖出100笔,正常按数量合并后,只有一笔,数据量约为原来的1/00)。这样的一个好处是,出库单的分录数量大大降低,由于合并数量了,核算、后续的应收应付、对账更加高效,简单(不要从几万,几十万的明细数据中核对,只要对总数量、总金额,效率提升),另外一块是出库单、应收单之类的日常操作,审批等业务用户的体验会更好。


赞 17