电子政务基础平台详解.doc

电子政务基础平台详解第一章 基本架构1.1 编码出于集成的考虑，平台中所有需要编码的地方都采用UTF-8编码方式来处理数据。但有一个例外的地方，就是所有的properties文件都不是以UTF-8进行编码的。核心配置文件src/wfc_perties是GBK编码的，这是为了方便配置修改，对这个文件采用了本地化的编码格式。其它的properties文件皆以ISO-8859-1格式编码。1.2 配置系统主要配置文件为src/wfc_perties，配置内容可以参考文件中的说明。该配置文件中的配置项可以通过wfc.service.config.Config类来读取。1.3 Spring平台整体基于Spring框架，但不限于Spring框架。通过Spring的IoC、Annotation、AOP、AutoWired等特性，可以很愉悦地构建整个平台框架。1.3.1 自动装配平台通过自动搜索的方式来进行类的装配，搜索的范围仅限于package以coral开头的类，如果要自动装配其它package下的类，请对src/applicationContext.xml中的component-scan进行修改。能被自动装配的类都具有以下Annotation：Component、Service、Controller、Repository。1.3.2 MVC推荐使用Spring的MVC实现，Spring的MVC比较轻量级，非常灵活，并可以通过Annotation进行装配，避免了繁琐的配置。1.3.3 事务处理由于在平台中使用了各类数据访问层的技术，包括JDBC、Hibernate以及iBatis，所以在事务处理中必须使用JTA技术。使用JTA需要更改多处配置，首先需要在应用服务器中配置Data Source（Connection Pool），并指定JNDI；然后在src/wfc_perties中修改几个配置项，把wfc.service.connection.mode设为4，把wfc.service.database.pool.jndi设为指定的JNDI；接着在src/applicationContext.xml中配置JNDI形式的dataSource，并配置JTA形式的transactionManager；最后通过在ServiceImpl类上用Annotation声明Transactional就可以使该类的所有方法都具有事务的效果。1.3.4 缓存处理缓存处理一般使用AOP来实现，推荐使用AspectJ的Annotation方式来实现，具体例子可以参考src/coral/integration下的类。1.3.5 WebServiceWebService一般使用CXF来实现，通过对Service层进行Annotation方式的配置，可以很方便的创建WebService。并不是所有的方法都能被声明成WebService，要注意该方法的参数和返回值是不是都是可序列化的，如果存在不能序列化的参数或返回值，那么生成的WebService接口在调用过程中是会报错的。具体例子可以参考src/coral/clouddesktop/ConfigService和ConfigServiceImpl。1.4 AppContext作为全局上下文的静态类，该类定义了如下几个静态变量和静态方法，非常有用。其中appPath是应用的物理路径，webRootPath是应用的web根路径。getBean方法用于通过Spring的id或类名来获得类。具体参考src/coral/base/app/AppContext。1.5 初始化操作在系统启动时会执行一系列系统初始化的操作，这些初始化操作都被写在一些初始化的类里，初始化类都实现了src/coral/base/app/Initializer接口，并且允许自动装配。如果需要在系统启动时执行相关的操作都可以通过这个方式来实现。具体例子可以参考src/coral/base/app/CoralInitializer。1.6 会话在平台登录后，会话中将包含以下数据信息：session_user：当前登录用户信息，对象是一个com.wondersgroup.framework.security.bo.SecurityUser。session_org：当前登录用户所在的部门信息（数组），对象是一个数组，每一项为anization.bo.OrganNode。session_ext_js_theme：当前登录用户使用的js模板，对象是一个coral.base.frame.customise.ExtJsTheme。session_frame_theme：当前登录用户使用的界面框架，对象是一个coral.base.frame.customise.FrameTheme。session_menu_code：当前登录用户有权限访问的菜单code集合，对象是一个集合，每一项为String，是菜单的编号。session_check_string：登录时记录的校验码，对象是一个String。1.7 默认菜单生成平台通过src/menu.xml来生成默认的系统菜单，具体参见该文件中的说明操作。1.8 代码生成通过使用代码生成类可以由PDM文件或数据库生成BO类和DAO类，BO类和DAO类可以直接使用，访问数据库是采用封装的JDBC方式。BO类还可以在Hibernate下使用。具体使用方法参见util/DaoGenerator。1.9 注意点1.9.1 Struts2 FilterCuteFramework使用了Struts2，Struts2有个核心的Filter来预处理request中提交的数据，这在通常情况下并不会影响其它的操作。但是在文件上传的操作中，该Filter会对文件流进行预处理，将文件流缓存到临时文件中，这样的话，其它代码再想从文件流中获取文件就获取不到了。所以平台提供了这样一个类src/coral/base/cuteframework/CuteStruts2Filter来取代原生的Struts2 Filter，这个filter可以通过设置excludedPath来排除与Struts2无关的一级目录。如果在开发中新加了某个一级目录，一定要记得在这里进行配置，否则在文件上传处理中就会出现问题，即使没有文件上传，也会影响系统的处理速度。第二章 基础功能2.1 CuteFramework相关功能平台底层复用了CuteFramework的各个相关功能，主要包括登录；统一用户管理中的用户帐号管理、用户组管理、组织机构管理；统一权限管理中的按用户授权、按群组授权、按组织授权、权限资源管理、身份认证管理；应用系统管理中的基础数据管理、门户资源管理（菜单）等。2.2 页面级访问控制页面级访问控制采用了XML配置文件的方式来配置，配置文件为src/platform.function.xml。该文件中function元素与平台的菜单相对应，name属性为菜单的显示名称，permission属性为菜单的代码。page元素为具体的url，该url属性为从根目录开始的完整路径，但不包含传递的参数。page元素属于哪个菜单功能下，则将该page置于该菜单的子元素。没有出现在该xml文件中的url，访问不需要权限。2.3 日志统一的日志处理接口为src/coral/base/log/LogUtil。第三章 界面框架3.1 登录新接入一个登录模块，需要做以下一些工作：1) 为新登录模块定一个编号，假设为xxxxx。2) 定义一个URL为/login/xxxxx/login.do，该URL负责跳转至登录的实际地址，实际地址要在/login/xxxxx/目录下。3) 登录处理提交给/login/login_process.do，其中必须包含username和password两个参数，如果要验证码，再提交check参数，如果要指定登录成功后的返回地址（AJAX方式提交则无需该参数），则提交view参数，view通过Spring MVC来实现，所以一般情况下view值为redirect:开头的跳转格式。3.2 框架目前框架有三种风格，Frame风格、WebOS风格和Protlet风格，这三种风格可以互为切换。框架主要处理菜单和工作台的展现形式。WebOS风格中应用图标都在CuteFramework中的菜单管理中设置，可参考已设置过图标的菜单进行操作，能设置的图标请参见/WebRoot/frame/coral_widget/images/shortcuts目录下的PNG文件。3.3 界面组件界面组件采用EXTJS作为基本框架，采用了页面渲染的方式进行实现，其中实现较为复杂，效率上也存在一定问题，一般情况下不推荐使用平台中的界面组件库。如果要保持与平台界面风格一致，可以直接使用原生的EXTJS框架，或基于CuteFramework的Widget组件库。在平台的组件库常用的图标样式，可用于INPUT框，设置icon_class属性为silk-XXXXX即可，其中XXXXX的取值可以参见doc/icon_class.png。第四章 工作流与表单4.1 关系概述工作流的环境中有一个数据容器，用于存放工作流运行过程中的数据，工作流的驱动过程中，在分支中将会使用这些数据作为判断条件。表单为数据容器提供业务数据。所以可以这么认为，用户通过填写表单，来驱动工作流运行，从而完成整个业务。4.2 工作流4.2.1 概念 流程与业务流程是定义，业务是流程的具体实例，一个流程可能有多个业务。流程在代码中一般称为workflow，业务在代码中一般称为business。 结点与活动结点是流程的各个环节，是定义，活动是结点的具体实例。结点在代码中一般称为node，活动在代码中一般称为activity。 活动与活动项一个活动具体分配给某个人即产生一个活动项，分配给n个人，则生成n个活动项。活动项在代码中一般称为activity item。待办的活动项与已经完成的活动项区别在于有没有完成时间。活动是否完成，取决于活动项的完成情况，默认情况仅需要一个活动项完成，则活动完成，如果设置了操作条件，则判断条件是否满足，满足则活动完成。活动完成后则驱动流程。 操作结点上可以定义若干操作，一个活动项只能选择其中一个操作进行处理。操作有几种类型，下表列出了几种类型操作的区别：暂存只暂存当前表单，不作其它任何操作停留处理完当前活动项，生成同结点新的活动项，但不驱动流程办理处理完当前活动项并驱动流程驳回处理完当前活动项，并退回上一结点（需要流程支持）终止处理完当前活动项，并结束整个流程（需要流程支持）跳转处理完当前活动项，并跳转到指定结点（需要流程支持） 数据容器数据容器作为工作流中的重要组成部分，数据容器中存放了流程中产生的所有数据，格式为XML。下面给出一个XML的示例。asdf2011-08-1533233av105审批产品开发市内交通费asdfsdafB1231112223334444.2.2 实现 Flexibility仅含一个结点的工作流，该结点循环流转，永不终止，仅作测试用。 CuteFlowCuteFlow定义参照相关文档操作，其中特别需要注意的有以下几点：1) 必须在business数据容器中定义一个类型为String，名称叫eform的数据项，见如下的示例图。如果未定义该数据项，在流程驱动时会提示相关错误。2) 线上的条件定义已经被重写，故关于条件的格式有了新的定义。条件围绕的数据就是数据容器中的内容，具体可以参考数据容器的概念。在条件定义中使用了几个内置的对象，最常用的就是xp，该对象对应的是 src/coral/workflow/adapter/cuteflow/util/Xpath，最常用的方法是 boolean has(String xpath)，其中xpath针对的就是数据容器，has方法表示xpath能否返回对象，工作流引擎依据其返回值来驱动流程。另外还有两个不太常用的对象 eformTree 和 eform，具体用法参见 src/coral/workflow/adapter/cuteflow/util/CuteflowBusinessDataHelper 中的实现 JBPM4JBPM4是开源工作流，相关资料请参阅网上资料，该工作流采用令牌方式驱动流程运转，受限于此，工作流在某些方面不能符合国情需要，较多的业务功能无法在这个工作流上实现，所以不推荐使用该工作流。 各工作流比较Flexibility仅有一个结点，可以模拟流程运行，适用于测试。CuteFlow有定义工具，较为灵活，推荐使用。JBPM4开放标准，但不太符合国情，不推荐使用。4.2.3 版本工作流存在版本的控制，不同版本的工作流之间只是code相同，其它相关配置都是独立的，互不相干，甚至生成的菜单也是不同的。在工作流安装的时候，把code设置为与原有流程的code相同，则该工作流为原流程的新版本，版本号以自然数方式递增。新版本的工作流将继承原流程的配置，继承的规则是只要名称相同的结点，其配置内容相继承，总配置也继承与原流程。注意在结点名称改变后，结点的配置需要重新设置。4.2.4 计时系统的计时相对简单，只在内部记录流程的每个计时段，具体如何计算时限，需要应用策划并进行二次开发。计时段可参考数据库表WWF_ACTIVITY_TIMER的设计。4.2.5 额外操作额外操作是工作流对外开放的标准扩充接口，实际该接口的类，可以在流程配置时设置与流程绑定，这样在流程运行时，可以调用到额外的操作代码。接口可以参考coral.workflow.extra该包下的相关代码。4.2.6 各类编号说明流程启动时，流程会生成两个编号：其中一个是eformOriginalDataId（当前数据编号），它与eformXmlDataId（当前表单数据编号）、businessId、activityItemId（启动活动项编号）值相同；另一个是eformOriginalDataId（历史数据编号），它与 business.eformOriginalDataId、activityItem.eformOriginalDataId（启动活动项所指向的数据编号）值相同。结点操作时，流程会生成两个编号：其中一个是eformOriginalDataId（当前数据编号），它与eformXmlDataId（当前表单数据编号）、activityItemId（操作活动项编号）；另一个是eformOriginalDataId（历史数据编号），它与activityItem.eformOriginalDataId（操作活动项所指向的数据编号）值相同。4.3 表单4.3.1 实现 Flexibility可以填写任意数据，包括文件上传等，仅作测试用。 WeForm3.2和WeForm4WeForm有两个可用版本，3.2和4，其中3.2版本采用了XSL技术来生成界面，使用PDF作为打印文件；4版本采用HTML来生成界面及打印预览，相对于3.2版本更为灵活，但是在打印的品质上有所不及。WeForm定义参照相关文档操作，其中特别需要注意的有以下几点：1) 表单的权限可以通过设置来实现，具体设置的含义如下：user_用户登录名：仅当前用户与指定用户相同时才显示该字段项；group_用户组编号：仅当前用户所属用户组中包含指定用户组时才显示该字段项；org_组织编号：仅当前用户所属组织中包含指定组织时才显示该字段项。2) 表单的使用可以参见doc/WeForm3.2下的文档。这里特别说明一下表单默认值的处理，普通的默认值不具体说明，单说可以替换的默认值，这些值的格式为XXX，其中XXX为替代值。这种值有以下三种情况。第一种为平台内置的值，如下表所示：日期格式为yyyy-MM-dd年格式为yyyy月格式为MM日格式为dd用户当前登录的用户姓名单位当前登录用户所属的单位名称（如果该用户属于多个部门，则随机返回其中一个单位名称）第二种为session值，如下表所示，其中为session属性的名称：session属性的取值第三种为流程中的值，如下表所示，其中为流程中的数据名称或编号：#流程中的数据名称或编号 JSPForm和JSP+FormJSPForm和JSP+Form仅存在一点区别，JSPForm只有创建操作，不能进行更新操作，预览操作则是通用的界面，比较简陋，JSP+Form则可以完全定义以上三种操作的界面。建议一般情况下都采用JSP+Form。JSP+Form是有一定要求的，以下参数是需要从request可接收，并提交给平台的（提交给平台的链接为/eform/application/eform_submit.do）：eform_id电子表单编号ex_type表单应用类型（见EformConstant的EFORM_USE_TYPE_WORKFLOW和EFORM_USE_TYPE_ACTIVITY_ITEM）ex_id工作流编号（workflowId）或活动项编号（activityItemId），区分参照ex_type取值ex_op操作编号（operationId）eform_data_id表单数据编号concurrent_flag同步操作标志，如果没有在多个结点同时可填同张该表单的情况下，可以不处理该数据如果有附件要提交给平台，可以用这样的做法：通过异步方式，把文件提交到平台，通过自己的代码把文件置入WEF_ATTACHMENT表，并把该表中的ST_ATTACHMENT_ID返回回来，并作为表单的一部分随表单一起提交。相关内容可以参考src/coral/eform/adapter/flexibility/FlexibilityController中的fileUploadProcess方法。区分表单三种不同操作的参数是jsp_type，含义如下：create：创建新表单；update：更新表单；preview：预览表单。 NTKO通过上传MS Office或者WPS模板，在模板中插入书签作为表单形式，进行数据提交处理。详细使用方法参见doc/NTKO下的相关文档。 各表单比较Flexibility可以模拟提交包括附件在内的任意值，适用于测试。WeForm3.2优点是有数据项的预填和权限控制，打印效果好。缺点是界面开发的灵活性很差。WeForm4优点是有数据项的预填和权限控制，有一定的界面开发灵活性。缺点是打印效果需要开发者精密控制。JSPForm开发快速而简单，但不能更新和定义预览，适用于测试。JSP+Form非常灵活，可以根据应用进行复杂的设计。NTKO优点是支持电子签章和电子签名，打印效果很好。缺点是数据校验困难，数据格式及表单完整性控制困难。暂时还未实现数据项的预填和权限控制功能。4.3.2 版本4.3.3 特殊含义的数据表单中有些特殊含义的数据，这些数据会在流程处理中有特殊的作用，如下表所示：title作为申请时的表单，该字段值将作为business或activityItem的标题config_string动态配置，用于动态调整结点权限和可执行的操作列表，格式为：nodeName,配置类型,配置面向的对象标识或名称，下面罗列各种具体的情况：1) 配置类型为user_add或user_remove时，对象为userLoginName2) 配置类型为group_add或group_remove时，对象为groupCode3) 配置类型为org_add或org_remove时，对象为orgCode4) 配置类型为group_user_add或group_user_remove，对象为groupCode:userLoginName5) 配置类型为org_user_add或org_user_remove，对象为orgCode:userLoginName6) 配置类型为op_add或op_remove时，对象为operationNameorg_id部门编号（只影响流程起动的ActivityItem）group_id用户组编号（只影响流程起动的ActivityItem）node_id跳转的结点的编号（只影响跳转操作）4.4 移动接口接口以ajax方式提供，以下是接口的详细描述：1) 登录地址：/mobile/mobileLogin.do参数：account 帐号password 口令返回值示例：成功userId ：0032f438-4e30-4113-b119-1f5cbe2f101a,username : 张三,success : true失败success : false2) 获得待办事项地址：/mobile/mobileGetActivityItemList.do参数：userId 用户编号nodeId 结点编号pageSize 每页记录数pageNum 页号返回值示例：page ：1,total : 100,rows : activityItemId : 0032f438-4e30-4113-b119-1f5cbe2f101a,title : 事项A,startTime : 2012-09-10 15:33,businessId : 0032f438-4e30-4113-b119-1f5cbe2f101a, activityItemId : 0