网路冷眼@BlogJava

熙熙攘攘一闲人 以冷静的眼光观察技术
posts - 88, comments - 193, trackbacks - 0, articles - 28
  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理

Chapter 10. History(历史)

Table of Contents

History configuration(历史配置)
History for audit purposes(审计目的的历史)

History is the component that captures what happened during process execution and stores it permanently. In contrast to the runtime data, the history data will remain present in the DB also after process instances have completed.

历史是在流程执行过程中抓取的事件以及把事件永久存储的部件。与运行时数据相比较,历史数据既将当前的数据也将流程已经完成的数据保留在数据库中。

There are 3 history entities: HistoricProcessInstances containing information about current and past process instances, HistoricActivityInstances containing information about a single execution of an activity and HistoricDetail containing various kinds of information related to either a historic process instances or an activity instance.

存在3种历史实体:HistoricProcessInstance包含与当前和过去流程示例相关的信息;HistoricActivityInstance包含与一个活动的当个执行相关的信息;HistoricActivityInstance包含与历史流程实例或者一个活动示例相关的不同的信息。

In the API, the HistoryService exposes this information by offering methods createHistoricProcessInstanceQuery, createHistoricActivityInstanceQuery and createHistoricDetailQuery.

在API里,历史服务(HistoryService)通过提供createHistoricProcessInstanceQuery, createHistoricActivityInstanceQuery and createHistoricDetailQuery方法暴露这个信息。

Since the DB contains historic entities for past as well as ongoing instances, you might want to consider querying these tables in order to minimize access to the runtime process instance data and that way keeping the runtime execution performant.

因为DB包含过去的,正运行示例的历史实体,所以为了最小化访问运行流程实例的数据,你也许考虑查询这些库表。这种方式保留了运行期执行的效率。

Later on, this information will be exposed in Activiti Explorer and Activiti Probe. Also, it will be the information from which the reports will be generated.

最后,这个信息将会在 Activiti Explorer和 and Activiti Probe里面暴露。这将是报告将会产生信息的来源。

History configuration(历史配置)

In the activiti.cfg.xml configuration file, you can configure the level of history archiving that needs to happen:

在activiti.cfg.xml配置文件,你能配置需要的历史归档的级别:

<activiti-cfg>
<history level="audit" />
...
</activiti-cfg>

Or if you're using the spring style of configuration:

或者如果你正使用Spring风格的配置方式:

<bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
<property name="historyLevel" value="audit" />
...
</bean>

Following history levels can be configured:

可以配置如下的历史级别:

  • none: skips all history archiving. This is the most performant for runtime process execution, but no historical information will be available.

    忽略所有的历史归档。尽管对于运行期流程执行来说这是性能最高的,但是没有历史信息保留。

  • activity: archives all process instances and activity instances. No details will be archived

    归档所有流程实例和活动实例。不归档细节。

  • audit: This is the default. It archives all process instances, activity instances and all form properties that are submitted so that all user interaction through forms is traceable and can be audited.

    这是缺省级别。它归档所有流程实例,活动实例和提交的表单属性。以至于通过表单的所有用户交互都是可跟踪并可以被审计。

  • full: This is the highest level of history archiving and hence the slowest. This level stores all information as in the audit level plus all other possible details like process variable updates.

    这是历史归档的最高级别。所以是最慢的。这个水平保存audit级别的所有信息加上像流程变量的所有其它可能的细节。

History for audit purposes(审计目的的历史)

When configuring at least audit level for configuration. Then all properties submitted through methods FormService.submitStartFormData(String processDefinitionId, Map<String, String> properties) and FormService.submitTaskFormData(String taskId, Map<String, String> properties) are recorded.

当配置configuring 至少为audit级别时,那么通过FormService.submitStartFormData(String processDefinitionId, Map<String, String> properties)FormService.submitTaskFormData(String taskId, Map<String, String> properties) 方法提交的所有属性将会被记录。

[KNOWN LIMITATION] Currently the forms as worked out in Activiti Explorer do not yet use the submitStartFormData and submitTaskFormData. So the form properties are not yet archived when using the forms in Activity Explorer. @see ACT-294

[KNOWN LIMITATION] 当前在工作的表单 还没有使用 submitStartFormDatasubmitTaskFormData。所以当在使用表单时,表单属性还未被归档。@参见 ACT-294

Form properties can be retrieved with the query API like this:

表单特性能够像下面以查询API方式检索:

historyService
.createHistoricDetailQuery()
.onlyFormProperties()
...
.list();

In that case only historic details of type HistoricFormProperty are returned.

在那种情况下,只返回 HistoricFormProperty类型的历史细节。

If you've set the authenticated user before calling the submit methods with IdentityService.setAuthenticatedUserId(String) then that authenticated user who submitted the form will be accessible in the history as well with HistoricProcessInstance.getStartFormUserId() for start forms and HistoricActivityInstance.getAssignee() for task forms.

如果在调用带有IdentityService.setAuthenticatedUserId(String) 提交方法之前,你已经设置认证用户,那么提交这个表单的那个认证用户将会在历史里可访问。带有HistoricProcessInstance.getStartFormUserId() 访问启动表单,带有HistoricActivityInstance.getAssignee() 访问任务表单。


只有注册用户登录后才能发表评论。


网站导航: