CN104008436A - 一种内容管理集成方法和系统 - Google Patents

Abstract

本发明提供了一种内容管理集成方法和系统，其中，所述方法包括：将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；所述服务端生成与所述业务对应的文件包的文件包ID；所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；所述客户端通过所述文件包ID从服务端获取文件包信息并显示。本发明以文件包作为与业务系统交互的最小单位，能够满足企业的业务需求。

Description

一种内容管理集成方法和系统

技术领域

本发明涉及业务支撑领域，尤其涉及一种内容管理集成方法和系统。

背景技术

在公司日常管理运营过程中，业务系统在运行过程中产生和处理的数据可以分为两类：结构化的数据和非结构化数据。非结构化数据的内容可能是文字、图形或多媒体文件，其在系统中存在的形式为文档附件，而在文档附件管理方面，各个业务系统分别使用自有的、独立的方式完成对附件的存取和利用。

一般情况下，IT部门在建设业务系统时会开发专门的文档附件管理模块，最常使用的方式是在服务器文件系统或FTP服务器中存放文件，而通过数据库和专门的功能模块来控制文档附件的存取权限。

当企业的业务规模越来越大，业务系统中的文档附件也越来越多，交互也愈趋频繁。在这种背景下，很多企业会部署文档管理平台对各类业务文档进行集中管理。EMC的Documentum作为企业内容管理平台的主流产品之一，被很多企业用作集中的文档管理平台。

为了对分散在各个部门、各个业务系统的中的文档进行采集、分类和发布利用，改变原有的随意管理的习惯，实现集中存放和管理，有必要将Documentum与业务系统进行集成，而不仅仅是把Documentum当作一个独立的文档库使用。

目前大部分企业对于Documentum的集成方式为三层架构，如图1所示，在业务系统上部署DFC(Documentum Foundation Classes)和WDK（WebDevelopment Kit）接口包，并在业务应用中调用内容管理API实现与Documentum集成。

使用Documentum进行文档集中存储和管理，在实现了与各业务系统集成后，具有节约存储空间、便于跨系统文档附件交互等优点，但在文档附件交互方面，Documentum集成方式以单个文档为关注对象，但企业的业务模式更多的时候是以一个事务为交互单位。譬如企业内部的公文，正文和附件组合才是一个公文系统的最小交互单位。所以这种单纯以文档为交互单位的技术方案从根本上来讲无法满足企业的业务需求。

发明内容

本发明的目的是提供一种内容管理集成方法和系统，以文件包作为与业务系统交互的最小单位，满足企业的业务需求。

为了实现上述目的，本发明实施例提供了一种内容管理集成方法，所述方法包括：

将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

所述服务端生成与所述业务对应的文件包的文件包ID；

所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成方法，其中，所述方法还包括：

所述客户端获取用户标识；

所述服务端对所述用户标识是否有效进行验证，获得验证结果；

所述客户端通过所述文件包ID从服务端获取文件包信息并显示具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成方法，其中，所述方法还包括：

根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

上述的内容管理集成方法，其中，所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。

为了实现上述目的，本发明实施例还提供了一种内容管理集成系统，所述系统包括：

存储模块，用于将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

文件包ID生成模块，用于所述服务端生成与所述业务对应的文件包的文件包ID；

交互模块，用于所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

文件包信息获取模块，用于所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成系统，其中，所述系统还包括：

用户标识获取模块，用于所述客户端获取用户标识；

验证模块，用于所述服务端对所述用户标识是否有效进行验证，获得验证结果；

所述文件包信息获取模块具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成系统，其中，所述系统还包括：

下载模块，用于根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

上述的内容管理集成系统，其中，所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。

本发明实施例具有以下有益效果中的至少一项：

本发明实施例，实现了以文件包作为与业务系统交互的最小单位，满足了企业的业务需求；

本发明实施例，进一步地，将内容管理集成系统分为四个部分，提供统一的、支持多种内容管理集成系统接口的前端WEB部件，企业业务系统集成该前端WEB部件即可实现与Documentum的交互，将标准的三层集成模式升级为四层集成模型，包括：业务系统、WEB部件展现、WEB部件本地组件库、文档管理系统，其中文档管理系统优选Documentum系统，从而降低了业务系统与文档管理系统的耦合程度，提高了系统敏捷性；

本发明实施例，WEB部件对Documentum的接口进行了抽象和统一，对外提供以文件包为最小事务对象的集成接口，从而大幅度降低集成开发的工作量和难度；

本发明实施例，采用二进制流方式实现文档上下传，提高传输性能；

