流動性のプロセスエンジンの問題と落とし穴

プロセスのファイル名の接頭辞は、プロセス定義自体にプロセスIDと一致する必要があります。プロセスIDは、「コンプライアンス預金プロセス」である場合などは、プロセスのファイル名は、プロセスが展開されているかどうかを確認するには、「コンプライアンス預金プロセスxxx.bpmn.xml」でなければなりません。processDefinitionQueryオブジェクトを使用します
```
repositoryService.createProcessDefinitionQuery().list()
```

並行して、サブprocesssesを開始するには、「multiInstanceLoopCharacteristics」を使用

<callActivity id="callnamescreeningprocess" name="call namescreening process" calledElement="namescreening-process"
flowable:inheritVariables="true">
<multiInstanceLoopCharacteristics isSequential="false" flowable:collection="${namesToScreen.result.namesToScreen}" flowable:elementVariable="nameVariableToScreen" >
<!-- completionCondition></completionCondition -->
</multiInstanceLoopCharacteristics>
</callActivity>

並列コールアクティビティタスクが参加したときに、例外スタックトレースがログに表示されます。しかし、このエラーが継続的にプロセスを妨げることはありません。

Job 327 failed
org.flowable.common.engine.api.FlowableOptimisticLockingException: VariableInstanceEntity[id=53, name=nrOfCompletedInstances, type=integer, longValue=1, textValue=1] was updated by another transaction concurrently
at org.flowable.common.engine.impl.db.DbSqlSession.flushUpdates(DbSqlSession.java:505) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.db.DbSqlSession.flush(DbSqlSession.java:292) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.interceptor.CommandContext.flushSessions(CommandContext.java:191) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.interceptor.CommandContext.close(CommandContext.java:61) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:80) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.spring.SpringTransactionInterceptor$1.doInTransaction(SpringTransactionInterceptor.java:49) ~[flowable-spring-common-6.4.1.jar:6.4.1]
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:140) ~[spring-tx-5.1.2.RELEASE.jar:5.1.2.RELEASE]
at org.flowable.common.spring.SpringTransactionInterceptor.execute(SpringTransactionInterceptor.java:46) ~[flowable-spring-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:30) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:51) ~[flowable-engine-common-6.4.1.jar:6.4.1]
at org.flowable.job.service.impl.asyncexecutor.ExecuteAsyncRunnable.executeJob(ExecuteAsyncRunnable.java:128) [flowable-job-service-6.4.1.jar:6.4.1]
at org.flowable.job.service.impl.asyncexecutor.ExecuteAsyncRunnable.run(ExecuteAsyncRunnable.java:116) [flowable-job-service-6.4.1.jar:6.4.1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_191]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_191]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]

信号通知は、プロセス・インスタンスを開始スレッドから別のスレッドであることが必要です。この問題は、ユニットテストの場合に特に顕著です。プロセスはまだ対応する「intermediateCatchEvent」ノードに到達しなかったのに対し、それ以外の信号はealier到達します。

val processInstanceId = executionService.startProcess("compliance-deposit-process", "100", listOf(ProcessVariable("deposit_service_host", "localhost:1010"),
))
Thread {
Thread.sleep(5000)
executionService.continueProcess(
     processInstanceId, "event-wait-rule-index-completed", listOf(
     ProcessVariable("caseAttributes", caseCreationData))
)
}.start()

並列ゲートウェイは、落とし穴に参加：
最初のプロセス定義は、トランザクション・モニターと名のスクリーニング用の2つの並列実行パスと並行ゲートウェイから始まります。トランザクションモニタの実行は2つの論理分岐を有する排他的ゲートウェイを開始し、すべての分岐は接合平行ゲートウェイに接続向けます。しかし、参加並列ゲートウェイが出ることはありません。

のみそれらの二つが実際に実行され、一方、接合平行ゲートウェイの3着信接続があることに留意されたいです。これは、並列ゲートウェイ出口条件チェックの失敗を引き起こしました。org.flowable.engine.impl.bpmn.behavior.ParallelGatewayActivityBehaviorを参照してください。

