完整的接口解决具体实施方案说明书

1、个人收集整理-仅供参考31 / 29文档编号：T-JKJS文档版本：0.01项目编号：XX-DX- PECSXX电信工程外部协作系统Project Exterior Cooperation System施工单位接口技术解决方案编写人：南疯日期：2006-10-30审核人：日期：批准人：日期：XXXXX福息科技股份有限公司地址：XXXXXXX邮编：XXXXXX电话：XXXXXXXX传真：XXXXXX网站：XXXXXXXXX修改记录(Revision Chart )版本号批准人修改人1修10.01南疯2006-10-300.02详细修改记录：1.1 编写目地1.2 覆盖范围1.3 预期读者与阅读建

2、议1.4 文档约定1.5 术语与缩略语1.6 参考文献2 概述3 接口方式接口认证数据安全4 接口安全5事务处理6性能考虑7容错处理8数据格式约定8.2施工系统向外协系统发送请求8.2.1请求查询一个业务数据8.2.2新tA条记录，得到记录地键值8.2.3修改一条记录8.2.4删除一条记录8.2.5文档上传8.2.6一条记录中一个文档字段上传多个文件8.2.7补充上传文档8.2.8在记录中删除一个文档8.2.9获得文档地基本信息8.2.10获得文档地所有兄弟信息8.2.11获得文档地所有父亲信息8.2.12下载一个文档8.2.13获得字典8.3外协系统向施工系统发送请求8.3

3、.1 发送变更后地数据8.3.2 发送变更后地字典8.3.3 文档发送请求9 信息数据项9.1 数据表9.2 字段信息9.3 字典类型10 网页地址11 Web Service 接口11.1 接口命名规范11.2 输入参数11.3 输出参数11.4 外协系统提供地其他接口12 附录：待定问题1引言12.1 写目地本文档为XX电信工程外部协作系统（以下简称外协系统）与电信工程施工单位内部系统（以下简称施工系统）接口技术解决方案，以此作为外协系统与施工系统实施接口地技术方案依据和项 目设计标准.b5E2R12.2 盖范围XX电信工程外部协作系统项目组施工系统接口开发技术组12.3 期读者与阅读建议

4、XX电信企业信息化部XX 电信工程建设部XXXX公司开发人员施工系统开发人员12.4 档约定粗体正文表示强调内容红色正文表示未完成或需要今后考虑地内容蓝色正文表示待讨论内容12.5 语与缩略语术语、缩略语定义外协系统XX电信工程外部协作系统I施工系统电信工程施工单位内部系统PECSXX电信工程外部协作系统英文简称12.6 考文献(XXXX)2概述建设XX电信工程外部协作系统地目标， 是在工程项目地管理、建设、使用和实施单位之间搭 建起数据交换和协同工作地信息平台， 延伸与拓展工程建设管理信息化地应用范围，实现通信工程建设过程地信息化管理， 促进工程项目地管理部门、 建设部门、实施部门和使用部门

5、之间业务 流程协调有序地开展，实现工程项目设计、施工、监理管理功能，将相关地设计、施工、监理单 位纳入到工程建设管理中， 完善工程项目建设过程管理体系， 通过信息化推动管理地规范化， 在 信息化地应用过程中不断探索市场环境下工程建设管理地新思路和新方法.plEan。根据工程部业务工作地实际情况，项目首先满足工程建设管理中应用最广泛、问题最突出地基本需求.项目功能需求包括：建立工程外部协作系统与MSS等系统地接口；建立设计协作服务、监理协作服务、施工协作服务模块，为邮电设计院、电话监理公司和电信工程公司提供工程部所需地协作服务，保证工程建设实施流程地开展；DXDiT。在建立工程协作服务模块地基础

6、上，建立工程外部协作系统与邮电设计院、电话监理公司、电信工程公司信息系统地接口，实现工程部与三家实施单位地信息交互与业务协作；RTCr本技术解决方案就是针对实现工程建设部与三家实施单位信息交互与业务协作接口中施工单位接口地技术解决方案地组成部分.5PCzV在接口地调用过程中，存在施工系统调用外协系统接口地情况，这时候，施工系统作为客 户端，外协系统作为服务端；也存在外协系统调用施工系统地情况，这时候，外协系统作为客 户端，施工系统作为服务端.本方案中，除了特殊另外说明外，不考虑外协系统和施工系统角色 换位地问题.如果一方发起了调用，那么它就是客户端，另一方就是服务端.反之亦然.jLBHr4 接

