此前做过一个第三方业务系统单据对接wise15.0业务单据的开发，只用到了基础资料、进销存单据的新增接口。

其中印象特别深刻的是，第三方业务系统的物料有六万多个，需要同步到wise的8个账套里。

结果同步了48小时还没同步完成。根据日志分析，平均同步速度为3个/秒。

咨询了厂家，厂家建议几种方案：1、部署多个中间层服务器，每个对应几个账套，然后分别访问这几个中间层服务器的api接口，分散负担；2、同步软件开多线程，比如同时开8个线程，每个线程对应一个账套。

因为客户这边不具备调整服务端部署的条件，所以我将同步程序改成多线程。

但是效率几乎没有提高，感觉我虽然开了多线程，但是它接口仍然是按顺序处理的。

所以我就研究了一下K3API目录下的文件，反编译出源码看看它的保存代码。然后我就发现，这是.Net的壳，COM的魂。

接口解析提交的参数后，即调用COM组件实现保存。这个算法和wise提供的实例代码里保存基础资料的算法是一致的，也和wise软件界面新增保存的算法一致。

所以，你在界面操作保存一个物料需要多长时间，接口基本上也需要多长时间。

它这是架构的问题，效率不可能改善的。

除非接口完全摆脱COM组件，重写一套保存逻辑。

说这些，并不是指责wise的api接口不好，毕竟有了这个接口，还是方便了不少的。说这些的目的，是希望厂家能够想办法优化一下接口效率。重写也没问题啊，有开发成本可以考虑EBDI模块收费嘛。我觉得只要好用，客户还是愿意出这个钱的。

能力够的话自己写一个就好了 不一定要用标准的API。。。 就是能力不够 哈