FileNet P8 Content Engine 的分布式部署架构

摘抄笔记：http://www.ibm.com/developerworks/cn/data/library/techarticle/dm-1307wanghaining/

前言

对于集团公司，企业内容的集中管理是目前的一个趋势，在这边文章里，我们讲解某集团银行如何通过 FileNet 实现企业内容的统一管理。

业务场景描述

某集团银行是我国最大的投资银行之一，下属五十几家分行，分布在全国各地。在日常业务中，每天会产生大量的业务凭证，包括信贷合同、储蓄凭单、支票、会计档案等。如何对这些凭证进行统一集中管理，有效的分类、保存、归档以及查询，是该集团银行面临的一个比较棘手的问题。

凭证电子化管理可以有效解决这个问题，所谓凭证电子化管理是指将纸面凭证扫描转化为电子影像文件，并实现电子影像文件的自动分类、存储、调阅、查询以及归档。

利用 IBM 的 Datacap，总行以及分行可以快速有效的完成纸面凭证到电子影像文件的自动识别、转换以及分类，但是各个分行要将每天产生的这些大量电子影像文件发送到总行做统一集中管理面临下面这些问题：

由于分行到总行的网络带宽的限制，在业务时间把电子影像文件上传到总行比较慢；
电子影像文件上传占用带宽比较大，严重影响了其它业务的操作；
由于分行对影像文件没有缓存，分行对已经上传的影像文件的查阅比较慢。

回页首

解决方案描述

这样的业务场景在集团公司非常常见，内容的集中管理也是未来企业内容管理的一个趋势。目前，VPN 的搭建也很昂贵，网络带宽是实现非结构化内容集中管理的一个瓶颈，在我们的这个客户系统中，总行和分行的网络带宽只有 10M，10M 带宽是给分行所有的应用系统使用，电子影像文件集中管理系统占用的带宽也就 3M，有效带宽就更少大约为 1.8M，每个影像大概有 2M，每个分行每天业务会产生 5000 多个影像，差不多 10G 的数据。

考虑到网络带宽这个瓶颈，为了不在业务时间占用带宽，我们的解决方案是分行产生的影像文件首先临时保存在分行的系统中，也就是把分行作为一个存放影像文件的缓存（分行缓存）。等到非业务时间，错峰使用网络，把各个分行的影像文件迁移到总行做集中管理。

利用 FileNet P8 Content Engine 的分布式部署可以有效实现上面这个解决方案，下面我们来了解一下 FileNet 的相关知识。

FileNet P8 介绍

FileNet P8 是可靠的、可扩展的、高可用性的企业平台，使你能够捕获、存储、管理、保护和处理信息，提高操作效率，降低总体拥有成本。

Content Engine 是 FileNet P8 的一个核心模块，提供企业内容和客户自定义业务对象的存储管理服务，管理的企业内容和对象包括影像、电子文档、音频、视频、报表、网络内容、记录、文件夹、预存的检索、工作流定义、发布模板、登录模板等。在这里，我们重点介绍内容存储的两个概念，File storage area 和 Content cache area。FileNet 的相关术语，请参照下面表 1。在本文里面，我们把 FileNet Content Engine 简称为 CE ，File storage area 是 CE 用来存储内容的具体地方，支持 UNIX NFS，Windows DFS,GPFS 和 NTFS 文件系统，而 Content cache area 里面主要存储了最近访问的文档，和浏览器里面的缓存作用很像，当 CE 访问一个文档内容的时候，CE 首先尝试从 Content cache area 里面查找该内容，如果没有的话，再从 File storage area 里面查找，把内容返回给 Client 端后，CE 再把内容拷贝到 Content cache area，下次访问的时候就直接从 Content cache area 访问了。一般来说，Content cache area 创建在分行的系统文件里，便于分行直接访问提高访问文档内容的性能。

表 1. FileNet 术语表

