Flowable6.6.0BPMN用户指南17高级用例17.1异步执行器（1）

• 17.1 异步执行器&＃xff08;Async Executor&＃xff09;
  • 17.1.1 异步执行器设计&＃xff08;Async Executor design&＃xff09;
  • 17.1.2 异步执行器配置
  • 17.1.3 基于异步执行器的消息队列
• 17.2 与流程解析挂钩&＃xff08;Hooking into process parsing&＃xff09;
• 17.3 用于高并发的UUID ID生成器
• 17.4 多租户&＃xff08;Multitenancy&＃xff09;
• 17.5 执行自定义SQL&＃xff08;Execute custom SQL&＃xff09;
• 17.6 采用ProcessEngineConfigurator 进行高级的流程引擎配置
• 17.7 高级查询API&＃xff1a;运行时和历史任务查询之间的无缝切换
• 17.8 重写标准SessionFactory实现自定义身份管理
• 17.9 启用安全的BPMN 2.0 xml
• 17.10 事件日志记录&＃xff08;Event logging&＃xff09;
• 17.11 禁用批量插入&＃xff08;Disabling bulk inserts&＃xff09;
• 17.12 安全脚本&＃xff08;Secure Scripting&＃xff09;
• 17.13 日志记录会话[实验性]

有关Flowable的更多文档&＃xff0c;参见&＃xff1a;

《Flowable文档大全》

17 高级用例

The following sections cover advanced use cases of Flowable, that go beyond typical execution of BPMN 2.0 processes. As such, a certain proficiency and experience with Flowable is advised to understand the topics described here.

下面几节介绍了Flowable的高级用例&＃xff0c;这些用例超出了BPMN 2.0流程的典型执行。因此&＃xff0c;建议您对Flowable有一定的熟练程度和经验&＃xff0c;以了解此处所述的主题。

17.1 异步执行器&＃xff08;Async Executor&＃xff09;

In Flowable v5, the Async executor was added in addition to the existing job executor. The Async Executor has proved to be more performant than the old job executor by many users of Flowable and in our benchmarks.

在Flowable V5中&＃xff0c;除了现有的作业执行器之外&＃xff0c;还添加了异步执行器(Async executor)。许多Flowable用户和我们的基准测试已经证明&＃xff0c;异步执行器比旧的作业执行器性能更好。

From Flowable V6, the async executor is the only one available. For V6, the async executor has been completely refactored for optimal performance and pluggability, while still being compatible with existing APIs.

在Flowable V6中&＃xff0c;异步执行器是唯一可用的。对于V6&＃xff0c;异步执行器已经完全重构以获得最佳性能和可插性&＃xff08;performance and pluggability&＃xff09;&＃xff0c;同时仍然与现有API兼容。

17.1.1 异步执行器设计&＃xff08;Async Executor design&＃xff09;

Two types of jobs exist: timers (such as those belonging to a boundary event on a user task) and async continuations (belonging to a service task with the flowable:async&＃61;“true” attribute).

Timers are the easiest to explain: they are persisted in the ACT_RU_TIMER_JOB table with a certain due date. There is a thread in the async executor that periodically checks if there are new timers that should fire (in other words, the due date is ‘before’ the current time). When that happens, the timer is removed and an async job is created.

存在两种类型的作业&＃xff1a;定时器&＃xff08;例如属于用户任务上边界事件的定时器&＃xff09;和异步持续&＃xff08;属于具有flowable:async&＃61;“true” 属性的服务任务&＃xff09;。

定时器是最容易解释的&＃xff1a;它们被保存在具有特定截止日期的ACT_RU_TIMER_JOB表中。异步执行器中有一个线程&＃xff0c;它定期检查是否有新的定时器应该触发&＃xff08;换句话说&＃xff0c;截止日期是当前时间的“之前”&＃xff09;。当发生这种情况时&＃xff0c;将删除定时器并创建一个异步作业。

An async job is inserted in the database during the execution of process instance steps (which means, during some API call that was made). If the async executor is active for the current Flowable engine, the async job is actually already locked. This means that the job entry is inserted in the ACT_RU_JOB table and will have a lock owner and a lock expiration time set. A transaction listener that fires on a successful commit of the API call triggers the async executor of the same engine to execute the job (so the data is guaranteed to be in the database). To do this, the async executor has a configurable thread pool from which a thread will execute the job and continue the process asynchronously. If the Flowable engine does not have the async executor enabled, the async job is inserted in the ACT_RU_JOB table without being locked.