本发明实施例，除支持访问Documentum文档管理系统外，WEB部件还支持客户端本地文件操作的交互模式，多种方式的文件访问接口全面满足业务系统的集成需求；

本发明实施例，WEB部件提供友好和可定制的用户界面，用户体验好；

本发明实施例，实现基于HTTP协议的客户端组件自动更新，易于维护。

附图说明

图1为文档管理系统Documentum与业务系统集成的结构示意图；

图2为本发明实施例中内容管理集成方法的流程示意图；

图3为本发明实施例中的四层集成结构示意图；

图4为本发明实施例中的WEB部件结构示意图；

图5为本发明实施例中公文系统中的文件包示意图；

图6为本发明实施例中审计系统中的文件包示意图；

图7为文档上传下传原理图；

图8为本发明实施例中多业务系统、WEB部件和文档管理平台的系统架构图；

图9为本发明实施例中多业务系统、WEB部件和文档管理平台的系统数据流转示意图；

图10为本发明实施例中文件包交互流程示意图；

图11为本发明实施例中业务系统与文档管理系统Documentum的集成流程图；

图12为本发明实施例中内容管理集成系统的结构示意图。

具体实施方式

为使本发明实施例要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。

本发明实施例提供了一种内容管理集成方法，所述方法如图2所示，包括：

步骤21，将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

步骤22，所述服务端生成与所述业务对应的文件包的文件包ID；

步骤23，所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

步骤24，所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

在本发明实施例中，服务端将文档以文件包的方式进行存储，这里的文件包包括正文文件夹和附件文件夹，并为每个文件包生成与具体业务对应的文件包ID。当客户端请求第一业务的文档时，通过与服务端交互获得与第一业务对应的文件包的文件包ID，通过文件包ID来获取文件包信息。

通过上述过程，实现了以文件包作为与业务系统交互的最小单位，满足了企业的业务需求。

在进行文档管理时，一般需要对用户身份进行验证，有权限的用户才允许获取文档信息，因此，上述的内容管理集成方法，优选地，还包括：

所述客户端获取用户标识；

所述服务端对所述用户标识是否有效进行验证，获得验证结果；

步骤24具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

通过用户端获取用户身份标识，并通过服务端对所述标识进行验证，验证结果指示标识有效时，才允许客户端通过文件包ID从服务端获取文件包信息并显示，提高了内容管理集成系统的安全性。

当客户端获取文件包信息并显示给用户后，所述方法还包括：

根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端，此时用户可以通过客户端对下载的文件进行修改更新等操作。

针对现有的文档管理系统与业务系统三层架构的集成方式，本发明实施例提出了一种四层架构，如图3所示。所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。

其中，文档管理系统优选地使用Documentum系统。

业务系统与Documentum系统的文档交互主要由客户端的WEB部件来处理，业务系统无需部署WDK/DFC接口包，与Documentum交互关系也变得简单。

内容管理集成方法按照交互顺序依次为：业务系统、IE浏览器及WEB部件、本地组件库、Documentum，具体步骤为：

步骤一，用户访问业务系统时，首先通过标准的JavaScript进行WEB部件的展现，与业务系统进行交互；

步骤二，客户端从业务系统中获取文件包在Documentum中的标识即文件包ID，不同业务系统可以根据ExtJs的框架进行界面风格、部件功能的自定义设计；

步骤三，WEB部件通过微软的OCX技术调用本地组件库文件，实现页面功能与本地组件库功能映射，其中系统的核心逻辑实现功能都在本地组件库中进行封装，按照功能组件库可以分为身份认证组件、文件上传下载组件、Documentum交互组件和本地文档操作组件；

步骤四，WEB部件本地组件库传递用户标识到Documentum，请求登录；

步骤五，Documentum与业务系统交互，验证用户标识是否有效；

步骤六，用户标识有效时，文件传输组件通过TCP的方式直接与Documentum库进行文件交互，本地交互组件封装了对本地文件的操作，比如Word文档修改痕迹保留、依据标签进行格式标准化等操作，在完成本地文档操作后，仍然通过文件传输组件完成文档上传；

步骤七，WEB部件本地组件库能够执行文档的本地修改更新等操作。

下面就本发明实施例提出的四层架构的设计进行详细说明。

首先，本发明实施例基于AJAX(Asynchronous JavaScript and XML)技术的ExtJS框架以及微软COM(Component Object Model)技术开发一个统一的前端WEB部件（含本地组件库），如图4所示，WEB部件自下而上分为三层，底层通过API实现与文档管理系统的数据交互，中间是COM组件层，主要完成身份认证、文件传输、Documentum交互、本地文件交互等功能，上层则通过JavaScript来进行WEB展现和交互。