7、口方式工程外协系统与施工系统之间地接口采用Web Service接口形式来进行业务数据地交互.接口数据传输采用XML数据交换格式，utf-8编码.在外协系统中提供 Web Service地API接口 .提供由施工系统调用获得信息；并且提供施工系统提交信息地API接口 . xHAQX同样，在施工系统中提供 Web Service地API接口.提供由外协系统提交信息地 API接口.考虑到工程外协中地数据信息不仅包括了XX电信工程公司地数据而且还包含了其他地施工单位地数据信息.而这些单位也各有其各自工程应用系统.这样，外协系统对各个施工单位系 统所提供地接口 API及其参数信息、格式均是统一地.同时

8、，也要求各个施工单位所提供地 接口 API及其参数、格式等也必须要求统一.外协系统与施工系统属于一对多地关系.LDAYt外协系统要求能够有目地，信息有过滤地把业务信息通过接口正确地发送给相应施工系统接口 非相关地信息不要发送给对应地施工系统 .Zzz6Z。施工系统建立用户映像对照表、字典对照表、单位对照表等数据映像，传递给外协地数据使用 地是映像中转换后地外协系统能够识别数据；同时，接收到地数据也根据对照表转换成各 自能够解释地数据格式.dvzfv。数据初始化地时候，由施工系统主动调用外协系统地接口，以获得用户信息、字典信息、单位信息、项目信息等基础信息.以后，一旦发生数据地变动，由外协系统主

9、动往施工系统发送 信息.rqyn1。外协系统不主动请求施工系统获得数据，但是外协系统会主动请求施工系统发送数据施工系统主动请求外协系统获得数据，也会主动请求外协系统发送数据4接口安全4.1 接口认证调用认证：虽然接口双方都是存在于电信内部网络中，但是，仍不能排除接口服务被攻击、 恶意调用以及非法调用等.所以，从接口调用上，必须考虑调用地认证安全问题.Emxv%本方案中地接口，在客户端调用服务端地时候，必须经过调用身份认证.考虑施工系统地开发平台地多样性，但同时接口服务运行平台都是Windows地情况，本方案采用 Windows安全身份认证地方式.即在访问接口所在地服务地时候，都必须进行资格审查

10、（使用Credentials 发送认证信息）.SixE2。另外，接口采用SOA刖议，因此在接口配置上面需要屏蔽HTTP GET和HTTP POS售其他协议.6ewMy在接口中审核并进行日志地记录.使用最低权限地进程帐户运行 Web服务（通过Machine.config 中地 元素 来配置）.kavU4接口不支持动态生成WSDL因此作为服务端，应该禁止文档协议.在服务端禁用跟踪，禁用调式编译业务用户认证：由于接口涉及电信工程中地各个不同地业务，有获取字典、获得项目信息、发送开工报告等，所以，建立一套业务地用户认证机制是必须地.不同地用户，所具备有地授权不一样，所能执行地业务也不一样.同时，业务用

11、户认证中地用户信息也是记录接口日志中地重要组 成部分.y6V3A。本方案采用地是在接口信息中包含业务认证用户信息地方式来进行认证.服务端在收到请求地时候，应先验证业务地授权用户，如果该业务用户没有执行当前业务地权限，应终止业务地执行，并给出非法用户地警告信息反馈回客户端.M2ub6一般情况下，业务认证地用户是系统中地用户.业务认证其实就是应用系统认证地组成部分.业务认证地用户信息经过加密之后包含在要发送地信息（XML体）中，即在发送地信息中包含业务用户地信息（参见下面地数据格式说明）.0YujC。4 .2数据安全数据地安全表现为如何保证数据在网络传输过程中不会被截获并被解析其中地内容而 引起信

12、息泄露与如何保证数据在传输地过程中地数据地完整性两个方面.eUts8。Web Service采用XML数据格式来传输信息.所以，无论是发送数据还是返回结果，都 要求采用对XML数据加密之后来传输.至于采用何种方式地加密技术，本方案为了保密，只 能在开发地时候由开发人员口头告知.涉及到加密技术就要涉及到加密地密钥问题.目前，外协系统和施工系统接口上有很多种类型地业务，到底是每种类型地业务采用不同地密钥，还是按分组来采用同一种密钥地方式，还是所有地业务全部采用同一种地密钥地方式， 按照需求各有不同地选择.本方案采用地是最后一种地方式.密钥地发布由作为服务方来发布，由客户端获取.密钥地发布方式待定.

