互联互通系统建设方案知识讲解文档格式.docx

互联互通系统建设方案知识讲解文档格式.docx

《互联互通系统建设方案知识讲解文档格式.docx》由会员分享，可在线阅读，更多相关《互联互通系统建设方案知识讲解文档格式.docx（10页珍藏版）》请在冰豆网上搜索。

4.1.设计原则

4.1.1.实用性和先进性相结合的原则

方案的设计力求做到结构合理、性能优良、运行稳定，同时也是一个经济实用的方案，系统必须有较强的灵活性和扩展性，是一个可持续发展的平台系统，同时保证系统信息处理和传递的安全、可靠、及时、准确、完整，提高工作效率，减少人为差错。

充分考虑到在未来若干年内业务发展的需要，所选择的在技术上保证在相当长的一段时间内不落后。

与此同时，在保证实现系统建设目标的前提下，选择性能价格比高、成熟可靠的技术和产品，以保证系统的整体性、协调性、高效率、高性能的先进性原则。

4.1.2.经济实用性原则

确保用户所购设备真正能物尽其用。

在达到功能、满足用户需求的前提下，减少整体投资。

4.1.3.可行性、可靠性原则

必须保证在系统建立之后，在保证业务正常运转的前提下，在系统结构、设计方案、设备选择、技术服务等方面综合考虑，保证系统能够持续无故障运行。

能确保系统连续7x24不间断运行，并便于维护和修理。

当系统出现局部故障时，不会影响整体系统的运行，并能尽快地解决并恢复正常运行。

4.1.4.可扩展性原则

对此次设计具有优秀的可扩展性，可以根据具体需求的更新进行弹性扩展，可对服务器、存储、备份等进行扩展，以满足新的需要。

4.2.实现设计图

4.2.1.整体设计

交换平台由一个中心节点和部署在各个部门的数据接入控制器组成。

河池内部应用系统只同自己的数据接入控制器通信，完成公文信息的发布、下载以及与其他单位间的协同交互。

4.2.2.交互设计

根据互联互通厂商提供的接口交互模式，选择收发件箱方案进行开发设计，收发件箱方案是通过“对接适配器”软件在交换平台与用户对接程序之间模拟出一个邮箱系统，其中包含收件箱和发件箱，来完成用户对接程序和交换平台通信，如下图所示：

对接适配器是运行在用户方前置机上的一个应用程序。

前置机是用户单位内部一台服务器。

对接适配器将前置机上的两个文件夹分别模拟为收件箱与发件箱，作为与用户程序对接的接口；

适配器实现了HTTPS客户端和SFTP客户端的功能，用以与交换平台做交互。

用户对接程序与交换平台交互的封首信息和封内信息，均以信件的形式通过收发件箱在适配器与交换平台之间做传输。

为了保证对接适配器能够高效稳定地工作，建议将对接适配器与控制器部署在同一局域网中，其间不要穿越城域网、广域网，不要加防火墙或其它网络设备。

通过收发件箱同交换平台对接无需考虑网络通信与通信协议，只需要在业务层面进行开发。

此种开发方式兼具以下优点：

既可以让新的业务系统快速上线，还可以使业务系统与交换平台适当的融合为一体。

建议有需要将平台与业务系统进行融合且开发时间上相对较紧的单位选择此种开发方式。

4.3.平台关键实现

4.3.1.公文交互

说明

公文交互主要实现河池人民政府办公室与广西省办公厅之前的公文交互传输。

收文、发文的角色

A向B发文件，则A为发文方，B为收文方。

反之，则B为发文方，A为收文方。

发送和接收的实现机制

发送信件

一封信件分为封首和封内文件两部分（参见2.1.1节）。

将一封信件发送到数据接入控制器，需要两个步骤：

1）将封内文件利用SFTP协议上传到数据接入控制器的SFTP服务器的Upload目录上。

（为了便于今后管理和归档本单位上传的封内文件，建议在Upload目录下按当前日期建立子目录，比如建立Upload/2013-12-1目录。

2）构造封首报文，将封内文件的SFTP路径以及封内文件的MD5校验值填入封首报文的files节点区域,利用HTTPS协议将封首报文对应的字符串作为HTTPS协议的Body，发送到数据接入控制器的XML-RPC/RESTService服务器上。

收取信件

使用协议对接方式从数据接入控制器收取一封信件需要四个步骤：

1、向数据接入控制器提供的RESTService/XML-RPC服务发送一份“查询缓存信件”的报文（参“/信封范例/缓存信件/查询缓存信件/envelope.xml”）。

该请求的响应是一封查询缓存信件-反馈报文，此报文中将会携带最近未读缓存信件的封首（如果有缓存信件尚未拉取），参考“/信封范例/缓存信件/查询缓存信件-反馈/envelope.xml”。