术语	解释说明
Content Engine	内容引擎，FileNet 的一个核心组件，用来管理整个企业的工作对象、自定义对象和文件。
Object Store	是一个数据库的贮藏室，用来存储文档、文件夹、自定义的业务对象以及这些对象的元数据信息。
File Storage Area	文件存储区域，是内容引擎具体存放非结构化文件的地方，对于结构化文件被内容引擎存储在数据库里面。
Content Cache Area	文件缓存区域，CE 首先从这个地方获取文件内容，如果没有的话，再从文件存储区域获取。
Request forwarding	请求转发，一个 CE 服务器可以把请求转发给另外一个 CE 服务器，以提高性能。
Migration Application	自己写的一个文档内容迁移的小应用，用来把文档内容从一个文件存储区域迁移到另外一个文件存储区域。
Property	属性，根据业务需要，自定义的元数据。
Class	类，包含了自定义的元数据定义。是用来创建文档的模板。
Document	文档，是类的实例，包含了具体元数据的值和附加的非结构化文件。

部署架构设计

此解决方案的核心是先把影像文件缓存在分行，然后利用网络错峰时间把分行的影像文件迁移到总行做集中管理，所以在总行要创建一个 File storage area 做影像文件的集中存储管理，在各个分行我们要创建一个 File storage area 做影像文件的临时缓存，同时在分行也要创建一个 Content cache area，这样当分行 File storage area 的影像文件被迁移到总行后，还可以从本地的 Content cache area 访问。接下来的问题是如何把影像文件从分行的 File storage area 迁移到总行的 File storage area，CE 的 com.filenet.api.core.Document 类有一个 moveContent(StorageArea) 方法，通过在 Document 对象上调用 moveContent 方法，就可以把分行的影像文件迁移到总行的 File storage area 上。

根据上面的描述，我们设计的分布式部署架构如下图 1，下面我们详细讲解一下这个架构图。

数据库和 LDAP 都安装在总行，在总行也创建了一个 CE File storage area，用来集中存储 50 个分行的影像文件。在每一个分行，都创建了一个 File storage area 和 Content cache area，分行的 File storage area 用于临时存储影像文件，分行把影像文件上传后，以后再访问的时候直接从分行的 Content cache area 来访问。分行影像文件上传流程如下：

分行扫描影像后，Client 端直接访问分行的 CE，发出电子影像文件上传请求。
分行的 CE 处理这个请求，把影像文件分别保存到分行的 File storage area 和 Content cache area。
然后分行的 CE 通过请求转发（Request forwarding），把影像文件对应属性数据信息保存请求发送给总行的 CE。
总行的 CE 处理请求，把属性数据信息保存在数据库里面，然后把操作结果返回给分行的 CE。
分行的 CE 把操作结果返回给调用的 Client 端。
然后定时调用 Migration Application 应用程序，把影像文件从分行的 File storage area 迁移到总行的 File storage area。

图 1. 分布式部署架构图

各个分行的影像文件被上传到总行做集中管理后，总行直接从本地的 File storage area 访问电子影像文件，访问速度很快；而分行在本地有 Content cache area，分行从 Content cache area 访问电子影像文件也很快。

文档迁移 (Migration Application) 应用程序编写比较简单，主要调用上文描述的 moveContent 方法，具体实现如下面代码片段，可以通过 EJB timer 或者定义一个作业来按时运行这个程序 , 比如说在每天夜里 12 点非业务时间运行。