// Fork

// Is needed to set the endTime for all historic activity joins
CommandContextUtil.getActivityInstanceEntityManager().recordActivityEnd((ExecutionEntity) execution, null);

if (nbrOfExecutionsCurrentlyJoined == nbrOfExecutionsToJoin) {

    // Fork
    if (LOGGER.isDebugEnabled()) {
        LOGGER.debug("parallel gateway '{}' ({}) activates: {} of {} joined", execution.getCurrentActivityId(), 
                execution.getId(), nbrOfExecutionsCurrentlyJoined, nbrOfExecutionsToJoin);
    }
    ...
}

この問題を回避するには、その後、最初の排他ゲートウェイから2つの論理分岐を結合並列ゲートウェイに参加するための軽量ダミースクリプトノードを追加することです。

流動性のプロセスエンジンの問題と落とし穴

Async task delay:
From the log i found that there when the parent process starts multiple subprocesses, only 2 of them are executed at the same time. The engine triggers another batch after around 10 seconds. The key problem is that i inadventently add "flowable:async=true" to callActivity task. This seems to somehow reorder the task to execute and delay the invoation of subprocess for a while.
```
<callActivity id="callnamescreeningprocess" name="call namescreening process" calledElement="namescreening-process"
flowable:inheritVariables="true" flowable:async="true">
```
Checking the code: org.flowable.job.service.impl.asyncexecutor.DefaultAsyncJobExecutor and org.flowable.job.service.impl.asyncexecutor.AcquireAsyncJobsDueRunnable: The aync job acquiring thread first checks remaining capacity in job pool (minimum of threadPoolQueue.remainingCapacity and MaxAsyncJobsDuePerAcquisition) and trying to poll a batch of jobs up to that size. If polled job size = remains capacity, this indicates that there are more job waiting to be executed. The job acquiring thread will not wait and immedidate starts another round of polling, otherwise, the thread pause for asyncExecutorDefaultAsyncJobAcquireWaitTime. Adjusting the variable "maxAsyncJobsDuePerAcquisition" (default value: 1) requires caution. Increase the value does increase throughput, but under cluster environment. It might cause more optimistic locking exception and degrade stability. Adjusting the variable "asyncExecutorDefaultAsyncJobAcquireWaitTime" to lower value (default value: 10000ms) also increase throughtput. But it might increase invalid db polling.
Signal to continue subprocess:
Sometimes, it is neccessary to continue a subprocess by signal from code. To do that, the processInstanceId of the subprocess must be known. Usually we will store parent processInstanceId in database table. But since the subprocesses are not triggered from code but via a multiInstance callActivity task in parent process definition, the processInstanceIds of the subprocesses are not known directly. A workaround to get the subprocess's processInstanceId is via ExecutionQuery.

val query = runtimeService.createExecutionQuery().activityId("event-wait-namescreening-result").variableValueEquals("nameVariableToScreen", "abc") 
val execution = query.list()[0] 
runtimeService.signalEventReceived(signalName, execution.id, variables.associate {
   Pair(it.name, it.value)
})

The "activityId" parameter takes value of an "intermediateCatchEvent" where the subprocesses are waiting for. This gives a list of subprocess executions that are waiting for the event signal. An additional variable to further distinguish which subprocess we want to signal, this should be the business key stored as a subprocess variable.

問題：
multiInstanceLoopCharacteristics completionCondition式：式の評価コンテキストは、マルチインスタンス実行の変数（nrOfActiveInstances、nrOfInstances、nrOfCompletedInstances）とその親（メインプロセス）へのアクセスのみを持っています。それは私たちが投票シナリオのために複数のサブプロセスを使用している場合、これは私たちが何ができるかに重大な制限を課し、callActivity実行スコープ内に変数にアクセスすることはできません。いくつかの問題を回避するには、ここで説明されていますhttps://blog.csdn.net/weixin_40147618/article/details/83548270

流動性のプロセスエンジンの問題と落とし穴

おすすめ