关于WISE自带的API研究分析原创
7人赞赏了该文章
649次浏览
编辑于2021年09月04日 17:29:15
此前做过一个第三方业务系统单据对接wise15.0业务单据的开发,只用到了基础资料、进销存单据的新增接口。
其中印象特别深刻的是,第三方业务系统的物料有六万多个,需要同步到wise的8个账套里。
结果同步了48小时还没同步完成。根据日志分析,平均同步速度为3个/秒。
咨询了厂家,厂家建议几种方案:1、部署多个中间层服务器,每个对应几个账套,然后分别访问这几个中间层服务器的api接口,分散负担;2、同步软件开多线程,比如同时开8个线程,每个线程对应一个账套。
因为客户这边不具备调整服务端部署的条件,所以我将同步程序改成多线程。
但是效率几乎没有提高,感觉我虽然开了多线程,但是它接口仍然是按顺序处理的。
所以我就研究了一下K3API目录下的文件,反编译出源码看看它的保存代码。然后我就发现,这是.Net的壳,COM的魂。
接口解析提交的参数后,即调用COM组件实现保存。这个算法和wise提供的实例代码里保存基础资料的算法是一致的,也和wise软件界面新增保存的算法一致。
所以,你在界面操作保存一个物料需要多长时间,接口基本上也需要多长时间。
它这是架构的问题,效率不可能改善的。
除非接口完全摆脱COM组件,重写一套保存逻辑。
说这些,并不是指责wise的api接口不好,毕竟有了这个接口,还是方便了不少的。说这些的目的,是希望厂家能够想办法优化一下接口效率。重写也没问题啊,有开发成本可以考虑EBDI模块收费嘛。我觉得只要好用,客户还是愿意出这个钱的。