BPM Console Reference
BPM Console Reference – 1.0.0.GA
1. Technical Overview(技术概述)
1.1 Main components(主要组件)
1.2 Integration With the processengine(集成流程引擎)
1.3 Deployment Artifacts(部署artifacts)
1.4 Classloadingscopes(classloading作用域)
2. Workspace framework(工作空间配置)
2.1 Workspace API(工作空间 API)
2.1.1 Workspaceconfiguration(配置)
2.1.2 Build profiles(build概况)
2.2 Console server plugins(Console服务器插件)
2.2.1 Plugin loading(插件加载)
3. Management capabilities(管理能力)
3.1 Process Management(流程管理)
3.1.1 Process life cycle(流程生命周期)
3.1.2 Instance life cycle(实例生命周期)
3.1.3 Process Activity(流程活动)
3.1.4 Instance Data(实例数据)
3.1.5 Process forms(流程表单)
3.2 Task Management(任务管理)
3.2.1Users，Groups and identity management(用户，分组，和身份管理)
3.2.2Task life cycle(任务生命周期)
3.2.3Task forms(任务表单)
3.3 Reporting(表报)
3.3.1Default reports(默认报表)
3.3.2Customizing report templates(自定义报表模板)
3.3.3Default reports(默认报表)
4. Appendix A:FormDispatcherPlugin()
4.1 Default context information(默认上下文信息)
4.2 Dynamic render context(异步初始化上下文)
5. Appendix B: Report server(报表服务器)
5.1 Console integration(控制台整合)
5.2 The BIRT runtime(BIRT 运行时)
5.3 Report templates(表报模板)
6. Appendix C: Authentication andaccess(身份验证和访问)
技术概述
主要成分
控制台包含三个不同的部分：控制台用户界面，控制台服务器和集成层。后来从服务器模块中分离出来的实际流程引擎：
控制台UI是一个ajax的web应用程序，只是用http进行通信的服务器模块。服务器模块，提供啦一个REST门面的控制台用户界面和集成的实际流程引擎。
与流程引擎的整合
流程引擎是通过一个集成层去连接的。集成API是控制台项目的一个部分，实际执行的层就是流程引擎。在运行时，服务器模块通过集成层，来使用一个服务加载机制来访问流程引擎。
集成层允许不同的流程引擎使用相同的控制台进行管理，并防止在这个流程中引起在管理控制台中的变化。
部署构件
虽然安装的控制台通常包含安装的流程引擎，你也需要知道哪些部分在哪个地方，尤其是将控制台移植到不同的容器中。
Bonanova:jboss-5.0.0.GAhbraun$ find ./ -name "gwt*"
./server/default/deploy/jbpm/gwt-console-server.war
./server/default/deploy/jbpm/gwt-console.war
./server/default/lib/gwt-console-rpc.jar
./server/default/lib/gwt-console-server-integration.jar
快速扫描安装的一个例子，解释啦一个四个控制台有关的构件。两个web应用程序（控制台用户界面和控制台服务器）以及两个共享库：所有层和集成层API之间共享的数据模型。
Component(组件) DeploymentArtifact(部署构件)
ConsoleUI(控制台UI) gwt-console.war
ConsoleServer(控制台服务器) gwt-console-server.war
Domainmodel(领域模型) gwt-console-rpt.jar
IntegrationLayer(集成层) gwt-console-server-integration.jar
类加载范围
控制台用户界面是完全分离的，因为他是用HTTP服务器来访问后台（记住它的AJax）。然而，控制台服务器和流程引擎需要共享相同的类加载范围，否则服务加载机制不起作用。这儿两个reaming 构件，rpc.jar 和server-integration.jar应该进入一个共享的范围中，因为他们需要提供给每一层。
工作区框架
我们考虑到工作区，基本上是主要的控制台UI布局，包括主要的左侧导航，头部，消息面的底部和编辑器窗格中的中间。工作空间和他的内容是通过一个工作区API抽象出来的。工作区API允许你添加不同的编辑器到工作区。每一个编辑器都代表一个特定用例或者管理能力。控制台“one size fits many”做法。针对在重用和允许专有扩展在需要的时候。建立时间扩展，又名插件，将实际UI和运行时扩展插件化，允许替换控制台UI依赖于服务器功能。
注意：如何你不熟悉GWT，阅读GWT介绍，下面几个部分。
工作区API
工作区API涉及到控制台UI本身的扩展。工作区包含视图的编辑器。每一个编辑器提供了在左边的导航主菜单。在构建是的控制台安装插件，可作为Maven的依赖关系的基础上。为了扩展控制台UI，你是否只需要提供一个编辑器的实现，是建立对工作区API。
工作区配置
一个简单的属性文件控制实际的工作区组成。这是一个包含转配是，应包含最终的web应用程序的列表编辑器，选择构建配置文件的一部分。
#the default workspace.cfg
org.jboss.bpm.console.client.SettingsEditor
org.jboss.bpm.console.client.process.ProcessEditor
org.jboss.bpm.console.client.task.TaskEditor
org.jboss.bpm.console.client.report.ReportEditor
org.jboss.bpm.console.client.engine.EngineEditor
建立配置文件
在构建配置文件是，通过使用定制的控制台。它实际上是行家所触发的系统属性的配置文件：
Mvn–Dconsole.profile=jbpm
如果你正在寻找扩展控制台，那么就自定义配置点击右键开始生成。他不仅制定工作区的配置，还可以允许提供任意的依赖关系为你的需要。自定义编辑器作为maven架构已经发布。
控制台服务插件
服务器模块提供啦挂钩，为了考虑流程引擎本身，以取代或者消除某些功能。
插件加载
服务器模块插件通过使用服务加载机制，和通过简单的替换jar文件去启用服务器模块的classpath来实现加载。我们不详谈这里，但是一个很好的例子是FormDispatcherPlugin。
管理能力
请记住，控制台被设计为可扩展的。虽然他是附带的管理流程引擎设置的默认编辑器，但他也可能不符合你的要求。适用性和扩展性有必要重构。然而，这儿并不意味着默认的管理能力是固定的。积极的讨论和反馈可以帮助在现有的经验中提高，随着时间的推移。
流程管理
流程管理编辑器允许管理流程定义和流程实例
流程生命周期
流程定义可能是挂起和恢复状态，这儿与他们的部署状态关联。在部署周期和流程实体中，需要作进一步的解释，请参考流程引擎用户指南。
实例的生命周期
流程实例可以被启动，终止或者删除。终止以为着该实例已经结束，而删除将强制拆除实例和所有相关的实体，及历史信息。
流程活动
如果部署包含一个流程图，你可以访问图形表示实例活动状态。在内部，这是处理的GraphViewer插件。
实例数据
监测当前的流程状态（又名变量）是在读取模式。
流程表单
如果该流程关联一个表单，它就会在一个新的流程实例启动时使用，控制台将要求你输入数据基于表单模板附加到部署中。类似的GraphViewer这个选项将被提供，如果部署中包含一个表单模板和流程应用。欲了解更多信息，请咨询流程引擎用户指南。
任务管理
根据目前身份验证，任务编辑器提供用户组合用户列表，来访问任务。你有能力要求和分配任务以及通过流程任务表单提供数据。
用户，组合身份管理
实际的身份管理控制由流程引擎和省份验证提供解决方案。目前的主要任务是依赖查询。这儿意味着任务组，目前任务启用还是当前所属者或者组中的某个人。
任务生命周期
目前，控制台使用一个简化的任务生命周期模式。任务可以是开放式的，或者分配给别人的。开放是的任务是提供给一个组，然后可以声明任务和从而将其分配给自己的用户。释放一个任务就是开放了一次。
任务表单
主要的用例任务之一是审核或者提供流程数据。在这儿两种情况下一个任务将流程实例和访问的数据存储在一个只读或者只写的方式关联起来。控制台将任务表单委托给FormDispatcher插件。任务表单是可用的，如果FormDeispatcher可以解决一个关联特定任务实例的表单模板。
报表
报表是基于BIRT的功能。所有的控制台提供的一个报表服务组件去渲染报表模板和集成实际的UI。流程引擎提供了模板，你可以依赖，延伸，甚至替代所有的。基本思想是任何一种报表要求定制，无论如何，我们之提供集成的现有模板，让你开始。
默认报表
默认报表被分隔为一个普通系统概述和特殊流程报表。后来可以允许你通过引导执行特性分析系统概述去分析一个特殊流程。旨在发现推导和特殊情况一抹了然。但是记住，打算定制和丰富你的应用程序域数据。
自定义的报表模板
流程引起提供了一组默认的BIRT模板报表，这儿模板是使用BIRT报表设计工具来自定义的。附录B中包含如何将它们部署到BIRT运行时中。
默认报表
报表 模块名称
一般系统概述 overall_activity.rptdesign
流程活动总结 process_summary.rptdesign
附录A：FormDispatcherPlugin
默认的表单插件实现利用的FreeMarker模板库。他是建立在以下的内容中：
模板后缀需要“*.ftl”和包含部署的hTML表单需要提供正确的加密类型”multipart/form-data”的表字段名称成为过程流程变量，反之亦然，信号执行任务完成是，的保留字段名:”outCome”。
默认上下文信息
表单渲染上下文，提供了默认上下文信有用的信息为初始化模板：当前这样“${form}“和”${outcome}”;这些是用来在表单初始化时信息。
Eg :
<h2>Youremployee would like to go on vacation</h2>
<form action="${form.action}"
method="POST" enctype="multipart/form-data"> (1)
Number of days:${number_of_days}<br/> (2)
<hr>
In case you reject, please provide areason:<br/>
<input type="textarea"name="reason"/><br/> (3)
<#list outcome.values astransition> (4)
<input type="submit" name="outcome"value="${transition}"> (5)
</#list></form>
1.访问表单的action地址：form.action
2.引用一个流程变量，名字为“numer_of_days“
3.创建一个新的流程变量，名字“reason“
4.访问转化动态：”outcome.values”
5.保留字段名称来触发执行：‘outcome’
动态渲染上下文
以上所述，许多属性在运行时提供，即实际的表单action参数或者现有outcomes(转化)。其中有些是必需的，不能出现在设计时（表单行为），有的只是方便（可用的结果）。
附录B:报表服务器
控制台服务器集成BIRT运行时，提供流程引擎活动的报表历史。在控制台上的报表实际上是分解成三个部分：集成控制台，集成BIRT运行时，和实际的报表模板。
控制台集成
实际的控制台整合被默认的报表编辑器覆盖，应该不会有太大的问题。
BIRT运行时
BIRT运行时通常会和流程引擎一起安装，或者可以检索BIRT网站。它需要被安装在一个特定的位置，他的位置又控制台服务器来决定。在JBoss中，使用服务器的数据目录是模板和存储结果。
Bonanova:jboss-5.0.0.GAhbraun$ ll server/default/data/birt/
hbraun staff 340 Jul 9 12:57 ReportEngine
hbraun staff 170 Jul 9 12:58 output
hbraun staff 150899 Jul 9 12:53overall_activity.rptdesign
hbraun staff 669 Jul 9 12:53process_summary.rptconfig
hbraun staff 153602 Jul 9 12:53process_summary.rptdesign
报表模板
流程引擎提供的报表模板。但是，如果你计划去自定一个默认报表模块，BIRT数据目录将被替换。
附录C:身份验证和访问
控制台目前使用http基本身份验证去访问控制台服务器。服务器模式被连接到JAAS域，就像在其他任务web应用程序中。目前访问控制接口是控制台UI。
996
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