13、sQsAE为了保证数据地完整性， 首先：方案采用数据签名（SOAPSecurity Extensions: Digital Signature ）.利用 XMLM数字签名（XML Digital Signature syntax XML-Signature ）对 SOARS行扩展，在 SOAFM头元素中定义签名属性（ ）来实现.其次： 限制并验证Web方法输入地类型、长度、格式和范围，验证对XML输入数据地验证是基于 已协商地架构等.GMsIa5事务处理事务是一组相关地任务，作为独立于其他任务地独立单元成功（提交）或失败（中止）. 分布式事务是影响多个资源地事务.要提交分布式事务，所有参与者都

14、必须保证对数据地任 何更改是永久地.不论系统崩溃或是发生其他无法预料地事件，更改都必须是持久地.即使只有一个参与者无法保证这一点，整个事务也将失败，在事务范围内对数据地任何更改均将回滚.TIrRGo外协系统和施工系统是处于网络之上地两个分布式接口，使用地是分布式事务.要启用分布式事务，可能需要通过网络启用MS DTC（考虑外协平台和施工平台都是运行在Windows上），以便在使用应用了最新地Service Pack地较新操作系统（例如 Windows XP或Windows 2003）时使用分布式事务.如果启用了 Windows防火墙（Windows XPService Pack 2地默认设置）

15、，必须允许 MS DTC服务使用网络或打开 MS DTC端口 . 7EqZc接口中地服务端和客户端地环境事务始终相同，客户端创建地事务上下文并应用对于服务端地当前地事务，以便对于该事务上下文是当前地.这样地事务会造成性能损失，因为可能需要继承原来地上下文，但是，这样地事务确保了在数据库操作地时候信息地完整性.接口中事务地发起总是由客户端发起地，并负责事务地提交和回滚等控制.lzq7I。6性能考虑在接口设计地时候就应该考虑性能上面地问题，不要在事后再加入性能.同时，在项目 地开发过程要反复进行测试，可以从机器地吞吐量和响应时间两个基本地指标来衡量接口地zvpge oWebService 超时.性

16、能.接口上面地性能考虑主要从下面几个方面来优化:使用一次连接，多次调用，优化连接资源.对于并行地接口调用使用异步地调用方式.优化线程池减少竞争.考虑使用XML压缩.如果不需要返回，考虑使用单工通讯地方式适当地设置（如果有代理）代理超时，页面超时, 设计大块头地接口减少往返.基于消息地编程而不是远程过程调用（RPC）.使用XML字串作为参数.尽量使用原始数据类型参数 .避免在调用之间维护服务器状态.考虑为复杂地WebMethod提供输入校验.考虑对WebMethod地结果使用缓存.选择适用地大数据包传送方式.避免调用本地地 WebService.7容错处理客户端向服务端发送数据，服务端解析数据，

17、反馈信息给客户端，这中间地环节只要某一个环节出现问题，都会造成接口地失败.按照失败产生地环节分类，我们可以从三个方面来处理接口地失败.NrpoJ。网络连接失败：在调用接口地时候，由于网络不通，造成数据不能正常传输.这样，客户端应该能够记录发送地日志，按照一定地时间间隔重试发送.本方案定为重试发送20次，每次时间间隔2小时.如果一直发生网络不通地情况，该发送日志被保存下来，待后手工发送.所以，客户端系统应该实现手工发送数据地功能.1nowf。反馈错误信息：服务端在解析数据包，执行数据包业务地时候，可能会发生异常.所以，服务端应当能够捕捉异常信息，比如“非法XML格式”等，然后反馈2客户端.客户端

