Chapter 10. History(歷史)
Table of Contents
- History configuration（歷史配置）
- History for audit purposes(審計(jì)目的的歷史)
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.
歷史是在流程執(zhí)行過(guò)程中抓取的事件以及把事件永久存儲(chǔ)的部件。與運(yùn)行時(shí)數(shù)據(jù)相比較，歷史數(shù)據(jù)既將當(dāng)前的數(shù)據(jù)也將流程已經(jīng)完成的數(shù)據(jù)保留在數(shù)據(jù)庫(kù)中。
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種歷史實(shí)體：HistoricProcessInstance包含與當(dāng)前和過(guò)去流程示例相關(guān)的信息；HistoricActivityInstance包含與一個(gè)活動(dòng)的當(dāng)個(gè)執(zhí)行相關(guān)的信息；HistoricActivityInstance包含與歷史流程實(shí)例或者一個(gè)活動(dòng)示例相關(guān)的不同的信息。
In the API, the HistoryService exposes this information by offering methods createHistoricProcessInstanceQuery, createHistoricActivityInstanceQuery and createHistoricDetailQuery.
在A(yíng)PI里，歷史服務(wù)（HistoryService）通過(guò)提供createHistoricProcessInstanceQuery, createHistoricActivityInstanceQuery and createHistoricDetailQuery方法暴露這個(gè)信息。
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.
因?yàn)镈B包含過(guò)去的，正運(yùn)行示例的歷史實(shí)體，所以為了最小化訪(fǎng)問(wèn)運(yùn)行流程實(shí)例的數(shù)據(jù)，你也許考慮查詢(xún)這些庫(kù)表。這種方式保留了運(yùn)行期執(zhí)行的效率。
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.
最后，這個(gè)信息將會(huì)在 Activiti Explorer和 and Activiti Probe里面暴露。這將是報(bào)告將會(huì)產(chǎn)生信息的來(lái)源。
History configuration（歷史配置）
In the activiti.cfg.xml configuration file, you can configure the level of history archiving that needs to happen:
在activiti.cfg.xml配置文件，你能配置需要的歷史歸檔的級(jí)別：
<activiti-cfg>
<history level="audit" />
...
</activiti-cfg>
Or if you're using the spring style of configuration:
或者如果你正使用Spring風(fēng)格的配置方式：
<bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
<property name="historyLevel" value="audit" />
...
</bean>
Following history levels can be configured:
可以配置如下的歷史級(jí)別：
-
none: skips all history archiving. This is the most performant for runtime process execution, but no historical information will be available.
忽略所有的歷史歸檔。盡管對(duì)于運(yùn)行期流程執(zhí)行來(lái)說(shuō)這是性能最高的，但是沒(méi)有歷史信息保留。
-
activity: archives all process instances and activity instances. No details will be archived
歸檔所有流程實(shí)例和活動(dòng)實(shí)例。不歸檔細(xì)節(jié)。
-
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.
這是缺省級(jí)別。它歸檔所有流程實(shí)例，活動(dòng)實(shí)例和提交的表單屬性。以至于通過(guò)表單的所有用戶(hù)交互都是可跟蹤并可以被審計(jì)。
-
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.
這是歷史歸檔的最高級(jí)別。所以是最慢的。這個(gè)水平保存audit級(jí)別的所有信息加上像流程變量的所有其它可能的細(xì)節(jié)。
History for audit purposes(審計(jì)目的的歷史)
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.
當(dāng)配置configuring 至少為audit級(jí)別時(shí)，那么通過(guò)FormService.submitStartFormData(String processDefinitionId, Map<String, String> properties) 和 FormService.submitTaskFormData(String taskId, Map<String, String> properties) 方法提交的所有屬性將會(huì)被記錄。
[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] 當(dāng)前在工作的表單 還沒(méi)有使用 submitStartFormData 和 submitTaskFormData。所以當(dāng)在使用表單時(shí)，表單屬性還未被歸檔。@參見(jiàn) ACT-294
Form properties can be retrieved with the query API like this:
表單特性能夠像下面以查詢(xún)API方式檢索：
historyService
.createHistoricDetailQuery()
.onlyFormProperties()
...
.list();
In that case only historic details of type HistoricFormProperty are returned.
在那種情況下，只返回 HistoricFormProperty類(lèi)型的歷史細(xì)節(jié)。
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.
如果在調(diào)用帶有IdentityService.setAuthenticatedUserId(String) 提交方法之前，你已經(jīng)設(shè)置認(rèn)證用戶(hù)，那么提交這個(gè)表單的那個(gè)認(rèn)證用戶(hù)將會(huì)在歷史里可訪(fǎng)問(wèn)。帶有HistoricProcessInstance.getStartFormUserId() 訪(fǎng)問(wèn)啟動(dòng)表單，帶有HistoricActivityInstance.getAssignee() 訪(fǎng)問(wèn)任務(wù)表單。