WebService传输说明书1

WebService传输说明书

一、 WebService传输的原理

总部应用服务器 总部数据库 互联网 门店数据传输程序 门店数据库

二、 WebService传输的组成部分

以普通的总部门店间传输为例，WebService的传输组成部分包括： 1、 总部数据库（已有）

2、 总部应用服务器。采用IIS+海典通用Webservice服务 3、 门店数据库（已有） 4、 门店传输客户端程序

三、 WebService传输的优缺点及适用对象

1、 优点

1) 省去了租用或设置FTP服务器。

2) 传输由门店定时收发，直接针对总部数据库操作。因此总部不需要再点收发了。

3) 所有的传输设置全部以总部数据库里的为准。因此若要改变门店的传输设置，直接在总部改即可；当传输出

现错误时，也只需要针对错误在总部数据库作出修正即可。 4) 传输记录会实时反馈到总部。在总部能随时监控门店的传输状态。 5) 客户端程序支持自动更新以及更新后自动重启加载。

6) 运用事务最小化概念，将一个传输项目作为一个事务设计，弃用了传输中间表和中间触发器，中间处理不再

占用事务，最大限度减少了锁的开销，强化了并发概念，支持大量门店同时进行传输。 7) 客户端程序操作简单，支持任务栏加载和“气泡”提示。 2、 缺点

1) 需要配置一个（也可以多个）应用服务器。虽然该应用服务器可以用数据库服务器兼用，但是出于性能和安

全角度出发，不建议兼用。

2) 需要有固定IP或域名，或VPN，或其他的动态IP解析工具。

3) 当总部数据库不可用（如关机）时，门店无法进行收发数据操作并将报错。

4) 当总部和门店由多个互联网服务供应商接入时（如网通和电信），传输效率可能不如FTP方式。 5) 当门店采用电话线拨号接入时，传输效率不如FTP方式。 6) WebService传输要求总部采用SQL2005数据库。门店则不限。 3、 适用对象

1) 适用于带宽比较稳定，门店全天侯宽带接入（带宽256K或以上），总部有固定IP或相关动态IP解析方案

的客户使用。

2) 适用于门店数量众多（50家以上），传统的FTP传输太慢的客户。以200家店为例，假若在总部与每个门

店FTP传输一次平均需要4分钟，则全部传输一次需要800分钟约13个小时，这种情况下十分不利于总部门店间的及时传输。而WebService传输方式由于采用了并发，所以彻底解决了这个问题。

四、 WebService传输与FTP传输的关系

WebService的传输采用与FTP传输完全独立的传输项目、传输设置。所以两种传输方式不会相互影响。理论上说，同一客户两种方式可以同时使用。假若对于同一个门店，既启用WebService传输又启用FTP传输，那么意味着同一条数据必然通过两种方式各传输一次。或者对于同一个客户，一部分门店使用WebService传输，其他门店使用FTP传输。虽然这种情况下也可以正常工作，但是这种方式会增加维护的工作量（既要维护FTP传输又要维护WebService传输），另外两种传输方式的传输项目可能会存在一些差异，这种方式会导致同一条数据通过两种不同的方式传到不同门店后可能呈现出差异性，所以同一客户应当尽量避免共用两种传输方式。

对于原来使用FTP传输，想要改成WebService传输的客户来说，只需要建立好传输项目，将传输设置的最大序号修改为原FTP传输的最大序号即可。需要注意的是，这里所说的“最大序号”也包括门店发送的最大序号，这个值在总部是无法得到的。需要从门店的t_transet_c表获取数据。

五、 传输过程分解

1） 门店启动传输客户端程序 2） 客户端程序连接本地数据库

3） 客户端程序连接通过互联网连接应用服务器

4） 客户端程序判断应用服务器的download目录下是否有新版本的wstran.pbd，若有则自动下载更新，

然后重新启动客户端程序。

5） 客户端从总部服务器获取传输设置，将需要传输的项目显示在客户端窗口上。传输采用先发后收的机制；

并以用户设定的传输排序规则排序。

6） 发送一个传输项目。过程是：客户端程序以DATAWINDOW的方式从门店数据库提取到数据，另存为

到本地硬盘临时文件夹，压缩，传给应用服务器；应用服务器接收到数据后存为文件，解压缩，将解压得到的结果文件作为一个参数，以SQLCMD的方式直接执行。

