With the release of IBM BPM 8.5 a new functionality called “Teams” was created to replace the older construct “Participant Groups” which shipped in earlier versions of IBM BPM. While Teams are still able to do all of the things that could be done with participant groups, they add a few new features to our BPM solutions.
It is very important to remember that the Team functionality replaces and enhances the Participant Group functionality. They can act as Participant Groups did in the past, containing static members defined by either a set of user or a Security group. However the largest change is the availability of Team Retrieval Services.
TEAM RETRIEVAL SERVICES (TRS):
These are services that basically do exactly what their name says. The service has to be created to follow a very specific template with respect to the inputs and outputs on the service. Any service that meets those requirements can be used to answer the question “Please return the list of users for this Team.”.
Within this service you can do anything that it is possible to do with a BPM integration service. You can call out to other systems, process the results, whatever you need to do. The only requirement is that the service meet the input and output signature of a TRS. This means your team membership can now be as complicated as you desire.
The membership of the team is limited to the snapshot where the team was evaluated. Thus if you have 2 snapshots of a BPM Process Application using the same team, each snapshot will have it's own version of the team reflecting the results of the TRS at the last time it was executed for that team.
CACHING AND TEAM MEMBERSHIP:
On the overview tab of the TRS, there is an option to use caching.
If enabled, the TRS will check the cache for a result before executing the TRS code. If there is no cached result the TRS will execute and the result will then be cached for future use until the cache expiration has elapsed.
If disabled, the TRS will execute every time the Team using the TRS needs to be evaluated. This can place additional load on the system which may need to make LDAP or other system-of-record calls for user team membership.
The membership of a Team defined by a TRS is called every time a new task is assigned to that team. Unlike Participant Groups which were refreshed on a user's login, the act of a user logging in will not trigger a re-examination of the TRS results. This means that if a user is somehow removed from a team that is leveraging a TRS, that removal will not be picked up until either a new task is issued to the team or the Team is manually refreshed (see below).
Note that the choice to use caching affects this behavior. As stated in the caching section if a caching is turned on and a result is available, the TRS will return the cached result rather than re-running the TRS.
FORCING A REFRESH:
There is a method to programmatically force a re-evaluation of the membership of a team using an API against a specific team. Since teams are scoped to the snapshot of a process app, the refresh will only update the team within the context of that snapshot. Also, the update will affect only the team within the database but it will not invalidate the TRS cache if it is being used. The cache update will only happen once the cache entry has expired.
Example of forcing a refresh:
On the TRS service in the Overview tab, you can see the Service Result Cache and define the duration you want to keep the cache alive for. Remember that when the service is invoked, the cache is checked. If a matching result is found, the cached result is used directly without calling the service. If a matching result is not found in the cache, or the cached result has expired, then the service is invoked and the cache is refreshed.
This means you should set the cache duration to a reasonable time for your business needs as the expiration cannot be changed programmatically.