Workflow agents

Workflow agents pick up and process workflow events that are published by their designated users and groups. You can designate IBM TRIRIGA application users and groups for a workflow agent in the Workflow Agent Manager object of the Administrator Console.

The same user or group can be designated to multiple workflow agents. Priority is given to users and groups that have an agent that is configured for them. You can restrict an agent to the User and Group List, which prevents the agent from processing events that are posted by unassigned users and groups. You can also reset the restricted User and Group List settings, which allows you to remove settings for a server that is no longer in the current environment.

When an agent is configured for specific users, it picks up valid user events in the following order:

  1. If the agent is configured exclusively for one or more users, it picks up any available events.
  2. If the agent is configured for users non-exclusively, the agent keeps other agents from processing events for the specified users while it processes any available events for the specified users and other users.
  3. If an agent is not configured for specific users, it picks up any available events as it is unrestricted.

Valid events are events that satisfy the following conditions:

  • The event is not currently being processed.
  • No other event is being processed for the same record.
  • The event is not for a user that already has the maximum number of events being processed by this agent.

The User and Group List in the Workflow Agent Manager is initially empty. To add users, you click the Add Users action. After you select users and click OK, the names are displayed in the User and Group List. To add groups, you click the Add Groups action. After you select groups and click OK, the names are displayed in the User and Group List.

After names are added to this list, the Restrict to User and Group List action appears. Click this action to prevent the agent from processing events by users and groups who are not assigned to this agent. The agent is exclusive to the assigned users and groups.

To remove the restriction on the agent, click the Do Not Restrict to User and Group List action. The agent then processes events that are not only owned by its users and groups, but also owned by users and groups who are not assigned to any agent.

If multiple workflow agents exist, the Settings for other Agents section shows a read-only list of agents that are not running on the current application server.

Tip:

You run multiple workflow servers to allow workflow processing to be done in a manner that is fair to all users, not necessarily to increase the throughput of the number of workflows that are completed.

Adding more workflow agents to an environment can slow down processing, and cause undesirable results if workflows are not written with multi-threading in mind.

It is a best practice to assign secondary workflow agents to specific power users that tend to run more workflows than normal users. If the secondary workflow agents are left wide open, a set of workflow instances are picked up in parallel, and some can be processed out of order. Increasing the number of threads on a single process server results in higher throughput than splitting the threads across two servers. Typically, the bottleneck of performance in an environment is the database server rather than the process servers.

If you already have a system that is deployed with multiple workflow agents, consider either stopping the secondary agents and increasing the threads on the primary workflow agent server to be the sum of the threads across the other servers, or restricting the secondary agents so that they are exclusive for the set of power users.