在执行流程实例步骤的过程中&＃xff08;也就是说&＃xff0c;在进行的某个API调用期间&＃xff09;&＃xff0c;将在数据库中插入异步作业。如果对当前Flowable引擎&＃xff0c;异步执行器处于活动状态&＃xff0c;则异步作业实际上已被锁定。这意味着作业条目被插入到ACT_RU_JOB表中&＃xff0c;并将设置一个锁所有者&＃xff08;lock owner &＃xff09;和一个锁到期时间&＃xff08;lock expiration time &＃xff09;。在成功提交API调用时激发的事务侦听器&＃xff08;transaction listener&＃xff09;会触发同一引擎的异步执行器&＃xff08;async executor&＃xff09;来执行作这个业&＃xff08;因此保证数据在数据库中&＃xff09;。为此&＃xff0c;异步执行器有一个可配置的线程池&＃xff0c;线程将从中执行作业并异步继续流程。如果Flowable引擎未启用异步执行器&＃xff0c;则异步作业将插入ACT_RU_JOB表中&＃xff0c;而不会被锁定。

Similar to the thread that checks for new timers, the async executor has a thread that ‘acquires’ new async jobs. These are jobs that are present in the table that are not locked. This thread will lock these jobs for the current Flowable engine and pass it to the async executor.

与检查新定时器的线程类似&＃xff0c;异步执行器&＃xff08;async executor&＃xff09;有一个“获取”新异步作业&＃xff08;async job&＃xff09;的线程。这些作业是表中未锁定的作业。此线程将为当前Flowable引擎锁定这些作业&＃xff0c;并将其传递给异步执行器。

The thread pool executing the jobs uses an in-memory queue from which to take jobs. When this queue is full (this is configurable), the job will be unlocked and re-inserted into its table. This way, other async executors can pick it up instead.

执行作业的线程池使用内存中的队列从中获取作业。当此队列已满&＃xff08;这是可配置的&＃xff09;时&＃xff0c;作业将被解锁并重新插入其表中。这样&＃xff0c;其他异步执行器就可以取而代之。

If an exception happens during job execution, the async job will be transformed to a timer job with a due date. Later, it will be picked up like a regular timer job and become an async job again, to be retried soon. When a job has been retried for a (configurable) number of times and continues to fail, the job is assumed to be ‘dead’ and moved to the ACT_RU_DEADLETTER_JOB. The ‘deadletter’ concept is widely used in various other systems. An administrator will now need to inspect the exception for the failed job and decide what the best course of action is.

如果在作业执行期间发生异常&＃xff0c;则异步作业将转换为具有到期日期的定时器作业。稍后&＃xff0c;它将像常规定时器作业一样被拾取&＃xff0c;并再次成为异步作业&＃xff0c;稍后将重试。当某个作业已重试&＃xff08;可配置&＃xff09;多次并继续失败时&＃xff0c;该作业被假定为“已停止”并移动到ACT_RU_DEADLETTER_JOB。“死信”概念广泛应用于其他各种系统。管理员现在需要检查失败作业的异常&＃xff0c;并确定最佳操作方案。

Process definitions and process instances can be suspended. Suspended jobs related to these definitions or instances are put in the ACT_RU_SUSPENDED_JOB table, to make sure the query to acquire jobs has as few possible conditions in its where clause.

可以挂起流程定义和流程实例。与这些定义或实例相关的挂起作业放在ACT_RU_SUSPENDED_JOB表中&＃xff0c;以确保获取作业的查询在其where子句中有尽可能少的条件。

One thing that is clear from the above: for people familiar with the old implementations of the job/async executor, the main goal is to allow the ‘acquire queries’ to be as simple as possible. In the past (before V6), one table was used for all job types/states, which made the ‘where’ condition large as it catered for all the use cases. This problem is now solved and our benchmarks have proved that this new design delivers better performance and is more scalable.

上面有一点很清楚&＃xff1a;对于熟悉作业/异步执行器的旧实现的人来说&＃xff0c;主要目标是让“获取查询”尽可能简单。在过去&＃xff08;在V6之前&＃xff09;&＃xff0c;一个表用于所有作业类型/状态&＃xff0c;这使得“where”条件很大&＃xff0c;因为它适合所有用例。这个问题现在解决了&＃xff0c;我们的基准测试已经证明&＃xff0c;这种新的设计提供了更好的性能和更高的可扩展性。

培训视频推荐

CSDN上提供了Flowable 6.6.0的系列培训视频课程&＃xff0c;欢迎有兴趣的朋友前往学习。

• 《Flowable流程入门课程》
• 《Flowable流程高级课程》
• 《Flowable从入门到精通》