Flowable 6.6.0 BPMN使用者指南 - 12 曆史（History）- 12.2 曆史配置、12.3 異步曆史配置

Flowable 6.6.0 使用者指南相關文檔下載下傳

• BPMN使用者指南 第一部分 - 中文PDF精編版
• BPMN使用者指南 第二部分 - 中文PDF精編版
• BPMN使用者指南 第三部分 - 中文PDF精編版
• 應用程式指南 - 中文PDF精編版
• 應用程式指南 - 中英對照PDF精編版
• 應用程式指南 - Eclipse設計器中文PDF精編版
• 表單使用者指南 - 中文PDF精編版
• 事件系統資料庫使用者指南 - 中文PDF精編版

《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）

• 12.1 查詢曆史
• 12.2 曆史配置
• 12.3 異步曆史配置
• 12.4 用于審計的曆史
• 12.5 曆史清理（History Cleaning）

有關Flowable的更多文檔，參見：

《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應用程式等作為消息偵聽器。