2、向数据接入控制器提供的RESTService/XML-RPC服务发送一份根据缓存信件封首中的唯一标识符构造的“封首已成功接收的确认信件”（参考“/信封范例/缓存信件/确认封首/envelope.xml”），以通知数据接入控制器将已获取的封首从未获取队列中移除。

如果此步骤失败，则获取的封首不会从为获取队列中移除，在下次进行此步骤时会拉取到相同的封首。

3、解析信件封首中的files节点（如果有），从中提取封内文件的SFTP路径，从数据接入控制器的SFTP服务器上下载对应的封内文件，并做MD5完整性校验。

4、向数据接入控制器提供的RESTService/XML-RPC服务发送一份根据缓存信件封首中的唯一标识符构造的“封内文件已成功接收的确认信件”（参考“/信封范例/缓存信件/确认封内/envelope.xml”）。

数据接入控制器在收到此报文时会向信件发送方发送一封回执信（参考“/信封范例/回执/envelope.xml”），表示信件已成功被接收方获取。

对接程序需要周期性的从数据接入控制器上收取信件，建议间隔时间不低于10秒。

解封与加封

加封是将封内文件用交换控制信息包装，然后生成封首文件，最终得到封内文件和封首文件的过程。

加封过程结束后，将封首文件和封内文件放入信件的文件夹中。

其详细步骤如下：

1.创建一个空的新文件夹（文件夹名字不限，建议采用UUID以区别于其它信件）；

2.生成业务相关的封内文件（包含交换识别信息和交换主体信息，根据业务需要，封内文件可以包含零个、一个或多个），并将其放入刚创建的文件夹中,如果没有封内文件则跳过此步和第三步；

3.计算封内文件的MD5校验值，和其文件名（不包含其在文件系统中的路径信息）一起填入封首文件；

4.补全封首文件中其它控制信息（参见附录B以及“/信封范例”），将构造好的封首文件放入刚创建的文件夹，并命名为“envelope.xml”；

至此，加封过程完毕，即生成一个信件文件夹，可以将其放至发件箱，等待被发送。

解封是加封的逆过程，详细步骤如下：

1.操作一封信件，即一个包含有封首文件和封内文件的文件夹；

2.解析封首文件（envelope.xml），分析交换控制信息，如果有封内文件，则从可以从files节点获取封内文件（如果有）的文件名，在当前文件夹下即可寻找到对应文件；

3.将封内文件交付用户对接程序处理；

至此，解封过程结束。

信件的接收与发送中对xml文件的解析

一封信件分为封首和封内文件两部分（参见2.1.1）。

将一封信件发送到数据接入控制器，需要按照加封信件的流程构造一封信件。

适配器能够保证信件在构造过程中不会被发送。

信件发送失败会被移入收件箱根目录下的失败目录（即“.outbox_failed”目录）。

如果发送成功会移入收件箱根目录下的历史目录（即“history”目录）。

用户发送的信件状态会在适配器安装目录下的log/record.xml文件中以XML的形式记录，并实时更新。

其XML格式如下：

<

?

xmlversion="

1.0"

encoding="

UTF-8"

>

list>

<

!

--信件状态跟踪记录节点，一个节点代表一封信件的跟踪记录。

-->

--identifier是信件的唯一标识符，如果你发送的信件封首中没有填写信件唯一标识符信息（即封首文件中‘/envelope/header/@identifier’属性的值），适配器会自动补全，否则与你发送的信件封首中的唯一标示符值一致。

envelopeidentifier="

e8fa4921-1116-49e5-9144-22e67f360349"

--信件状态，有5种，分别代表对应下面message节点的5种信息。

status>

no_status、send_success、send_error、receive_success、receive_error<

/status>

--业务流水号，则此节点的值与你发送的信件封首中的业务流水号值一致。

business_id>

9227a98b-0a72-4f53-8bd0-a1f9a1c7703b<

/business_id>

--信件状态说明，有5种，分别代表对应上面status节点的5种状态。

message>

“无状态”、“已成功到达接收方数据接入器”、“到达接收方数据接入器失败！

”、“接收方已从数据接入器成功获取报文”、“接收方从数据接入器获取报文失败”<

/message>

--信件记录创建的日期。

create_date>

2014-06-26-09-35-09<

/create_date>

--信件记录最后一次更新的日期。

update_date>

2014-06-26-09-35-10<

/update_date>

dir>

信件当前所在路径地址<

/dir>

/envelope>

/list>

如果发送方开启了回执信功能（参考5.1.2节），且接收方是使用协议对接或者收发件箱的形式接入平台，则当接收方从数据接入器拉取缓存信件成功时会向发送方发一封回执信表示信件已经被接收，发送方适配器会收到发送的信件对应的回执信，当收到回执信时，会将发送的信件对应状态记录节点中的message信息置为“接收方已从数据接入器成功获取报文”。

