...
Here you must increase the default values for message exchange timeout and external service invocation timeout. Also set the SO_TIMEOUT
parameter and CONNECTION_TIMEOUT
parameter in HttpSender. Increase the timeout value from the default value to 10 minutes.
HumanTask caching
HumanTask caching is important when you have to deal with a large user store. HumanTasks are tightly coupled with users and user roles/groups. Because of this, BPS does lot of user store lookups for HumanTask operations. These user store calls can take considerable amount of time, if the user store is large or located remotely. This degrades the performance of the entire HumanTask engine. Caching user and role lookup data at the BPS side will reduce these remote user store calls and improve the overall performance of the HumanTask engine.
Enable HumanTask caching in the <BPS_HOME>/repository/conf/humantask.xml
file.
Code Block | ||
---|---|---|
| ||
<cacheconfiguration>
<enablecaching>true</enablecaching>
</cacheconfiguration> |
Number of HumanTask scheduler threads
This is relevant when you are not using HumanTask deadline/escalation. HumanTask deadline and escalation are scheduled tasks that are executed by the HumanTask scheduler. By default, 50 threads are allocated for the HumanTask scheduler. If you are not using deadline/escalations, you can configure this value to a lower value such as 5. This will utilize idle threads in BPS server. Note that, you can't set this to 0, because the HumanTask engine has several internal scheduled tasks to run.
Configure this value in the <BPS_HOME>/repository/conf/humantask.xml
file.
Code Block | ||
---|---|---|
| ||
<schedulerconfig>
<maxthreadpoolsize>5</maxthreadpoolsize>
</schedulerconfig> |
BPEL process persistence
Configuring BPEL process persistence is recommended. If a process is implemented in the request-response interaction model, use in-memory processes instead of persistence processes. This decision mainly depends on the specific business use-case.
...