FileNet项目中附件存储形式与上传下载的数据结构

        FileNet CE部分核心基类有:Document、Folder和CustomObject。在ECM产品中,大部分Document或基于此类自定义的Document代表的是各业务处科室的主件。主件在定制的同时可能也会定制其他相关文件,这便可以称为附件。由此可看出就业务而言,仅文件内容至少可分为两种情况:区分主附件的业务和不区分主附件的业务。这些也会对ECM产品设计和实现产生微妙的影响。此文简述这一点。

        一个业务主件的产生或其作用过程中往往是在一条或多条业务流程下完成的。与此种情况相对应,处理业务的流程在运转过程中,也往往会携带主附件。这一点ECM和BPM相互作用的映射:业务主附件的产生可能需要流程逐步完成,业务处理流程的实现也可能需要伴随主附件的详细说明。

        业务文件存储在FileNet的Document或其子类的Content中,多个文件的情况可以完全存放于一个Document或其子类中,该类的属性作为业务属性;也可以单独将一些业务属性存放在属性类上(仅使用Document或其子类的属性,而不考虑Content),将其对应的多个业务文件分别存放在其他多个文件类上(仅使用Document或其子类的Content,而不考虑其属性),继而将属性类和附件类通过Link关联起来;如果业务字段仅为业务流程所需,可以将相关业务属性存放于流程的DataField中,而将业务文件单独存放于文件类。

         在流程和业务文件共存业务处理中,文件从附件向界面上传过程分为两种情况,一种是流程尚未启动时,将内容放到Document Content上,发起流程后进行关联,一种是将流程处理过程中上传附件,此时可以按照流程未启动情况进行处理,也可以将附件直接关联到流程上。

         流程附件处理过程往往先将附件信息展现在界面,而附件内容往往可以滞后。在流程和业务文件共存业务处理中,文件基本信息是可以部分存在VWAttachment和DataField中,加之附件的多项性,可以很好的利用Map和List的配合将多个附件信息进行展现。

 

你可能感兴趣的:(FileNet项目中附件存储形式与上传下载的数据结构)