清单 1. 文档迁移应用的代码片段

 public static void migrateStorageArea(ObjectStore objectstore,StorageArea sourceStorage,

 StorageArea targetStorage){

		 System.out.println("===Migrate content from " + sourceStorage.

		 get_DisplayName() + " to " + targetStorage.get_DisplayName() + "==="); 

		 //each transaction will migrate 1000 docs' content

		 int batchSize=1000;

		 int temp=0; 

		 IndependentObjectSet docSet=null;

		 Document doc=null; 

		 //set up RetrievingBatch to migrate content

		 RetrievingBatch rb = RetrievingBatch.createRetrievingBatchInstance

		 (objectstore.get_Domain()); 

		 Integer pageSize = new Integer(1000);

	    PropertyFilter filter = new PropertyFilter();

	    int filterLevel = 1;

	    filter.setMaxRecursion(filterLevel);

	    filter.addIncludeType(new FilterElement(null, null, null,"StorageArea",

            null));

	    filter.addIncludeType(new FilterElement(null, null, null,"DocumentTitle",

		 null));

	    Boolean continuable = new Boolean(true);

		 try{

			 //search all docs stored in sourceStorage

			 String queryString="select this,StorageArea from document where

		 StorageArea=Object('" + sourceStorage.get_Id().toString() + "')";

			 System.out.println("create search scope");

			 SearchScope search = new SearchScope(objectstore);

			 System.out.println("create search SQL by query string

		 <" + queryString + ">");

			 SearchSQL searchSQL = new SearchSQL(queryString);

			 System.out.println("execute search");

			 docSet=search.fetchObjects

		 (searchSQL, pageSize, filter, continuable);

			 Iterator iter=docSet.iterator();

			 while(iter.hasNext()){

				 doc=(Document) iter.next();

				 System.out.println("get doc " + doc.getProperties().

				 getStringValue("DocumentTitle"));

				 temp++;

                                    doc.moveContent(targetStorage);

				 rb.add(doc, null);

				 if(temp==batchSize){

					 //if there are 1000 docs, migrate them

					 System.out.println("submit batch " + batchSize);

					 rb.retrieveBatch();

					 temp=0;

				 }

			 } 

			 rb.retrieveBatch();

			 System.out.println("===Migration is done===");

		 }catch(EngineRuntimeException erEx){

			 //just in case there is no doc needed migration

			 if(erEx.getExceptionCode()==ExceptionCode.API_EMPTY_BATCH){

				 System.out.println

				 ("There are no objects in this batch to process");

			 }else{

				 System.out.println

				 ("Unexpected error occurred when migrating content");

				 throw new RuntimeException(erEx);

			 }

		 }catch(Exception ex){

			 System.out.println("Error occurred when migrating content");

			 throw new RuntimeException(ex);

		 }

	 }

分布式环境安装配置

按照上面的分布式部署架构图，接下来我们详细讲解分布式部署环境的详细搭建。在我们的这个例子里，某集团银行用的是 WebSphere ND，FileNet CE 支持分布式部署，只需要把 FileNet CE 安装在总行，就可以把它部署到所有的分行，FileNet CE 的分布式部署非常便于升级和维护。

在总行，我们需要安装 WebSphere ND deployment manager 和一个 node，然后安装 FileNet CE。

在分行，我们只需要安装 WebSphere ND node 或者 WebSphere Application Server，然后用 WebSphere ND deployment manager 来管理所有分行的 WebSphere Application Server。

在 WebSphere 和 FileNet CE 安装完成后，我们就可以进行配置。下面是详细安装流程。

WebSphere ND 的安装

在总行，安装 WebSphere ND deployment manager 和一个 node，运行 WebSphere ND 的安装文件，选择安装”Cell(deployment manager and a managed node)”，如下图 2 所示，其它的步骤按默认安装就好。

图 2. 安装 WebSphere deployment manger

安装完 Base WebSphere ND deployment manager7.0 后，还需要安装 FP，CE5.1 支持的最低版本是 WAS 7.0 FP9，在我们的试验中，我们安装的是 FP21，如下图 3：

图 3. 升级 WebSphere deployment manger 到 FP21

Content Engine 的安装

在总行安装完 WebSphere ND deployment manager 和 node 后，我们接着需要安装 Content Engine，Content Engine 的安装和配置是分开来的，安装很简单，所有步骤按照默认安装就好。详细步骤请参照 infocenter。

WebSphere ND Node 的安装

在各个分行，只需要安装 WebSphere ND node（另外一种方法是在分行安装 WebSphere Application Server，然后通过总行的 deployment manager 来统一托管），运行 WebSphere ND 的安装文件，选择安装”Custom”，如下图 4 所示，其它的步骤按默认安装就好。

图 4. 安装 WebSphere ND node

在安装 WebSphere ND node 过程中，需要输入总行 deployment manager 机器名，端口号（默认为 8879）以及安装 deployment manager 的时候指定的用户名和密码，如下图 5：

图 5. 输入总行 WebSphere deployment manger 信息

安装完 Base WebSphere ND node 7.0 后，还需要安装 FP，CE5.1 支持的最低版本是 WAS 7.0 FP9，在我们的试验中，我们安装的是 FP21，如下图 6：

图 6. 升级 WebSphere ND node 到 FP21

配置部署

在总行和分行安装工作完成后，我们要对 WebSphere deployment manager 做一些配置，然后就可以部署 Content Engine。

WebSphere 配置

进入总行 deployment manager 的 Console，打开 Nodes 菜单，可以看到总行的 Node 和所有分行的 Node，在我们的实验中，总行的 Node 是 winceNode01，我们只有一个分行，Node 名称是 wincss1Node01，如下图 7：

图 7. 总行和分行的 Nodes 信息

分行的 Node wincss1Node01 还没有 server 信息，创建一个新的 server，名称为 shanghaiServer1，选择的 Node 为分行的 Node wincss1Node01，如下图 8，增加完成后，我们可以看到总行和分行的 servers 信息，如下图 9。

图 8. 为分行的 Node 增加 Server

图 9. 总行和分行的 Servers 信息

Content Engine 部署

Content Engine 的分布式部署和普通部署比较起来，只有 Deploy Application 这个 task 不一样，在分布式部署里面，Deployment type 选择 Network Deployment，如下图 10。然后选择 Application server node，我们需要分别在总行和各个分行部署 CE，所以需要依次选择总行和各个分行的 node，选择 Application server node 后，Application server name 会自动被筛选出来，根据不同的 node，我们可以给 Content Engine application name 不同的名称，比如在我们的实验中，总行的名称为 FileNetEngineBJ，分行的名称为 FileNetEngineSH。

图 10. 在分行的 Node 上面部署 CE

在总行和各个分行部署 Content Engine 后，打开 Enterprise Applications，可以看到我们部署的 FileNet Engine，如下图 11。部署完成后，需要重启分行和总行的 node，然后再把各个 node 同步一下，如下图 12。

图 11. 总行和分行部署的 FileNet Engine

图 12. 同步总行和分行的 node

部署完 Content Engine 后，打开桌面上 FileNet Content Engine Enterprise Manager，连接到 CE Server，创建两个 StorageArea，一个创建在总部为 BJ_StorageArea，另外一个创建在分行为 SH_StroageArea，如下图 13。然后在分行再创建一个 ContentCacheArea，如下图 14.

图 13. 总行和分行的 StorageArea

图 14. 分行的 ContentCacheArea

回页首

分布式环境的使用

按照上面的配置，即可完成分布式环境的安装和配置，我们接着以信用卡申请为例，讲解这个分布式环境在集团银行总行和分行的使用。

分行的使用

顾客到银行分行柜台提出信用卡申请请求，业务人员首先审核顾客的资料，身份证、工作证明比如工牌或者名片、最近几个月的收入证明，这些材料都是纸质材料，业务人员把这些纸质材料通过 IBM DataCap 自动扫描、分类生成电子影像文件，通过分行的 CE 保存到分行的 StorageArea 和 CacheStorage 中，然后信用卡申请流程被触发。

内容迁移应用程序在非业务时间被定时调用，把顾客提交的电子影像文件从分行的 StorageArea 迁移到总行的 StorageArea。

电子影像文件迁移到总行后，分行的业务人员等待总行审批部门的审核结果，在此期间，分行业务人员可以随时从 CacheStorage 查阅顾客的电子影像文件。

总行的使用

在总行的审批部门，审核人员通过信用卡申请系统看到信用卡审核任务，审核人员从总行的 StorageArea 中查阅从分行提交的电子影像文件，按照一定的规则对顾客的资料进行核查。由于这些文件都已经被迁移到总行，极大提高了审核人员的工作效率。