信件状态记录xml文件中最多保存最近10000条信件的状态。

从数据接入控制器收取一封信件需要四个步骤：

1.用户对接程序扫描收件箱根目录下的inbox目录下的所有文件夹（每个文件夹对应一封信件），当发现一封信件后进行下一步处理；

2.用户对接程序分析封首文件（envelope.xml）；

3.判断该信件是哪种类型的信件（协同资源、交换资源、共享资源、系统通知），然后再根据类型分别做解析；

4.分析封首文件的files节点，判断该信件是否包含封内文件,封内文件就在封首所在目录下，已经做过MD5完整性校验，不需要用户做校验；

5.用户对接程序使用上一步的解析结果，进行相关业务处理（涉及具体业务的处理逻辑，可能涉及到与部门业务系统之间的交互）；

6.处理完信件后，删除此信件文件夹，避免下次遍历时再次扫描到此信件；

7.至此，用户对接程序针对信件的处理完成；

收发件箱不需要用户手动去数据接入控制器收取信件，信件会自动存放在收件箱目录下，用户只需要扫描收件箱下的所有文件夹即可。

4.3.2.书生印章整合

书生电子印章系统与电子政务系统进行良好结合，结合后的政务系统是一个完整系统，即印章功能应嵌入至应用系统中。

结合仅需应用系统进行少量的修改即可完成。

应用系统生成待盖章的格式文件，之后系统后台通过printcom接口自动调用书生SEP转换器转成SEP文件，这些过程对操作者而言都是透明的，前台察觉不到。

之后系统平台将调用书生阅读器和电子印章客户端，采用OCX控件方式，此时待盖章文件即被打开并且书生电子印章客户端已嵌入到当前工作页面，在相应位置加盖印章后点击“盖章完毕”按钮，盖章后的文件通过财务系统自动上传到服务器，并进入系统下一个流程。

盖章流程如下图所

示。

浏览盖章文件时，仍按照目前的工作流程，浏览者直接选择“浏览文件”相关按钮，财务系统平台自动调用书生阅读器和电子印章客户端，通过OCX控件方式嵌入工作页面，此过程对浏览者而言也是透明的。

这时浏览者就可以看到已盖章的文件了，并可以对其印章进行验证和打印文件。

验章、打印等操作接口都将无缝嵌入到工作平台中。

5.系统功能

5.1.组织唯一标识

把市政府组织架构里面的每个单位或组织设置一个唯一的组织机构代码与其一一对应。

这样在系统里每个单位或组织就只有唯一的一个标识。

5.2.收文流程

区政府办公厅OA系统把公文发送到区OA前置机中，再通过互联互通系统传输到河池市OA系统的前置机中，OA系统从前置机收件箱取文件，解封封头文件，根据封头文件解析封体文件，文件接收成功，删除已解析的文件夹，收文完成。

文件接收失败，记录日志，继续处理3次，如果依然失败，记录日志不再处理，收文失败。

5.3.发文流程

拟稿发文，盖章节点人为判断是盖书生印章还是其它电子印章。

如果盖书生印章，盖章前需要转SEP文件，然后盖章。

如果是其它电子印章，直接盖章。

盖章完成后点击发送公文，公文会被发送到前置机中，然后通过互联互通系统传输到区政府办公厅OA系统中。

注：

转SEP文件的公文发文后需要将文件按照格式写入前置机发件箱。

格式为一个文件夹包含两个文件（封头，封体）

5.4.系统接口

5.4.1.互联互通接口

实现河池人民政府办公室到广西省办公厅之间的公文交互。

5.4.2.书生印章系统

实现在河池电子政务系统中使用书生印章盖章，并最终发文。

6.运行环境

6.1.1.基础软件

WindowsServer2003/2008操作系统64Bit（标准版）、Oracle10g/11g数据库（标准版）

6.1.2.服务器

将数据控制端集成到电子政务系统中则不需要新增服务器，独立数据控制端则需要新增服务器，建议先尝试集成到电子政务系统。

7.方案优势

7.1.易用性

系统充分考虑到用户的计算机应用水平、操作习惯，采用人性化的设计理念，为用户之所想，使整个系统方便易用。

7.2.稳定性

系统稳定可靠，能够确保各项工作正常运转，实现不间断运行。

系统不会因误操作或其他原因导致数据错误或系统失败，特别是保证数据库的存储和备份安全。

7.3.安全性

使用身份认证机制、传输数据加密、Session时间机制、用户角色权限等手段来保障整个系统的安全。

7.4.可扩展性

可移植、模块化、开放平台，充分考虑后期其他单位电子政务系统的接入和发展的需要；