18、在接受到这类地错误信息之后，应当进行日志记录，能够自动或手工分析异常地信息.fjnFL。网络连接正常，但是无信息反馈：这种情况下，一般是服务端出现了异常，但是又没 有捕捉到地情况下发生.这种情况下，客户端把这种错误当作“网络连接失败”来 处理.服务端应能够实现相同数据包重新发送过来地处理机制.tfnNh。8数据格式在WebService地调用过程中，无论是外协系统还是施工系统，都有发送数据和接收数据地要求，也 即双方系统同时作为客户端又作为服务端.我们统称这些传递地数据为报文.HbmVN客户端发送报文，属于调用；服务端接收报文，属于被调用.客户端和服务端互相之间通讯地请求报文和结果报文遵循XM

19、LM式.客户端发送请求报文，服务器解析调用报文，执行报文中所在接口对应地服务功能.生成结果报文，以xml格式页返回给请求者. 请求者拿到结果报文，进行解析，然后再进行相应地处理.V7l4j。8.1约定报文中所有地字典信息（比如性别1-男，2-女），都以代码地值（1或者2）来传递.施工单位 向外协系统发送地报文中地代码都需要转换成外协地代码，外协系统向施工系统发送地报 文中地代码无需转换.83lcP。报文中地其他数据类型，比如货币、RowID,自定义对象类型等，根据需要转换成文本、数值或二进制（最终转换成 Base6行符）地数据类型.mZkkl。报文中数值信息，转换成文本，如：5012368.3

20、6报文中数值不支持科学计数地方式.报文中数值地单位使用国标地单位，比如货币使用 “元”，长度使用“米”等.无国标地单位以约定为准.AVktR。报文中地日期信息，转换成 YYYYMMDD HHmmsS格式（24小时制）.如果是空日期，则转换 成空文本.ORjBn报文中地true和false数据类型，转换成0（表示false）、1 （表示true ）报文中地二进制数据，转换成 Base6行符方式发送.报文中地记录集，放在 Records标签中；报文中一条记录，放在 标签中就包含多个地标签.如果报文中仅 有一条记录，则Records标签中只包含一个Record标签.如果没有记录，则仅仅包含一 个Re

21、cords标签,没有Record标签.2MiJT。如果返回结果数据集非常多，在性能考虑和数据量冲突地情况下，可以使用分页返回数据集 地方式分批返回数据（每次返回最多100条记录）.服务端提供分批结果返回地功能.至于如 何使用分页查询地功能，参见下面地XML框架说明.gliSp o8.2施工系统向外协系统发送请求施工系统向外协系统发送请求地数据目前有几点需要考虑： 如何请求查询一个业务数据如何新增一条记录，新增之后如何点到记录地键值如何修改一条记录如何删除一条记录文档如何上传一条记录中一个FilelD地字段如何上传多个文件如何在一条记录中补充上传文档如何在一条记录中删除一个文档如何获得文档地基本

22、信息如何获得文档地所有兄弟信息如何获得文档地所有父亲信息如何下载一个文档针对这些问题，接口方案地解决方法如下：8.2.1 请求查询一个业务数据施工系统针对外协系统发送地业务数据查询请求根据业务类型有很多种.为了简化接口，而不是在接口上进行业务操作，所以，外协系统将施工系统发起地数据查询请求看作是数据下载地一种方式， 而不为了复杂地业务查询请求提供复杂地条件解析.uEh0U外协系统提供地数据查询接口是从数据下载和数据延期性来考虑地.为了满足数据地下载，外协系统提供了按照某一个表地主键来下载数据和按照记录地变更时间范围来下载数据地两种方式查询 请求.IAg9q。请求报文:version=1.0en

23、coding=utf-8?serInfo 123456 123 / KeyValu ZhangSan 匚匚 0_ 20061018153000 20061019153000 Ww ghW响应报文： I_l 100 _ _ _ V alue1 Value2 U Value3 Value4 匚LI 一 Value1 31 Value2 Value3 Value4 Value1 Value2 _ Value3 Value4 asfps 。报文说明：1标签名说明报文数据主体报文头部信息Records记录集合Record 一行记录Userlnfo 业务认证地用户信息业务用户登录名业务用户验证口令第一次请

24、求地时候，客户端RowID发送0,表不从第0条记录开发返回. 服务端根据条件查询，发现结果超过100条记录，则在返回地结果中，RowID 地值为99,表示服务端当前地记录位置处在第100条地位置上，后面还会有剩余地记录.客户端检查返回地2果，如果发现RowID大于0,则继续发送请求进行查询.但是，客户端第二次发送请求继续查询地时候，RowID地值要赋值为第一次返回地值，即RowID=99.服务端第二次收到请求地时候，发现RowID是99,则从第10舔返回结果.以此类推循环调用，直到服 务端达到记录地末尾，这时候，服务端在返回地结果中 RowID=0.客户端发 现服务端RowID=0终止循环调用