7） 接收一个项目。过程是：应用服务器以SQLCMD的方式将总部需要发送的数据直接导出为一个文件，

存到应用服务器的临时目录，然后压缩该文件，将结果发送给客户端程序；客户端收到后存为文件，解压缩，然后分段读入到内存字符串中，上数据库执行。

六、 WebService传输项目定义

WebService传输的定义FTP传输定义比，主要存在几个区别：

1、 WebService的传输以一种逻辑数据作为一个传输项目，例如零售，将u_sale_m、u_sale_c、u_sale_pay这

三个表作为一个传输项目。而FTP一般以一个表作为一个传输项目。

2、 FTP传输以一个传输文件作为一个事务。假若一个传输文件里有10个传输项目，则从第一个开始到最后一个结

束，作为一个事务。这个过程中，表会一直锁住。而WebService传输已经没有传输文件的概念。每个传输项目就是一个独立的传输单元。

3、 FTP传输的顺序是以TRANID大小来判断的，而WebService传输的wstranid则建议使用业务逻辑简称（如零

售建议为SAL），然后另外设置一个字段来决定排序。这样便于每个客户根据需要进行修改调整。

4、 为了便于理解而不至混淆，WebService传输设置的说明中，一般不使用“发送”和“接收”，而命名为“传入”

和“传出”。数据通过应用服务器传入总部叫“传入”，数据从总部通过应用服务器传出叫“传出”。

5、 WebServicew传输项目表中，通常一行的数据将超过8000个字符。而SqlServer2000是不支持这种情况出

现的。因此WebService传输项目一般只能应用在SqlServer2005上。 下面将逐项解释WebService传输项目表t_ws_tranitem的含义。

? ? ?

Wstranid：传输项目标识。该标识一般以三位代表业务的字母来表示。 Wstranname：传输项目名称。

Wstranorder：传输排序。此字段决定传输项目的先后顺序。应注意的是，传输时总是先发后收。所有项目发送完后才会开始接收。

? DIRECT：传输方向。可接受的值包括IN、OUT、BOTH、NONE，分别代表本项目只允许传入、只允许传出、即或传入又可传出、均不可。

? ?

Validsql：校验SQL，暂时未使用。备用。可为空。

Headersql：传输头部的select语句。一般在这里定义建立临时表的语句。需要注意的是，传输头不会作为事务的一部分处理，所以在传输头中，不可以允许有insert、update、delete操作，除非这些操作是针对临时表的。多个语句间以union all 连接

? Detailsql：传输数据体的select语句。一般在这里处理需要传输的数据，即将数据逐行插入至传输头里建立的临时表中。此处支持$tranorg_src（传出时代表总部、出入时代表门店）、$tranorg_obj（传出时代表门店、传入时代表总部）变量，$maxserialno、$minserialno以及其他FTP传输项目支持的变量。多个表间以union all 连接

? Footersql：传输脚的select语句。一般在这里处理数据，将临时表的数据导入到最终目标表。传输脚是事务的起点，也是事务的终点。为了让事务更有效，传输脚的设计原则是：

首先：将完全没有锁开销的步骤放在最前面处理。如：删除临时表中的重复的数据。

其次：尽量将一个操作分解成多个独立步骤，然后将统一将所有没有锁开销的步骤都放在前面，将所有没有锁开销的操作全部处理完后，再处理有锁开销的步骤。例如，在零售传输中，先将一些临时表汇总、判断、删除等操作全部处理完后，再根据处理的结果插入目标表，这种设计能非常明显的提升并发效率。 对于必然占用锁的操作，先后顺序原则是：

首先，将目标表使用频率较低的操作放在前面。这样即使有锁，影响也会比较小；

其次，将运算比较慢、比较耗费时间的操作放在前面。这样至少在运行这个语句的时候不会连着别的表一起被锁住。

再次，将使用频率非常高的操作放在最后面。如：冲减库存等。

? Onerror：是指当本项目传输出错以后的处理方式。设为1表示忽略错误，继续传下一个项目。设为0表示终止本次传输，等待下一次传输时再从第一个项目开始重新传输。对于那些独立的项目（就算本项目没传成功也不影响别的项目），应该设为1；而对于商品资料、库存批次等与其他项目有关联性的项目，则应设为0。