Flowable 6.6.0 BPMN使用者指南 - 12 歷史（History）- 12.2 歷史配置、12.3 非同步歷史配置
技術標籤：Flowable 6.6.0 BPMN使用者指南 -9-12
《Flowable 6.6.0 BPMN使用者指南》
1. 入門
2. 配置
3 The Flowable API
4 Flowable 6.6.0 BPMN使用者指南 - (4)Spring整合
5 Spring Boot
6 部署
7 BPMN 2.0簡介
8 BPMN 2.0的構造
9 表單（Forms）
10 流程例項遷移
11 JPA
12 歷史（History）
有關Flowable的更多文件，參見：
12.2 歷史配置
The history level can be configured programmatically, using the enum org.flowable.engine.impl.history.HistoryLevel (or HISTORY constants defined on ProcessEngineConfiguration for versions prior to 5.11):
可以以程式設計方式配置歷史級別，即使用列舉org.flowable.engine.impl.history.HistoryLevel（或5針對.11之前的版本，使用在ProcessEngineConfiguration上定義的HISTORY 常量）：
ProcessEngine processEngine = ProcessEngineConfiguration
.createProcessEngineConfigurationFromResourceDefault()
.setHistory(HistoryLevel.AUDIT.getKey())
.buildProcessEngine();
The level can also be configured in flowable.cfg.xml or in a spring-context:
也可以在flowable.cfg.xml或者在spring-context中配置級別：
<bean id="processEngineConfiguration" class="org.flowable.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
<property name="history" 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. At the end of the process instance, the latest values of the top level process instance variables will be copied to historic variable instances. No details will be archived.
- audit: This is the default. It archives all process instances, activity instances, keeps variable values continuously in sync 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, mostly this are process variable updates.
- 無（none）：跳過所有歷史存檔。對於執行時程序執行來說，這是最有效的，但是沒有可用的歷史資訊。
- 活動（activity）：歸檔所有流程例項和活動例項。在流程例項結束時，頂級流程例項變數的最新值將複製到歷史變數例項中。不會存檔任何詳細資訊。
- 審計（audit）：這是預設設定。它歸檔所有流程例項、活動例項、保持變數值持續同步以及提交的所有表單屬性，以便跟蹤通過表單進行的所有使用者互動，並且可進行審計。
- 完整（full）：這是歷史存檔的最高級別，因此速度最慢。此級別儲存稽核級別中的所有資訊以及所有其他可能的詳細資訊，主要是流程變數更新。
In older releases, the history level was stored in the database (table ACT_GE_PROPERTY, property with name historyLevel). Starting from 5.11, this value is not used anymore and is ignored/deleted from the database. The history can now be changed between 2 boots of the engine, without an exception being thrown in case the level changed from the previous engine-boot.
在舊版本中，歷史級別儲存在資料庫中（表ACT_GE_PROPERTY，名為historyLevel的屬性）。從5.11開始，這個值不再使用，並且被忽略/從資料庫中刪除。歷史記錄現在可以在engine的兩次啟動之間更改，如果級別從以前的engine引導（engine-boot）更改，則不會引發異常。
12.3 非同步歷史配置
Async History has been introduced with Flowable 6.1.0 and allows historic data to be persisted asynchronously using a history job executor.
非同步歷史已經在flowable 6.1.0中引入，並允許使用歷史作業執行器（history job executor）非同步地持久化歷史資料。
<bean id="processEngineConfiguration" class="org.flowable.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration">
<property name="asyncHistoryEnabled" value="true" />
<property name="asyncHistoryExecutorNumberOfRetries" value="10" />
<property name="asyncHistoryExecutorActivate" value="true" />
...
</bean>
With the asyncHistoryExecutorActivate property, the history job executor can be started automatically when booting the Process Engine. This would be only set to false for test cases (or if Async History is not enabled of course). The asyncHistoryExecutorNumberOfRetries property configures the number of retries for an Async History job. This property is a bit different than that for a normal async job, because a history job may need more cycles before it can be handled successfully. For example, a historic task first has to be created in the ACT_HI_TASK_ table before the assignee can be updated by another history job. The default value for this property is set to 10 in the Process Engine configuration. When the number of retries has been reached, the history job will be ignored (and not written to a deadletter job table).
使用asyncHistoryExecutorActivate屬性，可以在啟動流程引擎（booting the Process Engine）時自動啟動歷史作業執行器（history job executor）。對於測試用例，這隻會被設定為false（或者如果沒有啟用非同步歷史）。asyncHistoryExecutorNumberOfRetries屬性配置非同步歷史作業的重試次數。此屬性與普通非同步作業的屬性稍有不同，因為歷史作業可能需要更多的週期才能成功處理。例如，必須先在ACT_HI_TASK_表中建立一個歷史任務，然後才能由另一個歷史作業更新受讓人。在流程引擎配置中，此屬性的預設值設定為10。當達到重試次數時，歷史作業將被忽略（並且不會寫入死信作業表（deadletter job table））。
In addition to these properties, the asyncHistoryExecutor property can be used to configure an AsyncExecutor in a similar way that you can do for the normal async job executor.
When the history data is not to be persisted in the default history tables, but for example, is required in a NoSQL database (such as Elasticsearch, MongoDb, Cassandra and so on), or something completely different is to be done with it, the handler that is responsible for handling the job can be overridden:
- Using the historyJobHandlers property, which is a map of all the custom history job handlers
- Or, configure the customHistoryJobHandlers list with all instances will be added to the historyJobHandlers map at boot time.
除了這些屬性之外，asynchHistoryExecutor屬性還可以用於配置AsyncExecutor，方法與普通非同步作業執行器（async job executor）類似。
當歷史資料不儲存在預設的歷史表中，但需要儲存在如NoSQL的資料庫（如Elasticsearch、MongoDb、Cassandra等）中需要時，或者要對其執行完全不同的操作時，可以重寫負責處理該作業的處理程式：
- 使用historyJobHandlers屬性，它是所有自定義歷史作業處理程式的對映
- 或者，配置customHistoryJobHandlers列表，將在引導（boot time）時將所有例項都新增到historyJobHandlers對映（map）中。
Alternatively, it is also possible to use a Message Queue and configure the engine in such a way that a message will be sent when a new history job is available. This way, the historical data can be processed on different servers to where the engines are run. It’s also possible to configure the engine and Message Queue using JTA (when using JMS) and not store the historical data in a job, but send it all data to a Message Queue that participates in a global transaction.
See the Flowable Async History Examples for various examples on how to configure the Async History, including the default way, using a JMS queue, using JTA or using a Message Queue and a Spring Boot application that acts as a message listener.
或者，也可以使用訊息佇列並配置引擎，以便在新的歷史作業可用時傳送訊息。這樣，可以在執行引擎的不同伺服器上處理歷史資料。還可以使用JTA（使用JMS時）配置引擎和訊息佇列（Message Queue），不儲存作業中的歷史資料，而是將所有資料傳送到參與全域性事務的訊息佇列（Message Queue）。
有關如何配置非同步歷史（Async History）的各種示例，請參閱可流動的非同步歷史示例（he Flowable Async History Examples），包括預設方式、使用JMS佇列、使用JTA或使用訊息佇列（Message Queue）以及Spring Boot應用程式等作為訊息偵聽器。