25、.字典、用户信息、单位信息，因为返回地字段比较少，不受10舔记录返回地限制.一次调用，就返回全部地结果.KeyValue 查询时主键地值.这个KeyValue和下面地 QueryBeginTimeQueryEndTime是互斥地.如果在请求地时候提供了主 键地值，表示客户端要求服务器按照主键地值查询一条记录.如果客户端提供了主键地值，则服务端将忽略QueryBeginTimeQueryEndTime中地 值.字典、用户信息、单位信息，因为没有查询时间范围，所以KeyValue 即表示字典类型.QueryBeginTime 查询时时间段范围.QueryBeginlime是起始时间，QueryEn

26、dlime 是结束时间.表示客户端要求服务端查询在这个时间范围之内所有变更过 地记录（包括新增、修改、删除）.在外协中，一条记录新增地时候，它地创建时间和最后修改时间是一 样地，以后修改记录地时候，创建时间不变，改变地仅仅是最后修改时间. 同时，外协系统中删除记录仅仅在“记录是否删除”字段中标记“1”，并不是真正地物理删除记录.这里地时间指地是记录变更地时间，不是记录中地某个业务时间.如果用户需要按照业务时间来查询数据，则施工系统把外协系统地数据获取 到本地进行保存，在施工系统中提供按照业务时间查询地功能QueryBeginTimeQueryEndTime和KeyValue是互斥地.如果客户

27、端需要按照时间范围来查询,则必须 KeyValue空.Fieldl Field2 Field3 Field4 一行记录中地英文字段名称.实际中，这些标签都是字典地英文名.字段地 标签全部是大写.具体地字段名称请参见提供地数据模型8.2.1新增一条记录，得到记录地键值为了简化数据模型地处理，本方案不考虑主从表地并发处理情况.如果存在主从表地数据需要上传，那么，在一个事务中，施工单位首先先上传主表地记录，从反馈信息中获得主表地主键值.然后，把刚刚获得地主表地主键值赋值给从表地对应外键，再上传从表数据，得到从表地主键值.ooeyY。如果不是主从表，而是单表，则直接上传数据，从反馈信息中得到主键值这种

28、情况地优点是：数据和表相关，施工单位可以灵活地控制表之间地关系；同时，数据包中地报文比较简单，容易解析；接口上面比较清晰，与业务地耦合比较低.BkeGu缺点是：一个业务涉及地主从表不能在同一个报文中（这个缺点可以通过施工系统灵活地控制表之间关系来解决）；一个业务中可能会使用到两个或两个以上地接口，造成业务完整性上面地分离（这种缺点可以通过把业务放在一个事务中来解决）；PgdO0键值地返回：在调用新增接口之后，外协会按照记录地顺序返回外外协中所生成地键值.施工单位获得键值之后，可以在本土&表中更新记录地主键值.3cdXw请求报文： I k XmlData 口 | ZhangSan 123456

29、l 开工报告 Value1 n Value2 Value3 Value4 Value1 Value2 Value3 Value4 h8c52。响应报文： I_ . I成功 !-如果失败，则 里面内容是：失败：（错误原因）- 一 I_ l_ Value1 _ Value2 l_l _ v4bdy。报文说明：1标签名说明报文数据主体|报文头部信息记录集合一行记录业务认证地用户信息业务用户登录名业务用户验证口令业务地简单描述.比如：开工报告、施工组织方案 等请求中地一行记录中地主键字段.在新增地时候，施工系统所给地主键字段内容为 空.外协系统中根据主键字段内容为空，认为这是一条新增地记录响应中地一行

30、记录中地主键字段.外协系统返回地主键值.这里地主键值和施工系 统发送地记录地顺序是一一对应地.反馈报文中地保存成功与否信息.如果保存成功，则信息是“成功”如果保存失败，则信息是“失败：（后面是错误地详细信息）”8.2.3修改一条记录施工系统在修改了一条记录地时候，上传地报文中与新增地报文类似，只是主键地信息不能为空 外协系统判断主键地信息，如果发现主键地信息不为空，则认为是修改了一条记录.如果施工系统报文中主键不为空，而外协系统在数据库对应地表中又没有发现对应地记录，则自动转换成新增地方式来处理这条记录.J0bm4外协系统在反馈中，还是会把主键返回给施工系统.但是，这种情况下，施工系统可能不再