此WEB部件采用完全组件化的设计思想，提供友好的用户交互界面，可扩展性强。业务系统通过JavaScript引入此WEB部件，一旦业务系统完成部件的展现，所有与文档管理系统交互等部件内部功能及操作都由WEB部件自身完成，而无需业务系统进行再次开发，降低了业务系统与文档管理系统的耦合程度，提高了系统敏捷性。

其次，考虑到企业业务系统的复杂性，以文件包作为与业务系统交互的最小交互对象。所有业务系统都以文件包与WEB部件进行交互，业务系统只需要进行文件包ID的记录。文件包在各个业务系统的不同含义由各个业务系统进行诠释，可以解释为简单的文档集合，也可以解释为包含复杂的层次结构的业务对象。举例说明如下：

<例子1>

对于公文系统，文件包就是有一个正文文件夹和一个附件文件夹组成，如图5所示。

<例子2>

对于一个审计项目，一个文件包就包括送审文档和审计文档，其中送审文档可能会包含比较复杂的结构，如图6所示。

第三，WEB部件对Documentum文档管理平台API进行封装，以平台对应的协议直接与文档管理系统进行数据交互，采用直接二进制流的方式实现文件上下传，省略了HTTP编码转换和临时文件交换等步骤，如图7所示。而且文档管理服务器可对常用文件自动添加缓存处理，减少磁盘操作。这样就实现了用户客户端和文档管理系统服务器之间点对点的高性能传输。

第四，WEB部件基于微软的COM(Component Object Model)组件技术实现本地文件及远端文件交互，用户可以通过Windows对话框进行文件的批量选择、文件夹的选择；可以双击组件中的文件进行服务端文件的在线编辑和保存；可以批量进行服务端文件的改名下载；可以通过Word的标签进行文件套头等复杂操作。该实现方法可以适应企业用户的使用习惯，提供良好的交互友好性。

第五，WEB部件基于ExtJs框架实现UI界面，业务系统可以使用标准的界面，也可以根据需要定制开发。

第六，为了方便客户端WEB部件的部署和升级，减轻企业IT部门的运维工作量，本发明实施例实现了基于HTTP协议的服务端分发的组件自动更新。这样既保持用户使用COM组件技术的交互友好性，也解决了原先C/S架构的一些维护部署问题。

基于上述四层集成模型，企业各个业务系统可以快速与Documentum集成，从而充分利用文档集中管理具有的节约存储和容易交互的优点。上述多业务系统、WEB部件和文档管理平台的系统架构图和数据流转示意图分别见图8和图9所示。

下面举例说明上述四层架构的交互过程。

<例子3>

如图10所示。

首先是文件包的创建过程，包括：

在业务系统进行业务事务创建时，业务系统会对文件包进行初始结构设定，生成一个唯一的文件包ID，并记录此文件包ID与业务系统的关联；

同时，客户端WEB部件会在文档管理平台中创建相关目录；

当用户在业务系统WEB页面上选择上传文件时，WEB部件就会在文档管理平台服务器上完成文件的上传。

其次，文件包的流转及展现过程，包括：

业务系统流转过程中需要展现信息时，会通过关联的文件包ID调用WEB部件，WEB部件获得文件包ID后，进行文件包初始结构的显示，如公文的文件包就会显示为正文和附件。

另外，文件包中文件的阅读、修改过程，包括：

当用户双击文档时，WEB部件就会自动把文档管理平台中相应文档的下载到本地临时目录，同时调用本机关联应用程序打开，当用户完成文档内容修改后，进行保存提交时，WEB部件会自动把修改后文档上传到文档管理平台。

本发明实施例中，业务系统与Documentum集成的具体实现流程如图11所示，包括：

Documentum初始化，主要工作为文档管理库规划和文档系统架构设计和部署，业务系统接入准备等等，此步骤为一次性的初始化工作，属于准备工作；

业务系统申请接入，由业务系统项目经理完成，根据标准化的模版，估算业务系统的存储空间需求、系统压力需求，并说明与其它业务系统的交互关系；

Documentum资源分配，Documentum系统管理员根据上述基础数据，确定业务系统的接入方式，并分配用户、存储空间和目录等系统资源；

业务系统集成WEB部件，业务系统开发人员依据接口规范引用WEB部件，根据Documentum系统管理员提供的信息完成配置。

WEB部件集成完成后，业务系统就实现了与Documentum的集成。

