与公司开票接口对接的设计

为什么要对接改造？

     我们公司是做增值税管理系统的，增值税系统涉及到开发票的业务，需要与不同的供应商对接开票接口，供应商提供的开票接口，包括四种：A1供应商有两种，第一种是开票服务器，第二种是税盒 A2供应商也是一种是开票服务器，一种税盒。

         客户有用税盒开票的，也有用开票服务器的，各种情况都有

         我们的产品有两个开票历史版本，一个历史版本是 有一个WEB和一个开票客户端

         如图：

每一次要开票的数据，都要先经过web端处理完之后，存到数据库里面，然后再打开开票软件，进行开票

这样的缺点：1.操作繁琐，2.客户要装很多额外的软件

后来我们进行了第一次改造，就是借助Active 控件与本地机器通信，如图：

这样的话，客户不用再像历史一一样，需要安装一个客户端软件进行复杂的操作，但是active控件是有缺点的：一个是只有IE用，一个是配置复杂，测试人员因经常配置不好active控件，导致测试效率问题

现在的话，公司专门针对于这个问题，开发了一个稳定，不受浏览器限制，可以共享，集群开票的基础服务性软件，简单结构图如下：

这样的话，调用端不用，再像历史二那样，安装activce，不受浏览器限制，可以共享开票机器

1. 调用者请求业务服务，WEBService接受到请求会先对要传递的数据进行校验
2. 校验成功，给调用者一个受理信号，然后将要处理的业务请求，发送到MQ消息对列里面去，等待任务被处理
3. WebSocket会根据登录的开票机客户端，查找到要请求的开票机器号，并将数据发送到开票客户端
4. 待开票客户端完成，开票的操作之后，将结果返回到调用方
5. 最后，调用方，将处理完的结果，回写给调用方

基于历史版本，我要做的就是把原来历史二的开票方式，给替换成远程消息队列的模式。

要考虑到的一些点如下：

1. 原来有本地，调用active开票的，也有远程开票
2. 有A1厂家开票模式，也有A2厂家开票模式
3. 要提供回调服务，要考虑异步回写
4. 要方便以后的修改
5. 要可以执行不同的开票动作

设计了如下的改造结构：

用户可以针对于不同的业务进行回写服务的扩展和开票服务的扩展

可以添加不同的厂商开票方式

兼容原来的模式，前端只需要向后端传递数据，告诉执行什么动作

 

就可以按既定的业务模式执行业务了

 

转载于:https://www.cnblogs.com/gdnyfcuso/p/6603278.html