基于多组织架构的电子公文交换系统的设计
以下是资料介绍,如需要完整的请充值下载.
1.无需注册登录,支付后按照提示操作即可获取该资料.
2.资料以网页介绍的为准,下载后不会有水印.资料仅供学习参考之用.
密 惠 保
1.无需注册登录,支付后按照提示操作即可获取该资料.
2.资料以网页介绍的为准,下载后不会有水印.资料仅供学习参考之用.
密 惠 保
资料介绍：
1.1. 背景
1.1.1. 业务背景
为了提高政府机关公文处理效率和质量，避免信息孤岛的再次出现，提高业务的关联性，整合系统资源，简化系统操作的复杂性，加强系统的可维护性和完整性，必须对现有的深圳市政府办公厅网上办公系统进行改造。
为了适应新的公文交换平台标准以及各用户单位对电子公文交换的更高要求，运行近四年的深圳市党政机关电子公文交换系统的平台部分架构和系统已经不能完全满足新形势的改革发展需求，必须对现行系统进行改造。通过对现有电子公文交换系统的改造，制定统一规范的标准数据交换接口，以满足当前乃至今后市政府各部门的业务需求，整合交换系统各接入节点的资源，实现信息互联互通，提高工作效率，使其真正成为一个覆盖全市的分布式数据交换平台。
该电子公文交换系统要求包括三个子系统：办公厅OA，核心交换，智能客户端。其中办公厅OA负责市政府办公厅的电子公文交换和办文；核心交换负责电子公文的传输；智能客户端负责全市各个职能局之间、各职能局和办公厅之间以及各职能局和其下属单位的电子公文交换和办文。同时监察局和督察局可以通过智能客户端对各单位的办文状态进行跟踪并进行有效的催督办。
新改造后的系统必须采用多种新的技术标准规范，针对电子政务新形势下的需求增加新的功能，采用统一的接口规范实现电子公文交换系统数据的统一接入，无缝联结。新系统应该能够全面完善现有系统的功能，并在保持现有风格和功能的延续性的基础上，建立一个更先进和完善的电子公文交换和办文平台，进一步增强系统的功能以适应政府办公和业务信息化的发展要求，以及获得在开放式架构基础上与其他政府部门业务信息系统的紧密结合能力，进一步提高办文效率，增强政府部门之间的协作能力。新系统的主要目标是提高机关公文处理效率和质量，不再出现信息孤岛，提高业务的关联性和协同性，整和办公信息资源，简化业务处理功能操作，提高可视化操作程度，加强系统的可维护性和完整性。
1.1.2. 智能客户端
在二十世纪九十年代中期，Microsoft(R)Window(R)操作系统开发的胖客户端应用程序的数量急剧增长。胖客户端的目的是为了减少服务器的负担，充分利用本地硬件资源以及客户端操作系统平台的功能。尽管胖客户端技术通常提供了高质量，快速响应的用户体验，减少了服务器的负担，但是它们却非常难于部署和维护，同时系统的兼容性问题也日益凸突。这些问题使得应用程序变得非常的脆弱。
Internet的出现提供了传统胖客户端模型的替代模型，它解决了许多与应用程序部署和维护相关联的问题，给基于浏览器的瘦客户端应用程序是在中央web服务器上部署和更新的，因此它消除了将应用程序的任何部分显示部署到客户计算机并加以管理的必要性。瘦客户端的出现使得应用程序的简单部署和统一维护变成了现实。但是 瘦客户端是基于web的，因此它要求客户的浏览器总是联结在网络上，这也就意味着用户在断开联结时将无法访问应用程序。由于应用程序的逻辑部分和状态位于服务器上，因此瘦客户端会频繁的向服务器发回数据和处理请求，而浏览器则必须等待响应到达后用户才能够继续操作，因而导致瘦客户端的响应速度通常要比胖客户端慢的多。
2.3. 本系统的解决方案
对于当前电子公文交换系统中存在的问题以及当前技术发展的应用，迫切需要一种能够满足当前电子公文交换的需要并跟得上政府信息化发展步伐的新的电子公文交换系统。
新系统首先要解决的问题就是要建立一套完整的电子公文交换和办文的流程，在系统分析中我们有详细的介绍。
其次要解决的问题就是向下行文问题，向下行文问题是深圳市现有电子公文交换不能推广的首要问题。在系的系统中我们才用了北大方正的Apabi电子公章服务器和红头设计技术，使得在向下行文时不用担心公文因版式问题而使得公文无效。
在新系统中我们将根据当前技术发展的趋势才用了C/S和B/S相结合的技术，在核心交换我们采用C/S架构，而在客户端我们才用智能客户服务端技术。
3.2.1. 公文交换流程
通过对现有市政府现有公文交换和办文模式的调研，我们得到其基本的流程如下：
普通发文：公文草拟套红（A单位）－＞领导盖章（A单位）－＞发送（A单位）－＞签收（Ｂ单位）
转办发文：公文草拟套红（A单位）－＞领导盖章（A单位）－＞发送（A单位）－＞签收（Ｂ单位）－＞处理（Ｂ单位）－＞返回处理意见（Ａ单位）
从上述流程中我们可以看到，公文在发出去后没有一种有效的跟踪机制，也就是说无法确切的知道发送的公文是否真的被对方收到，如果因为网络等其他原因造成收文方没有收到，而此时在发文方显示的是状态是已经发送。对于收文方，在执行了签收和回复后此时显示的状态是已经签收和已经回复，而一旦因为网络等原因造成签收和回复发送失败，则发文方式收不到回执和回复。这样就造成了双方不必要的矛盾。对于转办来文，收文方可能会收到转办的处理意见即处理表，现有系统无法提供打印处理表功能，只能够由人工根据处理意见在文字处理软件中进行编排打印。为了能够简化这一步操作我们设计了打印处理表环节，在此环节，收文方能够根据处理意见自动生成处理表，并提供打印功能。对于携带有“任务”的公文在原有系统中无法处理，因此在新系统中将添加专门的任务模块。
为了解决现有系统的问题我们采用了如下的电子公文交换流程：
(1) 公文草拟：公文草拟即公文登记：公文只有在草拟完毕的情况下才可以进行盖章， 在盖章之前随时都能够修改公文基本信息及其内容，为了防止公文在传输过程中被篡改我们采用了北大方正的Apabi产品作为公文正文的载体。公文只有填写了国家规范的基本要素以及正文（套红可以选择）才能够草拟完毕进入盖章阶段。并不是所有的公文都需要盖章，因此可以根据需要直接进入发送环节。
(2) 电子签章：电子签章也就是盖章，对于一些需要盖章才能够发送的公文在此环节领导可以进行盖章，如果领导对于此待盖章的公文不满意，可以退回，公文发文管理人员对公文进行修改后再次转到盖章环节。对于需要盖章的公文只有领导盖章后才能够进入发送环节。电子签章我们采用的是北大方正的电子公章服务器进行签章。
(3) 发送公文和发文跟踪：只有盖了章的和无需盖章的公文才能进入发送环节。在发送环节可能遇到发送失败和漏发的情况，因此必须支持重发和补发操作。对于已经发送的公文，如果发现发错了，还必须支持废文操作。凡是发送了的公文，它不一定就能够发送成功，因此必须让用户知道该公文发送的各个单位是否发送成功，在此我们需要一种消息提醒机制即发文跟踪，当所有单位都成功发送后，发送方等待对方的签收和回复。
1.1.1. 业务背景
为了提高政府机关公文处理效率和质量，避免信息孤岛的再次出现，提高业务的关联性，整合系统资源，简化系统操作的复杂性，加强系统的可维护性和完整性，必须对现有的深圳市政府办公厅网上办公系统进行改造。
为了适应新的公文交换平台标准以及各用户单位对电子公文交换的更高要求，运行近四年的深圳市党政机关电子公文交换系统的平台部分架构和系统已经不能完全满足新形势的改革发展需求，必须对现行系统进行改造。通过对现有电子公文交换系统的改造，制定统一规范的标准数据交换接口，以满足当前乃至今后市政府各部门的业务需求，整合交换系统各接入节点的资源，实现信息互联互通，提高工作效率，使其真正成为一个覆盖全市的分布式数据交换平台。
该电子公文交换系统要求包括三个子系统：办公厅OA，核心交换，智能客户端。其中办公厅OA负责市政府办公厅的电子公文交换和办文；核心交换负责电子公文的传输；智能客户端负责全市各个职能局之间、各职能局和办公厅之间以及各职能局和其下属单位的电子公文交换和办文。同时监察局和督察局可以通过智能客户端对各单位的办文状态进行跟踪并进行有效的催督办。
新改造后的系统必须采用多种新的技术标准规范，针对电子政务新形势下的需求增加新的功能，采用统一的接口规范实现电子公文交换系统数据的统一接入，无缝联结。新系统应该能够全面完善现有系统的功能，并在保持现有风格和功能的延续性的基础上，建立一个更先进和完善的电子公文交换和办文平台，进一步增强系统的功能以适应政府办公和业务信息化的发展要求，以及获得在开放式架构基础上与其他政府部门业务信息系统的紧密结合能力，进一步提高办文效率，增强政府部门之间的协作能力。新系统的主要目标是提高机关公文处理效率和质量，不再出现信息孤岛，提高业务的关联性和协同性，整和办公信息资源，简化业务处理功能操作，提高可视化操作程度，加强系统的可维护性和完整性。
think58好，好think58 [资料来源：http://www.THINK58.com]
1.1.2. 智能客户端
在二十世纪九十年代中期，Microsoft(R)Window(R)操作系统开发的胖客户端应用程序的数量急剧增长。胖客户端的目的是为了减少服务器的负担，充分利用本地硬件资源以及客户端操作系统平台的功能。尽管胖客户端技术通常提供了高质量，快速响应的用户体验，减少了服务器的负担，但是它们却非常难于部署和维护，同时系统的兼容性问题也日益凸突。这些问题使得应用程序变得非常的脆弱。
Internet的出现提供了传统胖客户端模型的替代模型，它解决了许多与应用程序部署和维护相关联的问题，给基于浏览器的瘦客户端应用程序是在中央web服务器上部署和更新的，因此它消除了将应用程序的任何部分显示部署到客户计算机并加以管理的必要性。瘦客户端的出现使得应用程序的简单部署和统一维护变成了现实。但是 瘦客户端是基于web的，因此它要求客户的浏览器总是联结在网络上，这也就意味着用户在断开联结时将无法访问应用程序。由于应用程序的逻辑部分和状态位于服务器上，因此瘦客户端会频繁的向服务器发回数据和处理请求，而浏览器则必须等待响应到达后用户才能够继续操作，因而导致瘦客户端的响应速度通常要比胖客户端慢的多。
2.3. 本系统的解决方案
对于当前电子公文交换系统中存在的问题以及当前技术发展的应用，迫切需要一种能够满足当前电子公文交换的需要并跟得上政府信息化发展步伐的新的电子公文交换系统。
本文来自think58 [资料来源：THINK58.com]
新系统首先要解决的问题就是要建立一套完整的电子公文交换和办文的流程，在系统分析中我们有详细的介绍。
其次要解决的问题就是向下行文问题，向下行文问题是深圳市现有电子公文交换不能推广的首要问题。在系的系统中我们才用了北大方正的Apabi电子公章服务器和红头设计技术，使得在向下行文时不用担心公文因版式问题而使得公文无效。
在新系统中我们将根据当前技术发展的趋势才用了C/S和B/S相结合的技术，在核心交换我们采用C/S架构，而在客户端我们才用智能客户服务端技术。
3.2.1. 公文交换流程
通过对现有市政府现有公文交换和办文模式的调研，我们得到其基本的流程如下：
普通发文：公文草拟套红（A单位）－＞领导盖章（A单位）－＞发送（A单位）－＞签收（Ｂ单位）
转办发文：公文草拟套红（A单位）－＞领导盖章（A单位）－＞发送（A单位）－＞签收（Ｂ单位）－＞处理（Ｂ单位）－＞返回处理意见（Ａ单位）
从上述流程中我们可以看到，公文在发出去后没有一种有效的跟踪机制，也就是说无法确切的知道发送的公文是否真的被对方收到，如果因为网络等其他原因造成收文方没有收到，而此时在发文方显示的是状态是已经发送。对于收文方，在执行了签收和回复后此时显示的状态是已经签收和已经回复，而一旦因为网络等原因造成签收和回复发送失败，则发文方式收不到回执和回复。这样就造成了双方不必要的矛盾。对于转办来文，收文方可能会收到转办的处理意见即处理表，现有系统无法提供打印处理表功能，只能够由人工根据处理意见在文字处理软件中进行编排打印。为了能够简化这一步操作我们设计了打印处理表环节，在此环节，收文方能够根据处理意见自动生成处理表，并提供打印功能。对于携带有“任务”的公文在原有系统中无法处理，因此在新系统中将添加专门的任务模块。
think58.com [来源：http://www.think58.com]
为了解决现有系统的问题我们采用了如下的电子公文交换流程：
(1) 公文草拟：公文草拟即公文登记：公文只有在草拟完毕的情况下才可以进行盖章， 在盖章之前随时都能够修改公文基本信息及其内容，为了防止公文在传输过程中被篡改我们采用了北大方正的Apabi产品作为公文正文的载体。公文只有填写了国家规范的基本要素以及正文（套红可以选择）才能够草拟完毕进入盖章阶段。并不是所有的公文都需要盖章，因此可以根据需要直接进入发送环节。
(2) 电子签章：电子签章也就是盖章，对于一些需要盖章才能够发送的公文在此环节领导可以进行盖章，如果领导对于此待盖章的公文不满意，可以退回，公文发文管理人员对公文进行修改后再次转到盖章环节。对于需要盖章的公文只有领导盖章后才能够进入发送环节。电子签章我们采用的是北大方正的电子公章服务器进行签章。
(3) 发送公文和发文跟踪：只有盖了章的和无需盖章的公文才能进入发送环节。在发送环节可能遇到发送失败和漏发的情况，因此必须支持重发和补发操作。对于已经发送的公文，如果发现发错了，还必须支持废文操作。凡是发送了的公文，它不一定就能够发送成功，因此必须让用户知道该公文发送的各个单位是否发送成功，在此我们需要一种消息提醒机制即发文跟踪，当所有单位都成功发送后，发送方等待对方的签收和回复。
think58好，好think58 [资料来源：http://www.THINK58.com]