Clustering and the TRIRIGA Workflow Agent

In IBM TRIRIGA the Workflow Agent is arguably the most important agent in the system, so it is essential to configure it correctly. In deployments ranging from medium to enterprise class, you will typically split out your background work into one or more process servers, so as not to impact upon end user response time.

This means that you will no longer run a WFAgent in your app server, but instead run it in one or more in your process server(s). As per the TRIRIGA Best Practices guide below, if you do have more than one process server, you should only ever run one general purpose WFAgent. This is because the agents running in each process server are not in any way "aware" of each other, and so there is a significant chance that they will each attempt to pick up and execute the same asynchronous workflow from the queue at the same time. Also workflows may potentially be executed out of order. This can result in data integrity issues.

We therefore recommend designating one large process server to run all async workflows that are not tied to a specific user. Additional WFAgents must then be configured to only run workflows for a specific userid. In this way a specific subset of high impact workflows, e.g. those relating to lease accounting or data loading, may be hived off into their own process server(s).

Multi-Threading

Just because you only have one WFAgent per process server, doesn't mean you only have one instance. The WFAgent is multi-threaded, so multiple instances are running at the same time and, because they all run in the same Java Virtual Machine (JVM), they will co-ordinate with each other so as not to pick up the same workflow instance. The scale of multi-threading is controlled by the Workflow Agent Max Threads and Workflow Max Active Threads Per User properties, which can be initially set in the TRIRIGAWEB.properties configuration file and then dynamically altered via the Admin Console.

These can be tuned as needed to optimise workflow throughput for your specific requirements. The Best Practices guide recommends that these numbers should between 4 and 32. My experience is that you can safely set it between 1 and 4 times the number of CPU cores of your DB server. Your workflow throughput profile may flatten at a lower number than this, and any increases to these properties beyond that will not improve performance and may damage it, so any change you make should be thoroughly load tested.