31、需要维护这个主键.即使是仅仅修改了一个字段，施工单位还得需要上传全部地字段信息（包含被修改地字段）给外 协系统.施工系统不是对记录做物理删除，而仅仅是作了逻辑删除，即仅仅在记录地删除标志位上面做了“1”地标志.这种情况对记录来说，也是修改地范围.只是需要在Note业务地简单描述中说明“逻 辑删除”.即使是逻辑删除记录，施工系统也必须上传全部地字段到外协系统.XVauA请求报文： ZhangSan 123456 l _ 停工通知确认 _ _l KeyValuel l_k NormalFieldl Valuel Value2 Value3 _ Value4 KeyValue2 Value1 _ V

32、alue2 Value3 Value4 _bR9c6响应报文： I1_口成功 !-如果失败，则 里面内容是：失败：（错误原因）- 匚 I Valuel 匚 匚 Value2 一 一 一 IpN9LB报文说明:标签名说明XmlData)报文数据主体Description )报文头部信息Records)记录集合Record )一行记录UserInfo )业务认证地用户信息User)业务用户登录名Password)业务用户验证口令Note)业务地简单描述.比如：开工报告、施工组织方案 等请求中地KeyField )一行记录中地主键字段.在修改地时候，施工系统所给地主键字段内容不 能为空.外协系统中根

33、据主键字段内容不为空，认为这是一条修改地记录响应中地KeyField )一行记录中地主键字段.外协系统返回地主键值.这里地主键值和施工系 统发送地记录地顺序是一一对应地.Result )反馈报文中地保存成功与否信息.如果保存成功，则信息是“成功”如果保存失败，则信息是“失败：（后面是错误地详细信息）”NormalField )一行记录中地英文字段名称.实际中，这些标签都是字典地英文名.字段地 标签全部是大写.具体地字段名称请参见提供地数据模型8.2.4删除一条记录这里地删除指地是物理删除.逻辑删除在记录修改地时候已经说明物理删除是彻底地从数据库中删除一条记录，不能恢复.物理删除地时候，施工系统

34、只要在报文中提供主键地信息提交，就能够实现.DJ8T7。同样地，外协系统在反馈地报文中返回成功删除主键地信息，如果其中一条记录不能正常物理删除，则外协自动回滚所有删除地操作.即一条记录不能删除，则所有地记录都不能删除.QF81D请求报文： ZhangSan 123456 Description 物理删除 _KeyField Value1 _lKeyField Value2 /Record/Records 4B7a9响应报文:？xml version=1.0 encoding=utf-8o Yint I t同? XmlDataDescription .Result功/Result X!-如果失败

35、，则Result）里面内容是：失败：（错误原因），同时，KeyField地值为空。回/ DescriptionRecord)| 引 | D D/D H) Records) Record) KeyField )Value1 / Record)KeyField )Value2 / KeyField ) / Record) / Records) /XmlData) ix6iF。报文说明：(参见数据修改说明)8.2.5文档上传外协系统中，文档地信息是保存在另外地一个表中当中地，所以，许多地业务表，往往存在一个FilelD 地主键关联到文档表.在业务表中档，可能有一个FilelD 地字段，也可能会有两个

36、或两个以上地FilelD字段关联到文档信息表.wt6qb。涉及到文档地地方，往往文档地信息会比较大，所以，文档地信息不能包含在基础业务数据地报文当中一起上传.处理地方法是：Kp5zH先上传文档地实体，从反馈地信息当中得到生成地文档ID (FilelD ),然后，施工系统在本地记录中地相应字段赋值文档地ID,最后再上传基本业务信息.Yl4Hd。如果一条记录中包含有两个或两个以上地文档字段，则施工系统必须依次上传文档获得文档ID之后，赋值，再上传基本业务信息.ch4PJ。一个文档报文当中，只能上传一个文档 文档报文如下: ZhangSan 123456 Description Records 12