以下以档案管理系统为例说明业务系统如何接入Documentum。

<例子4>

首先，档案系统项目经理申请接入Documentum，估算所需的存储空间和压力需求，并描述其与公文系统、合同管理系统的交互关系；

其次，Documentum系统管理员根据档案系统管理员提交的需求进行评估，确定其与公文系统、合同管理系统使用同一个库下的不同目录，在Documentum中分配应用系统标记为AMS，存储目录为/AMS，访问用户为AMS，在/AMS目录上设置访问权限集为AMS用户拥有所有权限，其它用户为NONE；

再次，档案系统开发人员引用WEB部件的静态资源（若干JavaScript），并在WEB部件的配置文件中指定本系统标记为AMS，访问用户为AMS，由于WEB部件集成了文件传输、本地文档操作等组件，此步骤实现简单、易于集成。

最后，在用户使用档案系统时，在引用WEB部件的页面就会显示可交互的WEB部件区域，通过WEB部件上的菜单或按钮就可以进行与Documentum库的交互和访问以及本地文件的访问，实现了WEB部件和本地组件库的自动部署分发，如果用户是第一次使用，页面会自动提示用户需要安装WEB部件。

综上，本发明实施例中的文档管理系统Documentum与业务系统集成架构，与现有技术中的架构相比具有耦合度低、集成度低、集成工作量小、访问性能高、交互界面体验友好以及支持客户端本地文档处理等优点，如表1所示。

表1现有技术与本发明实施例进行文档管理系统与业务系统集成的比对

本发明实施例还提供了一种内容管理集成系统，如图12所示，所述系统包括：

存储模块，用于将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

文件包ID生成模块，用于所述服务端生成与所述业务对应的文件包的文件包ID；

交互模块，用于所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

文件包信息获取模块，用于所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成系统，其中，所述系统还包括：

用户标识获取模块，用于所述客户端获取用户标识；

验证模块，用于所述服务端对所述用户标识是否有效进行验证，获得验证结果；

所述文件包信息获取模块具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

上述的内容管理集成系统，其中，所述系统还包括：

下载模块，用于根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

上述的内容管理集成系统，其中，所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。

本发明实施例提供的内容管理集成方法和系统，将内容管理集成系统的客户端发送的业务文档以正文文件夹和附件文件夹组成的文件包的方式，存储在内容管理集成系统的服务端，服务端记录文件包与业务的关联关系，并为每个文件包生成与所述业务对应的文件包的文件包ID。当客户端需要请求第一业务的文档时，先与服务端交互获得与第一业务对应的文件包的文件包ID，客户端再根据文件包ID从服务端获取文件包信息并显示展现给用户。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (8)

1.一种内容管理集成方法，其特征在于，所述方法包括：

将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

所述服务端生成与所述业务对应的文件包的文件包ID；

所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

2.如权利要求1所述的内容管理集成方法，其特征在于，所述方法还包括：

所述客户端获取用户标识；

所述服务端对所述用户标识是否有效进行验证，获得验证结果；

所述客户端通过所述文件包ID从服务端获取文件包信息并显示具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

3.如权利要求1所述的内容管理集成方法，其特征在于，所述方法还包括：

根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

4.如权利要求1至3任一项所述的内容管理集成方法，其特征在于，所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。

5.一种内容管理集成系统，其特征在于，所述系统包括：

存储模块，用于将内容管理集成系统的客户端发送的业务文档以文件包的方式存储在内容管理集成系统的服务端；

文件包ID生成模块，用于所述服务端生成与所述业务对应的文件包的文件包ID；

交互模块，用于所述客户端请求第一业务的文档时，与服务端交互获得与第一业务对应的文件包的文件包ID；

文件包信息获取模块，用于所述客户端通过所述文件包ID从服务端获取文件包信息并显示。

6.如权利要求5所述的内容管理集成系统，其特征在于，所述系统还包括：

用户标识获取模块，用于所述客户端获取用户标识；

验证模块，用于所述服务端对所述用户标识是否有效进行验证，获得验证结果；

所述文件包信息获取模块具体为当所述验证结果指示所述用户标识有效时，客户端通过所述文件包ID从服务端获取文件包信息并显示。

7.如权利要求5所述的内容管理集成系统，其特征在于，所述系统还包括：

下载模块，用于根据用户在所述文件包中选择的第一文件，从所述服务端下载所述第一文件到客户端。

8.如权利要求5至7任一项所述的内容管理集成系统，其特征在于，所述服务端包括业务系统和文档管理系统；所述客户端包括web部件展现和web本地组件库。