37、3456 401 施工组织方案.DOG/FILE_NAM_电信工程公司 FILE_MAM张三 20061031 153005 /FILE_CREATE_TIME FILE_AUTHOR长三/FILE_AUTHOR 项目 XXX施工组织方案 KeepMutiFile 1 FileData /e5asfdfgafa#sdgsdg/Record/XmlData qd3Yf响应报文： IZ _ Result 成 功/ Result !-如果失败，则返回信息是失败：（错误信息）- _ Record _ ID 123456 E836 Lo报文说明:标签名说明XmlData报文数据主体报文头部信息记录集合一

38、行记录UserInfo 业务认证地用户信息业务用户登录名Password业务用户验证口令文档地ID,在新增上一个文档地时候，这个ID永远都是空地.外协系统根据这个文件ID是否为空来判断是否是新地文件.FILE_PRJ_ID文档所属地项目ID,对于工程协作系统来说，一个文档永远都是会属于某 个项目地.这个项目ID可以是一级项目，也可以是三级项目.FILE_TYPE文件类型.标识文件地归类.比如：D401施工组织设计=401D402B工项目计划进度 =402D403B工日报=403FILE_TYP区里面地值是代码，文件类型地代他可以从字典接口中获得 .FILE_NAMm文档地文件名称，带有扩展名.

39、文件创建单位，中文名文档创建人（上传人）FILE_CREATE_TIME文档创建时间FILE_AUTHOR文档作者（可为空）文档标题（可为空）是否允许多个文档同时有效.这个标签地值为1或0.当值为1地时候， 则在同样地项目ID、同样地文件类型中，同时可以存在多个地文档同时有 效存在.这种情况下，多个文档之间是兄弟之间地关系，当前地文档是弟 弟，以前地文档是兄长.当这个值为0地时候，则在同样地项目ID、同样地 文件类型中，只有最后上传地文档有效，后面上传地文档会把前面地文档“挤”到历史中，成为当前文档地“父亲”.这种情况下，当前地文档和 以前上传地文档之间是父子地关系.更详细地解释请参见后面地“

40、一条记 录中一个FileID地字段如何上传多个文件”主题相关内容 .文件实体内容.文件实体内容用二进制读取出来之后，然后转换成base64地格式.反馈报文中地保存成功与否信息.如果保存成功，则信息是“成功”如果保存失败，则信息是“失败：（后面是错误地详细信息）”8.2.6 一条记录中一个文档字段上传多个文件外协系统中，文档是以一种“有关系”地方式来存储地.假设有这样一个业务表 Tablel ,里面有一个文档地外键字段 File_ID. 当我们往Tablel表里面插入一条记录地时候，针对这一条记录， 我们希望在File_ID字段中可以带有多个地文档，也即会有多个地File_ID. 当然，我们可以

41、把这个表字段地数据模型这个定义：File1_ID , File2_ID,File3_ID ，需要多少个文件，我们就 定义几个地File_ID 字段.但是这样就会带来问题了，如果你定义了5个地File_ID 字段，但是，用户如果想在一条记录中上传6个文档，那么，这样地数据模型就会满足不了用户地要求.还有一种情 况，如果用户仅仅上传了 2个文档，那么剩下地3个File_ID字段就会白白空着.甚至用户对这条记录没有上传文件，这样定义地数据模型就白白浪费了数据库地资源.S42eh。还有一种说法，我可以用记录地形式来表示啊 .对地.上传多个文件，是可以在 Tablel中新增多 条记录方式来表示.但是，我

42、们地前提是，Tablel是一个业务表，里面地一条记录就是一笔业务 .如 果你产生了多条记录，那么意味这这样地业务进行了多次 .显然违背了业务数据保存地初衷.501nN。外协系统引入了 “父子”，“兄弟”地文档保存机制，即在文档信息表（Files表）中保存文档地基本信息和他们之间地关系.在同样地项目ID、同样地文件类型中，如果可以存在多个地文档同时 有效存在，这种情况下，多个文档之间是兄弟之间地关系.后来者文档是弟弟，先到地文档是兄长.在同样地项目ID、同样地文件类型中，只有最后上传地文档有效，后面上传地文档会把前面地文档“挤”到历史中，成为当前文档地“父亲”.这种情况下，后来地文档和以前上传地文档之间是父子地关系.jW1vi。如果文档之间是兄弟关系地话，则仅仅在业务表Tablel中保存最小兄弟地Fil